Dépannage d’une machine virtuelle qui ne répond plus

Objectifs
Cet article décrit les étapes à suivre pour isoler les causes possibles de l’absence de réponse d’une machine virtuelle vSphere.

Une machine virtuelle qui ne répond pas ne répond à aucune tentative de connexion et peut ne pas être en mesure de répondre aux tentatives de mise hors tension. Il existe diverses raisons pour lesquelles une machine virtuelle peut se retrouver dans un état qui ne répond pas. Cet article vous permet d’identifier et de résoudre ces causes courantes et, une fois résolues, de rétablir la machine virtuelle à un état opérationnel.

Il est possible de mettre une machine virtuelle hors tension sans résoudre la cause, mais cela empêche la collecte et l’analyse d’informations qui pourraient aider à déterminer la cause première de la panne. 

Faits
Une machine virtuelle s’exécutant sur VMware ESX/ESXi ne répond à aucune entrée externe et ne présente aucune activité. Cela concerne plus spécifiquement les points suivants :

• Le système d’exploitation invité ne répond pas à l’activité du clavier ou de la souris sur la console

• Le système d’exploitation invité ne répond pas aux communications réseau, notamment ping, RDP, SSH, etc.

• L’écran de la console de la machine virtuelle est statique et ne change pas ou ne s’actualise pas

• Les tâches effectuées sur la machine virtuelle échouent, expirent ou ne démarrent pas

• La machine virtuelle ne produit pas de trafic réseau ou disque

Solution
Les services fournis par une machine virtuelle peuvent cesser de répondre ou devenir inaccessibles pour un certain nombre de raisons, notamment des problèmes liés aux applications ou au système d’exploitation invité au sein de la machine virtuelle, des problèmes liés à l’écran de la machine virtuelle ou aux appareils virtuels, des conflits d’accès aux ressources sur l’hôte ou des problèmes liés à l’infrastructure de stockage ou de gestion de réseau sous-jacente.
Si le système d’exploitation invité produit une activité, il s’exécute correctement. Dans ce cas, l’absence de réponse est probablement due à un problème de connectivité ou à un conflit d’accès aux ressources, ou est spécifique à un composant de niveau supérieur tel qu’une application ou un service s’exécutant dans le système d’exploitation invité.

Validez le périmètre :
Il est important d’avoir des symptômes précis et de comprendre l’ampleur d’un problème. Pour confirmer l’étendue du problème, effectuez les vérifications suivantes :

1. Vérifiez que la machine virtuelle ne répond pas. Il est possible que la machine virtuelle ne réponde pas via une interface, mais fonctionne correctement sur les autres. 

2. Vérifiez que la machine virtuelle est sous tension. Si la machine virtuelle a été mise hors tension de manière inattendue, remettez-la sous tension, puis résolvez la cause de l’arrêt inattendu.

3. Déterminez si ce problème concerne plusieurs machines virtuelles ou une seule. Si plusieurs machines virtuelles sont affectées, tenez compte des similitudes entre les machines virtuelles concernées lorsque vous tentez de réduire le périmètre potentiel. En particulier, concentrez-vous sur l’infrastructure partagée dont dépend le groupe de machines virtuelles concernées et déterminez si toutes les machines virtuelles dépendant de cette infrastructure commune sont concernées. 

4. Déterminez si le système d’exploitation invité répond à l’interaction sur la console de la machine virtuelle. Si un problème a été isolé sur le système d’exploitation invité ou les applications au sein de la machine virtuelle, et que le système d’exploitation invité répond à la console, interagissez avec le système d’exploitation invité sur la console pour résoudre le problème. 

5. Déterminez si le système d’exploitation invité ou ses services applicatifs répondent à l’interaction via le réseau.

6. Déterminez si le système d’exploitation invité a signalé des erreurs critiques à la console et s’il est à l’état d’arrêt.

7. Déterminez si l’hôte ESX/ESXi ne répond pas non plus. Si l’hôte ne répond pas non plus, le périmètre est plus étendu que prévu.

Identifiez la cause :
À ce stade, vous avez établi qu’une ou plusieurs machines virtuelles ne répondent pas à la fois à la console virtuelle et via le réseau. L’hôte lui-même est réactif. Un problème peut exister au niveau de l’accessibilité ou des conflits d’accès aux ressources, ou au niveau de l’infrastructure de stockage ou de gestion de réseau sous-jacente.
Pour identifier la cause :

1. Déterminez si le problème est déclenché par une opération ou une tâche en cours d’exécution sur la machine virtuelle. Par exemple, les opérations de snapshot et vMotion étourdent une machine virtuelle pendant de courtes périodes, tandis que l’état de la mémoire est copié sur le réseau ou sur le disque.

