Le volume de la console de mon serveur VMware ESX est passé en lecture seule.Comment puis-je sauvegarder mes VM ?

Question

Deux volumes RAID, noyau/console VMware fonctionnant sur un RAID1, vmdks vivant sur un RAID5.La saisie d'un identifiant sur la console entraîne simplement des erreurs SCSI, aucune invite de mot de passe.Loué soit, les machines virtuelles sont toujours en cours d’exécution.Nous pensons cependant qu'au redémarrage, le noyau risque de ne pas redémarrer et les machines virtuelles seront en panne.

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

Quelles sont mes options ?

Notre meilleure idée actuelle est

1. Utilisez VMware Converter pour créer des vmdks en direct à partir des machines virtuelles en cours d'exécution, comme s'il s'agissait d'une migration P2V.
2. Redémarrez le serveur hôte et exécutez les diagnostics RAID, découvrez ce qui s'est passé dans le "h"
3. Essayez de redémarrer ESX, éventuellement après avoir reconstruit son volume RAID
4. Il faudra peut-être réinstaller ESX sur son volume et rattacher les VM
5. Si cela ne fonctionne pas, attachez les vmdks « en direct » créés à l'étape 1 à un autre hôte de 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, gardant ainsi 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 connaître leurs configurations.Les deux ont été dégradés et tous deux ont été réparés avec succès.

À l'étape 4, il n'était pas nécessaire de réinstaller ESX ;bien que, au démarrage, il ne souhaitait pas enregistrer les machines virtuelles.Nous avons dû déterrer des éléments de gestion enfouis pour demander au noyau de démissionner des machines virtuelles.(Recherchez dans la documentation VM "démission".)

Je pense que notre plan de secours aurait fonctionné, les images VMware Converter des machines virtuelles qui fonctionnaient "orphelines" ont été testées et ont fonctionné correctement sans perte de données.Je recommande fortement d'effectuer une imagerie VMware Converter de toute VM qui entre dans cet état, après avoir arrêté autant de services que possible et mis la VM dans un état en lecture seule autant que possible.Charger un vmdk ailleurs ou sur l'hôte d'origine en tant que réparation sera généralement BEAUCOUP plus rapide que de reconstruire un serveur à partir de zéro avec des sauvegardes.