Усунення несправностей віртуальної машини, яка перестала відповідати

Summary: У цій статті наведено кроки для виявлення можливих причин того, що віртуальна машина vSphere перестає відповідати.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Instructions

Цілей
У цій статті наведено кроки для виявлення можливих причин того, що віртуальна машина vSphere перестає відповідати.

Віртуальна машина, яка не відповідає, не реагує на будь-які спроби з'єднання і може бути не в змозі відповісти на будь-які спроби її переключення. Існує безліч причин, через які віртуальна машина може опинитися в стані, що не відповідає. Ця стаття дає змогу виявити та усунути ці поширені причини, а в разі їх усунення повернути віртуальну машину до робочого стану.

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

Факти
Віртуальна машина, що працює на VMware ESX/ESXi, не реагує на будь-яке зовнішнє введення та не проявляє жодної активності. Специфічно:

  • Гостьова ОС не реагує на дії клавіатури або миші на консолі

  • Гостьова ОС не реагує на мережевий зв'язок, включаючи ping, RDP, SSH і т.д.

  • Екран консолі віртуальної машини статичний, не змінюється і не оновлюється

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

  • Віртуальна машина не виробляє мережевий або дисковий трафік

Рішення
Служби, які надає віртуальна машина, можуть не відповідати або бути недоступними через низку причин, включаючи проблеми з програмами або гостьовою ОС у віртуальній машині, проблеми з монітором віртуальної машини або віртуальними пристроями, суперечки щодо ресурсів на хості або проблеми з базовою інфраструктурою зберігання чи мережі.
Якщо гостьова ОС виробляє будь-яку активність, вона успішно виконується. У цьому випадку відсутність відповіді, ймовірно, пов'язана з проблемою підключення або суперечкою про ресурси, або є специфічною для компонента вищого рівня, такого як програма або служба, запущена в гостьовій ОС.

Перевірте область видимості:
Важливо мати точну симптоматику і розуміння масштабів проблеми. Щоб підтвердити масштаб проблеми, виконайте такі перевірки:

  1. Переконайтеся, що віртуальна машина насправді не відповідає. Можливо, віртуальна машина не відповідає через один інтерфейс, але коректно функціонує на інших. 

  2. Переконайтеся, що віртуальну машину ввімкнено. Якщо віртуальна машина несподівано вимкнулася, увімкніть її знову, а потім усуньте причину несподіваного вимкнення.

  3. Визначте, чи стосується ця проблема кількох віртуальних машин чи лише однієї. Якщо уражено кілька віртуальних машин, враховуйте схожість між ураженими віртуальними машинами, намагаючись звузити потенційну область застосування. Зокрема, зосередьтеся на спільній інфраструктурі, від якої залежить група уражених віртуальних машин, і на тому, чи постраждали всі віртуальні машини, що залежать від цієї загальної інфраструктури. 

  4. Визначте, чи реагує гостьова ОС на взаємодію в консолі віртуальної машини. Якщо проблему було ізольовано для гостьової ОС або програм у віртуальній машині, а гостьова ОС реагує на консолі, взаємодійте з гостьовою ОС на консолі, щоб вирішити проблему. 

  5. Визначте, чи реагує гостьова ОС або її служби додатків на взаємодію через мережу.

  6. Визначте, чи гостьова ОС повідомила про будь-які критичні помилки консолі і чи перебуває вона в зупиненому стані.

  7. Визначте, чи не відповідає хост ESX/ESXi. Якщо вузол також не відповідає, область видимості буде більшою, ніж передбачалося спочатку.


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

  1. Визначте, чи викликана проблема операцією або завданням, що виконується на віртуальній машині. Наприклад, операції snapshot і vMotion оглушують віртуальну машину на короткі проміжки часу, поки стан пам'яті копіюється через мережу або на диск.

  2. Деякі поширені помилки конфігурації можуть призвести до того, що віртуальна машина перестане відповідати, наприклад, під час очікування ресурсу. Перегляньте конфігурацію віртуальної машини та хоста. 

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

  4. Віртуальні машини залежать від доступних ресурсів хоста (CPU, Memory), і гостьова ОС споживає ці ресурси. Проблема з доступністю ресурсів або плануванням всередині або за межами віртуальної машини може призвести до того, що вона перестане відповідати. Віртуальна машина також може блокуватися на недоступних ресурсах або обертатися при 100% завантаженні vCPU. 


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

  • Якщо проблему було ізольовано в гостьовій операційній системі, або %RUN є відносно високим, але монітор віртуальної машини функціонує коректно, перемістіть розслідування в гостьову ОС або програми віртуальної машини. Гостьова ОС може перестати відповідати всередині віртуальної машини так само, як і на фізичному обладнанні:

    1. Збирайте дані про продуктивність під час виникнення проблеми.

    2. Спробуйте вручну викликати паніку ядра всередині гостьової ОС для збору додаткової інформації про його внутрішній стан. Якщо гостьова ОС створює корисну діагностичну інформацію у відповідь на одну з цих подій, зверніться до постачальника гостьової ОС для подальшого дослідження.

    3. Якщо крок 2 не дав корисної інформації, призупиніть віртуальну машину для збору інформації про її внутрішній стан і відкрийте справу з VMware Support:

      1. Присипте віртуальну машину та зберіть .vmss призупинити файл стану.

      2. Збирайте логи з хоста, на якому запущена віртуальна машина.

      3. Знову ввімкніть віртуальну машину, а потім скиньте її.

      4. Залучіть службу підтримки VMware, надаючи інформацію, зібрану на кроках 1, 3a та 3b.

  • Якщо проблема була ізольована на моніторі віртуальної машини, або %WAIT є відносно високим, або спроби призупинити віртуальну машину не увінчалися успіхом, збирайте дані про продуктивність та примусово виводьте віртуальну машину з ладу, щоб зібрати додаткову інформацію про її внутрішній стан:

    1. Збирайте дані про продуктивність під час виникнення проблеми.

    2. Збій віртуальної машини, щоб зібрати інформацію про її внутрішній стан.

      ПРИМІТКА: Якщо спроби вивести з ладу віртуальну машину не вдалися, перейдіть до наступного розділу та спробуйте вибити хост.
    3. Залучіть службу підтримки VMware, надавши інформацію, зібрану на кроках 1 і 2.

  • Якщо проблема була ізольована на моніторі віртуальної машини, але спроби призупинити або завершити збій віртуальної машини зазнають невдачі, це відображає проблему з ядром віртуальної машини. Зберіть пакет журналів з хоста, евакуюйте всі неуражені віртуальні машини з хоста та використовуйте NMI для навмисної генерації фіолетового діагностичного екрана:

    1. Збирайте дані про продуктивність під час виникнення проблеми.

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

    3. Налаштуйте хост на паніку при отриманні переривання, яке не можна маскувати, а потім видайте NMI, щоб викликати паніку.

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

    5. Зберіть діагностичну інформацію від хоста.

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


Статті по темі
VMware KB 1007819: https://kb.vmware.com/kb/1007819 Значок стороннього посилання

Additional Information

Система VCE Увесь
Компонент vSphere

Products

VMware ESXi
Article Properties
Article Number: 000205776
Article Type: How To
Last Modified: 17 Dec 2024
Version:  3
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.