2. Certaines erreurs de configuration courantes peuvent conduire à ce qu’une machine virtuelle ne réponde plus, par exemple lors de l’attente d’une ressource. Vérifiez la configuration de la machine virtuelle et de l’hôte. 

3. Les machines virtuelles dépendent d’une infrastructure de sauvegarde fonctionnelle. En cas de problème avec le stockage de secours ou l’infrastructure de mise en réseau dont dépend la machine virtuelle, le matériel virtuel qu’une machine virtuelle présente au système d’exploitation invité peut être affecté. Résolvez le problème de stockage ou de mise en réseau sous-jacent.

4. Les machines virtuelles dépendent des ressources de l’hôte disponibles (CPU, mémoire), et le système d’exploitation invité utilise ces ressources. Un problème de disponibilité ou de planification des ressources à l’intérieur ou à l’extérieur de la machine virtuelle peut entraîner une absence de réponse. La machine virtuelle peut également être bloquée sur des ressources indisponibles ou tourner à 100 % d’utilisation du vCPU. 

Plan d’action :
À ce stade, vous avez établi que l’hôte qui exécute la ou les machines virtuelles est réactif et ne rencontre aucun problème de stockage partagé ou d’infrastructure réseau. Le système d’exploitation invité n’a pas échoué avec une erreur critique, mais ne répond toujours pas à la console de la machine virtuelle et via le réseau.
Prenez des mesures pour récupérer ou collecter des informations sur la machine virtuelle qui ne répond pas en fonction de la couche architecturale suspecte :

• Si un problème a été isolé sur le système d’exploitation invité ou le %RUN est relativement élevé, mais l’écran de la machine virtuelle fonctionne correctement, déplacez l’enquête dans le système d’exploitation invité ou les applications de la machine virtuelle. Un système d’exploitation invité peut ne plus répondre à l’intérieur d’une machine virtuelle, de la même manière que sur du matériel physique :

  1. Collectez les données de performances pendant que le problème se produit.

  2. Essayez d’induire manuellement une panique du noyau à l’intérieur du système d’exploitation invité pour collecter des informations supplémentaires sur son état interne. Si des informations de diagnostic utiles sont générées par le système d’exploitation invité en réponse à l’un de ces événements, demandez au fournisseur du système d’exploitation invité d’approfondir les recherches.

  3. Si l’étape 2 ne génère pas d’informations utiles, suspendez la machine virtuelle pour collecter des informations sur son état interne et ouvrez un ticket auprès du support VMware :

     1. Suspendez la machine virtuelle et récupérez les .vmss Suspendez le fichier d’état.

     2. Collectez les logs à partir de l’hôte qui exécute la machine virtuelle.

     3. Remettez la machine virtuelle sous tension, puis réinitialisez-la.

     4. Contactez le support VMware en fournissant les informations collectées aux étapes 1, 3a et 3b.

• Si un problème a été isolé sur le moniteur de la machine virtuelle ou sur %WAIT est relativement élevé, ou les tentatives de suspension de la machine virtuelle ont échoué, collectent des données de performances et forcent la machine virtuelle à se bloquer pour collecter des informations supplémentaires sur son état interne :

  1. Collectez les données de performances pendant que le problème se produit.

  2. Plantez la machine virtuelle pour collecter des informations sur son état interne.

     Remarque : Si les tentatives de blocage de la machine virtuelle échouent, passez à la section suivante et tentez de bloquer l’hôte.

  3. Contactez le support VMware en fournissant les informations collectées aux étapes 1 et 2.

• Si un problème a été isolé pour l’écran de la machine virtuelle, mais que les tentatives d’interruption ou de blocage de la machine virtuelle échouent, cela reflète un problème avec VMkernel. Collectez un bundle de logs à partir de l’hôte, évacuez toutes les machines virtuelles non affectées de l’hôte et utilisez une NMI pour générer intentionnellement un écran de diagnostic violet :

  1. Collectez les données de performances pendant que le problème se produit.

  2. Déplacez toutes les machines virtuelles non affectées hors de l’hôte à l’aide de vMotion. Si possible, utilisez le mode Maintenance pour empêcher le démarrage de machines virtuelles supplémentaires sur l’hôte.

  3. Configurez l’hôte pour qu’il panique à la réception d’une interruption non masquable, puis émettez un NMI pour déclencher un fonctionnement inattendu.

  4. Une fois que l’hôte a généré un écran de diagnostic violet et vidé les informations de diagnostic, effectuez une capture d’écran ou prenez une photo de la console, puis redémarrez l’hôte.

  5. Collectez les informations de diagnostic à partir de l’hôte.

  6. Contactez le support VMware en fournissant les informations collectées aux étapes 1, 4 et 5.

Articles
connexesVMware KB 1007819 : https://kb.vmware.com/kb/1007819