Поиск и устранение неисправностей виртуальной машины, которая перестала отвечать

Целей
В этой статье приведены инструкции по изоляции возможных причин зависания виртуальной машины vSphere.

Не отвечающая виртуальная машина не реагирует ни на какие попытки подключения и может быть не в состоянии ответить ни на одну из попыток ее выключить/включить. Существует множество причин, по которым виртуальная машина может оказаться в состоянии зависания. Эта статья поможет выявить и устранить эти распространенные причины, а затем вернуть виртуальную машину в рабочее состояние.

Можно жестко выключить виртуальную машину, не выясняя причину, но это не позволит собирать и анализировать информацию, которая могла бы помочь в определении основной причины сбоя. 

Факты
Виртуальная машина, работающая на VMware ESX/ESXi, не реагирует на внешние входные данные и не проявляет никаких действий. Специально:

• Гостевая ОС не реагирует на действия клавиатуры или мыши на консоли

• Гостевая ОС не реагирует на обмен данными по сети, в том числе на запросы ping, RDP, SSH и т. д.

• Экран консоли виртуальной машины статичен, не изменяется и не обновляется

• Задачи, выполняемые на виртуальной машине, завершаются сбоем, истекает время ожидания или не запускаются

• Виртуальная машина не создает сетевой или дисковый трафик

Решение
Службы, предоставляемые виртуальной машиной, могут перестать отвечать или стать недоступными по ряду причин, включая проблемы с приложениями или гостевой ОС в виртуальной машине, проблемы с монитором виртуальной машины или виртуальными устройствами, конкуренцию ресурсов на хосте или проблемы с базовой системой хранения или сетевой инфраструктурой.
Если гостевая ОС производит какие-либо действия, это означает, что она успешно выполняется. В этом случае отсутствие реакции, скорее всего, связано с проблемой подключения или конфликтом ресурсов или характерно для компонента более высокого уровня, например приложения или службы, работающей в гостевой ОС.

Проверьте область действия:
Важно иметь точные симптомы и понимание масштабов проблемы. Чтобы определить масштаб проблемы, выполните следующие проверки:

1. Убедитесь, что виртуальная машина действительно не отвечает. Возможно, виртуальная машина не отвечает через один интерфейс, но правильно работает в других. 

2. Убедитесь, что виртуальная машина включена. Если виртуальная машина неожиданно выключилась, снова включите ее, а затем выполните поиск и устранение причины непредвиденного выключения.

3. Определите, затрагивает ли эта проблема несколько виртуальных машин или только одну. Если затронуто несколько виртуальных машин, при попытке сузить потенциальную область действия учитывайте сходство между затронутыми виртуальными машинами. В частности, сосредоточьтесь на общей инфраструктуре, от которой зависит группа затронутых виртуальных машин, и на том, затронуты ли все виртуальные машины, зависящие от этой общей инфраструктуры. 

4. Определите, реагирует ли гостевая ОС на взаимодействие на консоли виртуальной машины. Если проблема была локализована в гостевой ОС или приложениях на виртуальной машине и гостевая ОС отвечает на запросы, взаимодействуйте с гостевой ОС на консоли для решения проблемы. 

5. Определите, реагирует ли гостевая ОС или ее службы приложений на взаимодействие по сети.

6. Определите, сообщила ли гостевая ОС о каких-либо критических ошибках в консоль и находится ли она в приостановленном состоянии.

7. Определите, не отвечает ли хост ESX/ESXi. Если хост также не отвечает, область оказывается больше, чем предполагалось изначально.

Определите причину:
На этом этапе вы установили, что одна или несколько виртуальных машин не отвечают как на виртуальной консоли, так и по сети. Сам хост отвечает на запросы. Проблема может быть связана с доступностью ресурсов, конфликтами между ними или с базовой инфраструктурой хранения данных или сети.
Чтобы определить причину, выполните следующие действия.

1. Определите, вызвана ли проблема операцией или задачей, выполняемой на виртуальной машине. Например, операции создания моментальных снимков и vMotion замедляют виртуальную машину на короткий период времени, в то время как состояние памяти копируется по сети или на диск.

2. Некоторые распространенные ошибки конфигурации могут привести к тому, что виртуальная машина перестанет отвечать, например во время ожидания ресурса. Проверьте конфигурацию виртуальной машины и хоста. 

3. Виртуальные машины зависят от функциональной резервной инфраструктуры. При возникновении проблемы с базовым хранилищем или сетевой инфраструктурой, от которой зависит виртуальная машина, может быть затронуто виртуальное оборудование, которое виртуальная машина предоставляет гостевой ОС. Устраните основную проблему с хранилищем или сетью.

4. Виртуальные машины зависят от доступных ресурсов хоста (ЦП, память), и гостевая ОС использует эти ресурсы. Проблема с доступностью ресурсов или планированием внутри или за пределами виртуальной машины может привести к тому, что она перестанет отвечать. Виртуальная машина также может блокироваться на недоступных ресурсах или вращаться при 100%-ном использовании виртуального ЦП. 

План действий:
На этом этапе вы убедились, что хост, на котором работают виртуальные машины, быстро реагирует и не сталкивается с какими-либо проблемами с общим хранилищем или сетевой инфраструктурой. Гостевая ОС не завершила сбой с критической ошибкой, но по-прежнему не отвечает на консоли виртуальной машины и по сети.
Выполните действие по восстановлению или сбору информации о не отвечающей виртуальной машине на основе архитектурного уровня, который является подозрительным:

• Если проблема была локализована в гостевой ОС или %RUN имеет относительно высокое значение, но монитор виртуальной машины работает правильно, переместите исследование в гостевую ОС или приложения виртуальной машины. Гостевая ОС может перестать отвечать на запросы на виртуальной машине так же, как и на физическом оборудовании:

  1. Собирайте данные о производительности во время возникновения проблемы.

  2. Попытка вручную вызвать панику ядра в гостевой ОС для сбора дополнительной информации о его внутреннем состоянии. Если гостевая ОС создает полезную диагностическую информацию в ответ на одно из этих событий, обратитесь к поставщику гостевой ОС для дальнейшего изучения.

  3. Если шаг 2 не дает полезной информации, приостановите виртуальную машину, чтобы собрать информацию о ее внутреннем состоянии, и откройте заявку в службе поддержки VMware:

     1. Приостановите виртуальную машину и соберите .vmss Файл состояния приостановки.

     2. Соберите журналы на хосте, на котором запущена виртуальная машина.

     3. Снова включите виртуальную машину, а затем выполните сброс.

     4. Обратитесь в службу поддержки VMware, предоставив информацию, собранную на шагах 1, 3a и 3b.

• Если проблема локализована на мониторе виртуальной машины или %WAIT является относительно высоким, или попытки приостановить виртуальную машину завершились сбоем, соберите данные о производительности и принудительно завершите работу виртуальной машины для сбора дополнительной информации о ее внутреннем состоянии:

  1. Собирайте данные о производительности во время возникновения проблемы.

  2. Аварийное завершение работы виртуальной машины для сбора информации о ее внутреннем состоянии.

     ПРИМЕЧАНИЕ. Если попытки аварийного завершения виртуальной машины не увенчаются успехом, перейдите к следующему разделу и попытайтесь аварийно завершить работу хоста.

  3. Обратитесь в службу поддержки VMware, предоставив информацию, собранную на шагах 1 и 2.

• Если проблема была локализована в мониторе виртуальной машины, но попытки приостановить или вызвать сбой виртуальной машины завершаются сбоем, это указывает на проблему с VMkernel. Соберите пакет журналов с хоста, перенесите с него все незатронутые виртуальные машины и с помощью NMI намеренно создайте фиолетовый экран диагностики:

  1. Собирайте данные о производительности во время возникновения проблемы.

  2. Переместите все не затронутые виртуальные машины с хоста с помощью vMotion. По возможности используйте режим обслуживания, чтобы предотвратить запуск дополнительных виртуальных машин на хосте.

  3. Настройте хост так, чтобы при получении немаскируемого прерывания возникала паника, а затем выдавалась команда NMI для запуска критической ошибки.

  4. После того как хост создаст фиолетовый экран диагностики и завершит дамп диагностической информации, сделайте снимок экрана или сфотографируйте консоль и перезапустите хост.

  5. Соберите диагностическую информацию с хоста.

  6. Обратитесь в службу поддержки VMware, предоставив информацию, собранную на шагах 1, 4 и 5.

Статьи
по темеСтатья базы знаний VMware 1007819: https://kb.vmware.com/kb/1007819