Mon volume de console du serveur VMware ESX a été lu en lecture seule. Comment puis-je sauvegarder mes machines virtuelles?

Question

Deux volumes RAID, noyau/console VMware s'exécutant sur un RAID1, vmdks en direct sur un RAID5. Entrer un login sur la console ne donne que des erreurs SCSI, pas d'invite de mot de passe. Louange soit, les machines virtuelles sont toujours en cours d'exécution. Nous pensons, cependant, qu'au redémarrage, le noyau ne redémarrera peut-être plus et les machines virtuelles seront désactivées.

Nous avons des sauvegardes de bases de données et de disques des machines virtuelles, mais pas de sauvegardes des vmdks elles-mêmes.

Quelles sont mes options?

Notre meilleure idée actuelle est

1. Utilisez VMware Converter pour créer vmdks en direct à partir des machines virtuelles en cours d'exécution, comme si elle était une migration P2V.
2. redémarrer le serveur hôte et exécuter des diagnostics RAID, figure ce que dans le « h » est passé
3. Essayez de démarrer à nouveau ESX, peut-être après la reconstruction de son volume RAID
4. ont peut réinstaller ESX sur son volume et re -attach VM
5. Si cela ne fonctionne pas, associez les vmdks "en direct" créés à l'étape 1 à un autre hôte VM.

Answer 1

C'était le fond de panier. Les deux disques du RAID1 et un disque du RAID5 étaient inaccessibles. Incroyablement, l'hyperviseur VMware a continué à fonctionner pendant trois jours à partir de la mémoire, sans accès à son disque hôte, ce qui a permis de maintenir en vie les machines virtuelles qu'il gérait.

À l'étape 3 ci-dessus, nous avons diagnostiqué le problème matériel et remplacé le contrôleur RAID, les câbles et le fond de panier. Après le redémarrage, nous avons ré-initialisé le RAID en demandant au contrôleur d'interroger les disques pour leurs configurations. Les deux ont été dégradés et les deux ont été réparés avec succès.

À l'étape 4, il n'était pas nécessaire de réinstaller ESX; Cependant, au démarrage, il ne voulait pas enregistrer les machines virtuelles. Nous avons dû déterrer des éléments de gestion enfouis pour ordonner au noyau de resigner les machines virtuelles. Je crois que notre plan de secours aurait fonctionné, les images VMware Converter des VM qui tournaient "orphelines" ont été testées et fonctionnaient correctement sans perte de données. Je recommande fortement d'effectuer une imagerie VMware Converter de toutes les machines virtuelles qui entrent dans cet état, après avoir fermé autant de services que possible et mis la machine virtuelle en tant qu'état en lecture seule. Charger un vmdk ailleurs ou sur l'hôte d'origine en tant que réparation est généralement plus rapide que de reconstruire un serveur à partir de zéro avec des sauvegardes.