Зависает виртуальная машина vmware
Обновлено: 06.07.2024
Заметил одну неприятную особенность в гипервизоре VMWare Workstation. Если вы не используете виртуальную машину в течении некоторого времени, она автоматически приостанавливается функцией Suspend. Чтобы продолжить использование ВМ приходится нажимать кнопку Resume this virtual machine.
Функция автоматической приостановки (Suspend) в VMWare Workstation Player/ Fusion включена по умолчанию. Ее задача – экономия ресурсов хоста, которая автоматически замораживает состояние ВМ, не выключая ее полностью. Чтобы включить замороженную ВМ нужно несколько секунд, но лично мне эта функция мешает. Во-первых, это неудобно, если вы тестируете что-то на ВМ и ожидаете результатов процесса или скрипта; во-вторых, периодический Suspend ВМ и сброс состояния памяти на диск расходует ресурс SSD диска; в-третьих, я не хочу каждый раз ждать по несколько секунд пока VMWare Workstation возобновит работу ВМ.
Гипервизор может включить Suspend автоматически или, когда обнаружит что гостевая ОС переведена в спящее состояние. Например, в Windows 10 по умолчанию компьютер переводится в спящий режим через 30 минут неактивности (Control Panel\Hardware and Sound\Power Options\Edit Plan Settings -> Put the computer to sleep).
К сожалению, полностью отключить функцию Auto Suspend в настройках VMWare Workstation нельзя. Но вы можете в параметрах vmx файла конкретной ВМ запретить гипервизору переводить в состояние suspend.
Если ваша виртуальная машина, запущенная на хосте Hyper-V зависла по каким-то причинам, перестала отвечать, и не реагирует на кнопки включения, выключения, перезагрузки в консоли Hyper-V, единственный быстрый способ принудительно остановить такую машину — завершить процесс этой ВМ в хостовой ОС. Покажем, как принудительно перезагрузить ВМ в Hyper-V на Windows Server 2016/2019 без перезагрузки всего сервера и запущенных ВМ (если у вас нет HA кластера Hyper-V и Live-Migration).
Виртуальная машина Hyper-V зависла в статусе Stopping, Starting
Итак, предположим, что одна из ВМ на Hyper-V зависла в состоянии Stopping (Stopping-Critical)/ Starting (Starting 10%).
Гостевая ОС перестала отвечать, а кнопки “Turn Off”,” Shut Down” и” Reset” в консоли Hyper-V Manager стали недоступны либо при нажатии возвращают ошибку:
Ошибка Hyper-V: Connecting to Virtual Machine Management service
Завершение процесса зависшей ВМ с помощью Task Manager
Единственный способ принудительно выключить/ перезапустить такую зависшую виртуальную машину без перезагрузки всего хостового сервера Hyper-V – завершить ее рабочий процесс на гостевой ОС. Все ВМ на хосте Hyper-V запускаются с помощью процесса vmwp.exe (Virtual Machine Worker Process). Для поиска процесса нужно узнать GUID виртуальной машины.
Определить GUID ВМ можно через консоль управления Hyper—V Manager. Откройте настройки сервера (Hyper—V Settings). В разделе Server указано каталог, в котором хранятся конфигурационные файлов ВМ (в нашем примере D:\VMStore).
Откройте этот каталог в File Explorer и найдите каталог с именем зависшей виртуальной машины. Скопируйте GUID, который указан в имени конфигурационного файла ВМ с расширением *.vmcx.
Теперь нужно запустить диспетчер задач (Task Manager) и перейти на вкладку Details. Все виртуальные машины запускаются в рамках собственного экземпляра процесса vmwp.exe. Чтобы определить какой процесс за какую ВМ отвечает, нам нужен полученный ранее GUID зависшей ВМ. Найдите процесс vmwp.exe, у которого в столбце User name указан GUID вашей ВМ. Завершите данный процесс (End Task).
Виртуальная машина будет принудительно остановлена. Теперь вы сможете делать с ней все что угодно.
Сбросить зависшую ВМ на Hyper-V VM с помощью PowerShell
Гораздо проще найти и завершить процесс зависшей виртуальной машины с помощью PowerShell. Запустите консоль PowerShell с правами администратора (учетная запись должна состоять в локальной группе Hyper-V administrators).
В этом случае встроенный командлет Stop-VM не позволит вам выключить ВМ. Если попробовать выполнить команду Stop-VM –Force , она также зависает. Очевидно ожидает ответа от ВМ.В этом случае также нужно завершить процесс ВМ по ее ID. Можно получить GUID ВМ с по ее имени. Например, для ВМ с именем SVM-GUARDEDHOST1, выполните команду:
$VMGUID = (Get-VM "SVM-GUARDEDHOST1").ID
Get-VM | Select Name, Id
Скопируйте GUID нужной ВМ из полученного списка.
Теперь нужно найди идентификатор процесса (PID) ‘vmwp.exe’ для вашего VMGUID:
Затем с помощью команды Stop-Process нужно принудительно завершить этот процесс:
Stop-Process ($VMWMProc.ProcessId) –Force
Вот так несложно можно принудительно завершить рабочий процесс подвисшей виртуальной машины Hyper-V.
Совет. У нас также описана аналогичная процедура по завершению процесса зависшей ВМ на хосте VMWare ESXi.Hyper-V: Не удалось изменить состояние виртуальной машины
Иногда бывает, что даже после завершения зависшего процесса вы не можете включить ВМ и она зависает в статусе Starting с ошибкой:
В этом случае проверьте следующие варианты:
- Проверьте что на диске, на котором хранятся файлы ВМ достаточно свободного места;
- Если в настройках ВМ подключен ISO образ, проверьте его доступность;
- Проверьте сетевые настройки ВМ. Виртуальные сетевые адаптеры должны быть подключены к существующему виртуальному коммутатору Hyper-V (не должно быть статуса Network Adapter – Configuration Error);
- Проверьте, что служба Hyper-V Virtual Management Service (VMMS) запушена, и не зависла в статусе Stopping;
- Убедитесь, что ваш антивирус не блокирует доступ к файлам ВМ. Добавьте пути к каталогу ВМ в исключения антивируса ( см. как добавить исключения во встроенный антивирус Windows Server 2016 – Windows Defender);
- Проверьте ошибки в журнале событий Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> Hyper-V-Worker.
Описание проблемной виртуальной машины
Как я и писал выше, виртуальная машина намертво зависла, по RDP или ping она была не доступна. Гостевой операционной системой была Windows Server 2012 R2. Попытавшись запустить Web Console из интерфейса vCenter Server, виртуальная машина ни на что не реагировала.
Диагностика зависшей виртуальной машины
Первым делом, чтобы восстановить сервис, вам необходимо принудительно перезагрузить виртуальную машины, для этого щелкните по ней правым кликом мыши и выберите пункт "Power - Reset".
После того, как операционная система в ней загрузится, я вам советую начать изучение логов Windows. Открываем просмотр событий и делаем поиск ошибок и предупреждений. Мне удалось найти два события, которые косвенно говорили, что проблема с зависанием виртуальной машины связана непосредственно с операционной системой и возможными проблемами с поврежденными системными файлами или драйверами Vmware Tools. Первое событие:
Event ID 11: The driver detected a controller error on \Device\RaidPort0
Так же можно обнаружить и ошибки вот такого рода, которые так же заставляю виртуальную машину флапать, зависать с черным экраном.
Код события ID 27 Intel(R) 82574L Gigabit Network ConnectionNetwork link is disconnected.
Данное событие связано с сетевым интерфейсом типа E1000, советую его поменять на паравиртуализованный VMXNET3. E1000 кушает больше ресурсов процессорных мощностей и так же более капризный, но за то не требует установки Vmware Tools.
Так же вы можете посмотреть логи самой виртуальной машины на уровне Vmware ESXI 6.5. Я нашел там вот такую выборку:
2019-05-14T11:06:41.739Z| vmx| I125: GuestMsg: Channel 0, Cannot unpost because the previous post is already completed2019-05-14T11:08:48.012Z| svga| I125: MKSScreenShotMgr: Taking a screenshot
2019-05-14T11:08:53.849Z| mks| I125: SOCKET 1396535 (189) Creating VNC remote connection.
2019-05-14T11:08:53.849Z| mks| I125: MKSControlMgr: New VNC connection 1
2019-05-14T11:08:53.912Z| mks| W115: VNCENCODE 1396535 failed to allocate VNCBlitDetect
2019-05-14T11:08:53.912Z| mks| I125: VNCENCODE 1396535 VNCEncodeChooseRegionEncoder: region encoder adaptive. Resolution: 1024 x 768
2019-05-14T11:08:54.289Z| vmx| I125: Tools_SetGuestResolution: Sending rpcMsg = Resolution_Set 1920 863
2019-05-14T11:08:54.630Z| vcpu-7| I125: VMMouse: CMD Read ID
2019-05-14T11:09:54.289Z| vmx| I125: GuestRpcSendTimedOut: message to toolbox timed out.
2019-05-14T11:10:07.476Z| svga| I125: MKSScreenShotMgr: Taking a screenshot
2019-05-14T11:10:19.546Z| mks| I125: SOCKET 1396535 (189) recv error 0: Success
2019-05-14T11:10:19.546Z| mks| I125: SOCKET 1396535 (189) VNC Remote Disconnect.
2019-05-14T11:10:19.546Z| mks| I125: MKSControlMgr: Remove VNC connection 1
2019-05-14T11:10:31.357Z| vmx| I125: VigorTransportProcessClientPayload: opID=HardPowerOpsResolver-applyOnMultiEntity-5384149-ngc:70276545-fb-c5-9d61 seq=2571570: Receiving Sched.SetResourceGroup request.
2019-05-14T11:10:31.357Z| vmx| I125: VigorTransport_ServerSendResponse opID=HardPowerOpsResolver-applyOnMultiEntity-5384149-ngc:70276545-fb-c5-9d61 seq=2571570: Completed Sched request.
2019-05-14T11:10:31.358Z| vmx| I125: VigorTransportProcessClientPayload: opID=HardPowerOpsResolver-applyOnMultiEntity-5384149-ngc:70276545-fb-c5-9d61 seq=2571571: Receiving PowerState.InitiateReset request.
2019-05-14T11:10:31.358Z| vmx| I125: Vix: [8790361 vmxCommands.c:686]: VMAutomation_Reset. Trying hard reset
2019-05-14T11:10:31.358Z| vmx| W115:
2019-05-14T11:10:31.358Z| vmx| W115+
2019-05-14T11:10:31.358Z| vmx| W115+ VMXRequestReset
2019-05-14T11:10:31.358Z| vmx| I125: Vigor_Reset: Attaching to reset.
2019-05-14T11:10:31.358Z| vmx| I125: Stopping VCPU threads.
2019-05-14T11:10:31.360Z| vcpu-0| I125: VMMon_WaitForExit: vcpu-0: worldID=9507337
2019-05-14T11:10:31.360Z| vcpu-7| I125: VMMon_WaitForExit: vcpu-7: worldID=9507347
2019-05-14T11:10:31.360Z| vcpu-3| I125: VMMon_WaitForExit: vcpu-3: worldID=9507343
2019-05-14T11:10:31.360Z| vcpu-1| I125: VMMon_WaitForExit: vcpu-1: worldID=9507341
2019-05-14T11:10:31.360Z| vcpu-5| I125: VMMon_WaitForExit: vcpu-5: worldID=9507345
2019-05-14T11:10:31.360Z| vcpu-10| I125: VMMon_WaitForExit: vcpu-10: worldID=9507350
2019-05-14T11:10:31.360Z| vcpu-9| I125: VMMon_WaitForExit: vcpu-9: worldID=9507349
2019-05-14T11:10:31.360Z| vcpu-8| I125: VMMon_WaitForExit: vcpu-8: worldID=9507348
2019-05-14T11:10:31.360Z| vcpu-6| I125: VMMon_WaitForExit: vcpu-6: worldID=9507346
2019-05-14T11:10:31.360Z| vcpu-4| I125: VMMon_WaitForExit: vcpu-4: worldID=9507344
2019-05-14T11:10:31.360Z| vcpu-2| I125: VMMon_WaitForExit: vcpu-2: worldID=9507342
2019-05-14T11:10:31.360Z| vcpu-11| I125: VMMon_WaitForExit: vcpu-11: worldID=9507351
2019-05-14T11:10:31.360Z| svga| I125: SVGA thread is exiting
2019-05-14T11:10:31.360Z| vmx| I125: MKS thread is stopped
2019-05-14T11:10:31.361Z| vmx| I125:
2019-05-14T11:10:31.361Z| vmx| I125+ OvhdMem: Final (Power Off) Overheads
Алгоритм действий и возможные причины зависания
- Первое, что я вам советую сделать, это избавится от ошибки "Vmware Tools is outdated on this virtual machine" путем обновления Vmware Tools. Напоминаю, что это сделать можно из меню "Guest OS - Update Vmware Tools". Потребуется перезагрузка виртуальной машины.
- Следующим пунктом, я вам советую проверить операционную систему на предмет повреждения системных файлов, сделать это просто. Запустите cmd от имени администратора или откройте Power Shell, кому что привычнее и введите команду:
Если ошибки не были устранены, то советую выполнить команду:
Утилита DISM обратится к внешним репозиториям Microsoft и скачает от туда валидные файлы, чтобы восстановить аналогичные в вашей системе. Процесс так же может занимать некоторое время. Как видим:
Восстановление выполнено успешно. Повреждение хранилище компонентов было устранено. Операция успешно завершена.
Еще одним пунктом диагностики проблем с ошибками ID 111 и ID 129, я вам советую выполнить сканирование ваших дисков на предмет ошибок. Для этого есть два варианта, старая добрая утилита командной строки ChkDsk и ее графический аналог в свойствах диска "Проверка диска на наличие ошибок файловой системы"
Для проверки локальных дисков через командную строку, вы можете воспользоваться командой:
Ключ /f указывает утилите исправлять ошибки на диске, флаг /R обязывает CHDSK искать на диске повреждённые сектора, и попытаться восстановить данные на них. Если диск системный, то вас попросят перезагрузиться, и проверка диска будет перед загрузкой системы.
Невозможно выполнить команду CHKDSK, так как указанный том используется другим процессом. Следует ли выполнить проверку этого тома при следующей перезагрузке системы? [Y(да)/N(нет)]
То же самое вы можете сделать и в свойствах локального диска, для этого щелкните по нему правым кликом и перейдите в его свойства. Найдите там вкладку "Сервис" и на ней пункт "Проверка диска на наличие ошибок файловой системы". Нажмите проверить.
В новом окне нажимаем "Проверить диск".
Будет запущен процесс сканирования диска, обычно он занимает не много времени.
После чего вы получите результат. В моем случае я вижу, что "Диск успешно проверен".
Ранее установленный софт
Очень часто причиной зависания виртуальной машины на ESXI 6.5 выступает недавняя установка обновлений в системе или различного рода программного обеспечения. Обязательно посмотрите в "Панель управления\Все элементы панели управления\Программы и компоненты" по дате установки, что недавно было проинсталлировано.
Тут же можно посмотреть установленные обновления. Недавно Microsoft выпустило обновление KB4015553 (Со временем может меняться), которое в Windows Server 2012 R2 стало вызывать зависание. Необходимо удалить KB4015553, kb4019215 и kb4019217, перезагрузить ваш сервер.
Сама компания Symantec рекомендует в ветке (https://support.symantec.com/en_US/article.TECH236543.html) Исключите из проверки следующий каталог, включая все подкаталоги: путь зависит от вашей версии SEP: "C:\ProgramData\Symantec\Symantec Endpoint Protection\<версия>\Data\Definitions". Пример для SEP 14.0 MP1: C:\ProgramData\Symantec\Symantec Endpoint Protection\14.0.2332.0100.105\Data\Definitions. Если вышеуказанное исключение не решает проблему, также исключите следующий каталог: C:\Windows\rescache.
Эти пути могут отличаться в зависимости от сборки продукта или от того, что каталоги ProgramData или Windows были перемещены на другой диск.Сделать, это можно в "Change Settings - Exception - SONAR Exception" нажимаем кнопку "Add" и выбираем нужные каталоги.
Описание проблемы
The virtual machine might be performing concurrent operations. Actions: Complete the concurrent operation and retry the power-off operation. The virtual machine is in an invalid state. Virtual machines can enter an invalid state for many reasons.
При попытке мигрировать виртуальную машину вы может получить ошибку:
Failed to migrate the virtual machine for reasons described it the event message
Так же вы можете увидеть ошибку при попытке, выключить или перезапустить виртуалку:
Во всех случаях вам скажут, что данная виртуальная машина имеет некий процесс, который в данный момент не дает выполнить ваши повторные действия. Так же данная виртуалка у меня была членом RDS фермы, при попытке перевода его в режим стока (Drain-Mode) я получил ошибку "Не удалось изменить состояние подключения для сервера".
Как перезапустить зависшую виртуальную машину
Сразу хочу отметить, что если в графическом интерфейсе у вас не выходит, что либо сделать, то у вас остается только командная строка ssh. Включаем на ESXI хосте SSH службу. Далее подключаемся через Putty или MremoteNG. Я подключаюсь через MremoteNG. Первое, что вам необходимо сделать, это как посмотреть список активных процессов, все как в Windows. Для этого есть команда:
В моем примере, я вижу свою виртуальную машину TERM6. Если системные процессы мозолят вам глаза, то вы можете одновременно нажать SHIFT+V, что оставит отображение только виртуальных машин.
Теперь нам нужно вычислить LWID - Leader World Id, завершив который вы завершите работу нужной виртуалки. ПО умолчанию LWID не отображается, чтобы его включить нажмите клавишу F. У вас откроется меню, где можно добавлять или скрывать поля. Видим, что если нажать клавишу "C", то у вас будет добавлен LWID- Leader World Id. Нажимаем "C" и "Enter".
Теперь зная LWID, нажмите клавишу "K", она вызовет меню "World to kill (WID)", данная операция поможет принудительно завершить процесс LWID. Вбиваем наш LWID и нажимаем "Enter".
Тут у вас два варианта, чудо произошло (80% вероятности) и чудо не произошло, часто бывает в случаях с ошибкой "Another task is already in progress"
Кстати World ID можно вычисли и просто введя команду:
Там вы сможете увидеть World ID, после чего его можно убить командой:
В моем случае чудо произошло, виртуалка перешла в состояние Power OFF, я это вижу в Power-CLI.
Если принудительное завершение процесса вам не помогло, то делаем вот что, по возможности мигрируйте все остальные виртуальные машины с данного хоста, у вас из-за ошибки останется только сбойная. Все в том же SSH. введите:
В итоге у вас будет выведен список, где первая колонка это PID процесса, вторая PID родительского процесса, убиваем его для вашей виртуальной машины.
После чего пишем kill PID-родительского процесса. Если не помогло, то пробуем выполнить вот, что (по возможности перевезите другие сервера с данного хоста на другие хосты)
В результате действий хост стал работать нормально, единственное может быть ситуация, что виртуалку придется удалить из inventory и добавить заново. Если и это не помогло, то попробуйте выполнить:
/etc/ init . d / hostd restart && /etc/ init . d / vpxa restartВисит задача create virtual machine snapshot
Еще в своей практике встречал ситуации, что из-за незаконченного задания у меня не выполнялось резервное копирование, задание висело со статусом "create virtual machine snapshot"
Читайте также: