Microsoft windows hyper v vmms

Время на прочтение
11 мин

Количество просмотров 108K

Всем занять свои места! Задраить люки! Приготовиться к погружению!
В этой статье я попытаюсь рассказать об архитектуре Hyper-V еще подробнее, чем я сделал это ранее.

Что же такое – Hyper-V?

Hyper-V – это одна из технологий виртуализации серверов, позволяющая запускать на одном физическом сервере множество виртуальных ОС. Эти ОС именуются «гостевыми», а ОС, установленная на физическом сервере – «хостовой». Каждая гостевая операционная система запускается в своем изолированном окружении, и «думает», что работает на отдельном компьютере. О существовании других гостевых ОС и хостовой ОС они «не знают».
Эти изолированные окружения именуются «виртуальными машинами» (или сокращенно — ВМ). Виртуальные машины реализуются программно, и предоставляют гостевой ОС и приложениям доступ к аппаратным ресурсам сервера посредством гипервизора и виртуальных устройств. Как уже было сказано, гостевая ОС ведет себя так, как будто полностью контролирует физический сервер, и не имеет представления о существовании других виртуальных машин. Так же эти виртуальные окружения могут именоваться «партициями» (не путать с разделами на жестких дисках).
Впервые появившись в составе Windows Server 2008, ныне Hyper-V существует в виде самостоятельного продукта Hyper-V Server (де-факто являющегося сильно урезанной Windows Server 2008), и в новой версии – R2 – вышедшего на рынок систем виртуализации Enterprise-класса. Версия R2 поддерживает некоторые новые функции, и речь в статье пойдет именно об этой версии.

Гипервизор

Термин «гипервизор» уходит корнями в 1972 год, когда компания IBM реализовала виртуализацию в своих мэйнфреймах System/370. Это стало прорывом в ИТ, поскольку позволило обойти архитектурные ограничения и высокую цену использования мэйнфреймов.
Гипервизор – это платформа виртуализации, позволяющая запускать на одном физическом компьютере несколько операционных систем. Именно гипервизор предоставляет изолированное окружение для каждой виртуальной машины, и именно он предоставляет гостевым ОС доступ к аппаратному обеспечению компьютера.
Гипервизоры можно разделить на два типа по способу запуска (на «голом железе» или внутри ОС) и на два типа по архитектуре (монолитная и микроядерная).

Гипервизор 1 рода

Гипервизор 1 типа запускается непосредственно на физическом «железе» и управляет им самостоятельно. Гостевые ОС, запущенные внутри виртуальных машин, располагаются уровнем выше, как показано на рис.1.

Рис.1 Гипервизор 1 рода запускается на «голом железе».

Работа гипервизоров 1 рода непосредственно с оборудованием позволяет достичь большей производительности, надежности и безопасности.
Гипервизоры 1 рода используются во многих решениях Enterprise-класса:

• Microsoft Hyper-V
• VMware ESX Server
• Citrix XenServer

Гипервизор 2 рода

В отличие от 1 рода, гипервизор 2 рода запускается внутри хостовой ОС (см. рис.2).

Рис.2 Гипервизор 2 рода запускается внутри гостевых ОС

Виртуальные машины при этом запускаются в пользовательском пространстве хостовой ОС, что не самым лучшим образом сказывается на производительности.
Примерами гипервизоров 2 рода служат MS Virtual Server и VMware Server, а так же продукты десктопной виртуализации – MS VirtualPC и VMware Workstation.

Монолитный гипервизор

Гипервизоры монолитной архитектуры включают драйверы аппаратных устройств в свой код (см. рис. 3).

Рис. 3. Монолитная архитектура

Монолитная архитектура имеет свои достоинства и недостатки. Среди достоинств можно отметить:

• Более высокую (теоретически) производительность из-за нахождения драйверов в пространстве гипервизора
• Более высокую надежность, так как сбои в работе управляющей ОС (в терминах VMware – «Service Console») не приведет к сбою всех запущенных виртуальных машин.

Недостатки же у монолитной архитектуры следующие:

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

Самым распространенным примером монолитной архитектуры является VMware ESX.

Микроядерная архитектура

При микроядерной архитектуре драйверы устройств работают внутри хостовой ОС.
Хостовая ОС в этом случае запускается в таком же виртуальном окружении, как и все ВМ, и именуется «родительской партицией». Все остальные окружения, соответственно – «дочерние». Единственная разница между родительской и дочерними партициями состоит в том, что только родительская партиция имеет непосредственный доступ к оборудованию сервера. Выделением памяти же и планировкой процессорного времени занимается сам гипервизор.

Рис. 4. Микроядерная архитектура

Достоинства у такой архитектуры следующие:

• Не требуются драйвера, «заточенные» под гипервизор. Гипервизор микроядерной архитектуры совместим с любым оборудованием, имеющим драйверы для ОС родительской партиции.
• Поскольку драйверы выполняются внутри родительской партиции – у гипервизора остается больше времени на более важные задачи – управление памятью и работу планировщика.
• Более высокая безопасность. Гипервизор не содержит постороннего кода, соответственно и возможностей для атаки на него становится меньше.

Самым ярким примером микроядерной архитектуры является, собственно, сам Hyper-V.

Архитектура Hyper-V

На рис.5 показаны основные элементы архитектуры Hyper-V.

Рис.5 Архитектура Hyper-V

Как видно из рисунка, гипервизор работает на следующем уровне после железа – что характерно для гипервизоров 1 рода. Уровнем выше гипервизора работают родительская и дочерние партиции. Партиции в данном случае – это области изоляции, внутри которых работают операционные системы. Не нужно путать их, к примеру, с разделами на жестком диске. В родительской партиции запускается хостовая ОС (Windows Server 2008 R2) и стек виртуализации. Так же именно из родительской партиции происходит управление внешними устройствами, а так же дочерними партициями. Дочерние же партиции, как легко догадаться – создаются из родительской партиции и предназначены для запуска гостевых ОС. Все партиции связаны с гипервизором через интерфейс гипервызовов, предоставляющий операционным системам специальный API. Если кого-то из разработчиков интересуют подробности API гипервызовов — информация имеется в MSDN.

Родительская партиция

Родительская партиция создается сразу же при установке системной роли Hyper-V. Компоненты родительской партиции показаны на рис. 6.
Назначение родительской партиции следующее:

• Создание, удаление и управление дочерними партициями, в том числе и удаленное, посредством WMI-провайдера.
• Управление доступом к аппаратным устройствам, за исключением выделения процессорного времени и памяти – этим занимается гипервизор.
• Управление питанием и обработка аппаратных ошибок, если таковые возникают.

Рис.6 Компоненты родительской партиции Hyper-V

Стек виртуализации

Следующие компоненты, работающие в родительской партиции, в совокупности называют стеком виртуализации:

• Служба управления виртуальными машинами (VMMS)
• Рабочие процессы виртуальных машин (VMWP)
• Виртуальные устройства
• Драйвер виртуальной инфраструктуры (VID)
• Библиотека интерфейсов гипервизора

Помимо этого, в родительской партиции работают еще два компонента. Это провайдеры служб виртуализации (VSP) и шина виртуальных машин (VMBus).
Служба управления виртуальными машинами
В задачи службы управления виртуальными машинами (VMMS) входит:

• Управление состоянием виртуальных машин (включено/выключено)
• Добавление/удаление виртуальных устройств
• Управление моментальными снимками

При запуске виртуальной машины VMMS создает новый рабочий процесс виртуальной машины. Подробнее о рабочих процессах будет рассказано далее.
Так же именно VMMS определяет, какие операции разрешено выполнять с виртуальной машиной в настоящий момент: к примеру, если происходит удаление снапшота, то применить снапшот в течение операции удаления она не даст. Подробнее о работе с моментальными снимками (снапшотами) виртуальных машин можно почитать в соответствующей моей статье.
Если говорить более детально – то VMMS управляет следующими состояниями виртуальных машин:

• Starting
• Active
• Not Active
• Taking Snapshot
• Applying Snapshot
• Deleting Snapshot
• Merging Disk

Другие задачи управления – Pause, Save и Power Off – выполняются не службой VMMS, а непосредственно рабочим процессом соответствующей виртуальной машины.
Служба VMMS работает как на уровне пользователя, так и на уровне ядра как системная служба (VMMS.exe) и зависит от служб Remote Procedure Call (RPC) и Windows Management Instrumentation (WMI). Служба VMMS включает в себя множество компонент, среди которых имеется и WMI-провайдер, предоставляющий интерфейс для управления виртуальными машинами. Благодаря этому можно управлять виртуальными машинами из командной строки и с помощью скриптов VBScript и PowerShell. System Center Virtual Machine Manager так же использует этот интерфейс для управления виртуальными машинами.

Рабочий процесс виртуальной машины (VMWP)

Для управления виртуальной машиной из родительской партиции запускается особый процесс – рабочий процесс виртуальной машины (VMWP). Процесс этот работает на уровне пользователя. Для каждой запущенной виртуальной машины служба VMMS запускает отдельный рабочий процесс. Это позволяет изолировать виртуальные машины друг от друга. Для повышения безопасности, рабочие процессы запускаются под встроенным пользовательским аккаунтом Network Service.
Процесс VMWP используется для управления соответствующей виртуальной машиной. В его задачи входит:
Создание, конфигурация и запуск виртуальной машины
Пауза и продолжение работы (Pause/Resume)
Сохранение и восстановление состояния (Save/Restore State)
Создание моментальных снимков (снапшотов)
Кроме того, именно рабочий процесс эмулирует виртуальную материнскую плату (VMB), которая используется для предоставления памяти гостевой ОС, управления прерываниями и виртуальными устройствами.

Виртуальные устройства

Виртуальные устройства (VDevs) – это программные модули, реализующие конфигурацию и управление устройствами для виртуальных машин. VMB включает в себя базовый набор виртуальных устройств, включающий в себя шину PCI и системные устройства, идентичные чипсету Intel 440BX. Есть два типа виртуальных устройств:

• Эмулируемые устройства – эмулируют определенные аппаратные устройства, такие, к примеру, как видеоадаптер VESA. Эмулируемых устройств достаточно много, к примеру: BIOS, DMA, APIC, шины ISA и PCI, контроллеры прерываний, таймеры, управление питанием, контроллеры последовательных портов, системный динамик, контроллер PS/2 клавиатуры и мыши, эмулируемый (Legacy) Ethernet-адаптер (DEC/Intel 21140), FDD, IDE-контроллер и видеоадаптер VESA/VGA. Именно поэтому для загрузки гостевой ОС может использоваться только виртуальный IDE-контроллер, а не SCSI, который является синтетическим устройством.
• Синтетические устройства – не эмулируют реально существующие в природе железки. Примерами служат синтетический видеоадаптер, устройства взаимодействия с человеком (HID), сетевой адаптер, SCSI-контроллер, синтетический контроллер прерывания и контроллер памяти. Синтетические устройства могут использоваться только при условии установки компонент интеграции в гостевой ОС. Синтетические устройства обращаются к аппаратным устройствам сервера посредством провайдеров служб виртуализации, работающих в родительской партиции. Обращение идет через виртуальную шину VMBus, что намного быстрее, чем эмуляция физических устройств.

Драйвер виртуальной инфраструктуры (VID)

Драйвер виртуальной инфраструктуры (vid.sys) работает на уровне ядра и осуществляет управление партициями, виртуальными процессорами и памятью. Так же этот драйвер является промежуточным звеном между гипервизором и компонентами стека виртуализации уровня пользователя.

Библиотека интерфейса гипервизора

Библиотека интерфейса гипервизора (WinHv.sys) – это DLL уровня ядра, которая загружается как в хостовой, так и в гостевых ОС, при условии установки компонент интеграции. Эта библиотека предоставляет интерфейс гипервызовов, использующийся для взаимодействия ОС и гипервизора.

Провайдеры служб виртуализации (VSP)

Провайдеры служб виртуализации работают в родительской партиции и предоставляют гостевым ОС доступ к аппаратным устройствам через клиент служб виртуализации (VSC). Связь между VSP и VSC осуществляется через виртуальную шину VMBus.

Шина виртуальных машин (VMBus)

Назначение VMBus состоит в предоставлении высокоскоростного доступа между родительской и дочерними партициями, в то время как остальные способы доступа значительно медленнее из-за высоких накладных расходах при эмуляции устройств.
Если гостевая ОС не поддерживает работу интеграционных компонент – приходится использовать эмуляцию устройств. Это означает, что гипервизору приходится перехватывать вызовы гостевых ОС и перенаправлять их к эмулируемым устройствам, которые, напоминаю, эмулируются рабочим процессом виртуальной машины. Поскольку рабочий процесс запускается в пространстве пользователя, использование эмулируемых устройств приводит к значительному снижению производительности по сравнению с использованием VMBus. Именно поэтому рекомендуется устанавливать компоненты интеграции сразу же после установки гостевой ОС.
Как уже было сказано, при использовании VMBus взаимодействие между хостовой и гостевой ОС происходит по клиент-серверной модели. В родительской партиции запущены провайдеры служб виртуализации (VSP), которые являются серверной частью, а в дочерних партициях – клиентская часть – VSC. VSC перенаправляет запросы гостевой ОС через VMBus к VSP в родительской партиции, а сам VSP переадресовывает запрос драйверу устройства. Этот процесс взаимодействия абсолютно прозрачен для гостевой ОС.

Дочерние партиции

Вернемся к нашему рисунку с архитектурой Hyper-V, только немного сократим его, поскольку нас интересуют лишь дочерние партиции.

Рис. 7 Дочерние партиции

Итак, в дочерних партициях могут быть установлены:

• ОС Windows, с установленными компонентами интеграции (в нашем случае – Windows 7)
• ОС не из семейства Windows, но поддерживающая компоненты интеграции (Red Hat Enterprise Linux в нашем случае)
• ОС, не поддерживающие компоненты интеграции (например, FreeBSD).

Во всех трех случаях набор компонент в дочерних партициях будет немного различаться.

ОС Windows с установленными компонентами интеграции

Операционные системы Microsoft Windows, начиная с Windows 2000 поддерживают установку компонент интеграции. После установки Hyper-V Integration Services в гостевой ОС запускаются следуюшие компоненты:

• Клиенты служб виртуализации. VSC представляют собой синтетические устройства, позволяющие осуществлять доступ к физическим устройствам посредством VMBus через VSP. VSC появляются в системе только после установки компонент интеграции, и позволяют использовать синтетические устройства. Без установки интеграционных компонент гостевая ОС может использовать только эмулируемые устройства. ОС Windows 7 и Windows Server 2008 R2 включает в себя компоненты интеграции, так что их не нужно устанавливать дополнительно.
• Улучшения. Под этим имеются в виду модификации в коде ОС чтобы обеспечить работу ОС с гипервизором и тем самым повысить эффективность ее работы в виртуальной среде. Эти модификации касаются дисковой, сетевой, графической подсистем и подсистемы ввода-вывода. Windows Server 2008 R2 и Windows 7 уже содержат в себе необходимые модификации, на другие поддерживаемые ОС для этого необходимо установить компоненты интеграции.

Так же, компоненты интеграции предоставляют следующий функционал:

• Heartbeat – помогает определить, отвечает ли дочерняя партиция на запросы из родительской.
• Обмен ключами реестра – позволяет обмениваться ключами реестра между дочерней и родительской партицией.
• Синхронизация времени между хостовой и гостевой ОС
• Завершение работы гостевой ОС
• Служба теневого копирования томов (VSS), позволяющая получать консистентные резервные копии.

ОС не из семейства Windows, но поддерживающая компоненты интеграции

Существуют так же ОС, не относящиеся к семейству Windows, но поддерживающие компоненты интеграции.На данный момент – это только SUSE Linux Enterprise Server и Red Hat Enterprise Linux. Такие ОС при установке компонент интеграции используют VSC сторонних разработчиков для взаимодействия с VSC по VMBus и доступа к оборудованию. Компоненты интеграции для Linux разработаны компанией Microsoft совместно с Citrix и доступны для загрузки в Microsoft Download Center. Поскольку компоненты интеграции для Linux были выпущены под лицензией GPL v2, ведутся работы по интеграции их в ядро Linux через Linux Driver Project, что позволит значительно расширить список поддерживаемых гостевых ОС.

Вместо заключения

На этом я, пожалуй, закончу свою вторую статью, посвященную архитектуре Hyper-V. Предыдущая статья вызвала у некоторых читателей вопросы, и надеюсь, что теперь я на них ответил.
Надеюсь, что чтение не было слишком скучным. Я достаточно часто использовал «академический язык», но это было необходимо, поскольку тематика статьи предполагает очень большой объем теории и практически нуль целых нуль десятых практики.

Выражаю огромную благодарность Mitch Tulloch и Microsoft Virtualization Team. На основе их книги Understanding Microsoft Virtualization Solutions и была подготовлена статья.

Если ваша виртуальная машина, запущенная на хосте Hyper-V зависла по каким-то причинам, перестала отвечать, и не реагирует на кнопки включения, выключения, перезагрузки в консоли Hyper-V Manager, единственный быстрый способ принудительно остановить такую машину — завершить процесс этой ВМ в хостовой ОС. Вы можете принудительно перезапустить конкретную ВМ в Hyper-V на Windows Server 2022/2019/2016 (или бесплатного Hyper-V Server) без перезагрузки всего сервера и запущенных на нем виртуальных машин (полезно, если у вас нет HA кластера Hyper-V и Live-Migration).

Виртуальная машина Hyper-V зависла в статусе Stopping или Starting

Администраторы Hyper-V периодически сталкиваются с ситуациями, когда что одна из ВМ на хосте Hyper-V зависает в состоянии Stopping (Stopping-Critical), Starting (Starting 10%) или Backing up.

При этом гостевая ОС перестаёт отвечать, и кнопки “Turn Off”,” Shut Down” и” Reset” вв консоли Hyper-V Manager становиться недоступны или при нажатии возвращают ошибку:

Failed to change state
The operation cannot be performed while the object is in its current state

Если ваш хост Hyper-V не показывает список зарегистрированных виртуальных машин в консоли Hyper-V Manager и возвращает ошибку “Connecting to Virtual Machine Management service”, вам нужно перезапустить процесс vmms.exe (служба Hyper-V Virtual Machine Management). Это безопасная операция, которая не прервет работу запушенных виртуальных машин. Проще всего перезапустить процесс службы vmms через консоль
services.msc
или PowerShell командой:

Get-Service vmms | Restart-Service

Как завершите процесс зависшей виртуальной машины Hyper-V?

Чтобы принудительно выключить/ перезапустить зависшую виртуальную машину без перезагрузки всего хостового сервера Hyper-V, нужно завершить ее рабочий процесс на гостевой ОС. Все ВМ на хосте Hyper-V запускаются с помощью процесса vmwp.exe (Virtual Machine Worker Process). Для поиска конкретного PID процесса нужно узнать 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 с помощью утилиты Process Explorer.

1. Запустите Process Explorer с правами администратора и нажмите Find Handle or DLL (или нажмите Ctrl-F );
2. В строке поиска укажите путь к виртуальному диску зависшей виртуальной машину (*.vhdx);
3. Process Explorer выведет все процессы, которые используются VHDX файл виртуальной машины;
4. Найдите процесс виртуальной машину vmwp.exe и завершите его.

Виртуальная машина будет принудительно остановлена. Теперь вы сможете делать с ней все что угодно.

Выключить зависшую ВМ на Hyper-V с помощью PowerShell

Гораздо проще найти и завершить процесс зависшей виртуальной машины с помощью PowerShell. Запустите консоль PowerShell с правами администратора (учетная запись должна состоять в локальной группе Hyper-V administrators).

Вы также можете завершить процесс ВМ по ее VM ID. Можно получить GUID ВМ по ее имени. Например, для ВМ с именем SVM-GUARDEDHOST1, выполните команду:

$VMGUID = (Get-VM "SVM-GUARDEDHOST1").ID

Скопируйте VMID нужной вам ВМ из полученного списка.

Теперь нужно найти идентификатор процесса (PID) ‘vmwp.exe’ для вашего VMGUID:

$VMWMProc = (Get-WmiObject Win32_Process | ? {$_.Name -match 'VMWP' -and $_.CommandLine -match $VMGUID})

Затем нужно принудительно завершить рабочий процесс подвисшей виртуальной машины Hyper-V с помощью команды Stop-Process:

Stop-Process ($VMWMProc.ProcessId) –Force

Виртуальная машина Hyper-V зависает при резервном копировании

При выполнении резервного копирования ВМ на хосте Hyper-V вы можете столкнуться с зависанием виртуальной машины Hyper-V в состоянии Running и статусом Backing up. При этом вы не можете остановить или запустить ВМ через Hyper-V Manager.

Если вы не хотите перезагружать хост Hyper-V, проверьте сначала состояние службу «Microsoft Hyper-V VSS Writer»:

vssadmin list writers

Убедитесь, что команда не вернула ошибку. Значит нужно перезапустить службу «Hyper-V Virtual Machine Management» с помощью команды PowerShell:

Get-service vmms | stop-process 

Убедитесь, что процесс vmms.exe завершен. Если нет, завершите его принудительно:

Get-Process | Where-Object { $_.ProcessName -eq 'vmms' } | Stop-Process

Теперь можно запустить службу Hyper-V:

Start-Service vmms 

Перезапуск службы Virtual Machine Management должно сбросить состояние VSS Writer для Hyper-V.

Hyper-V: Не удалось изменить состояние виртуальной машины

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

Virtual Machine Connection
Не удалось изменить состояние.
Failed to Change State.

В этом случае проверьте следующие варианты:

• Проверьте что на диске, на котором хранятся файлы ВМ достаточно свободного места;
• Если в настройках ВМ подключен ISO образ, проверьте этот файл доступен;
• Проверьте сетевые настройки ВМ. Виртуальные сетевые адаптеры должны быть подключены к существующему виртуальному коммутатору Hyper-V (не должно быть статуса Network Adapter – Configuration Error);
• Проверьте, что служба Hyper-V Virtual Management Service (VMMS) запушена, и не зависла в статусе Stopping;
• Убедитесь, что ваш антивирус не блокирует доступ к файлам ВМ. Добавьте пути к каталогу с виртуальными машинами в исключения антивируса ( см. как добавить исключения во встроенный антивирус Windows Defender в Windows Server);
• Проверьте ошибки в журнале событий Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> Hyper-V-Worker;
• Отключите режим сна и гибернации в гостевых операционных системах виртуальных машин. В Windows спящий режим отключается через Control Panel –>Power Options -> Change plan settings -> Put the computer to sleep -> Never. Чтобы отключить спящий режим в гостевой ОС с Ubuntu Linux, выполните команду:
  systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

Если методы, описанные выше, не помогли, похоже, что вам придется перезагрузить весь хост Hyper-V.

После установки некоторых обновлений касающихся работы Hyper-V на некоторых хостах виртуализации в журнале роли Hyper-V можно обнаружить ошибку с кодом 19510, фиксирующуюся каждые 5 минут:

Log Name:      Microsoft-Windows-Hyper-V-VMMS-Admin
Source:        Microsoft-Windows-Hyper-V-VMMS
Date:          11.02.2016 10:18:32
Event ID:      19510
Level:         Error     
User:          SYSTEM
Computer:      KOM-AD01-VM10.holding.com
Description:
The Integration Services Setup Disk image could not be updated: The process cannot access the file because it is being used by another process. (0x80070020).

Причиной появления такой ошибки может стать наличие подмонтированного образа компонент интеграции (%SystemRoot%\System32\vmguest.iso) на одной или нескольких виртуальных машинах хоста. Чтобы быстро отловить такие машины выполним PS-команду:

Get-VMDvdDrive -VMName * | Where {$_.Path -like "*\vmguest.iso"}

Как видим, в нашем случае на одной из виртуальных машин действительно подмонтирован диск с компонентами интеграции. Отключить его использование можно либо через консоль Hyper-V Manager в свойствах соответствующей виртуальной машины, либо, если таких машин несколько, быстрее это сделать с помощью PS:

Get-VMDvdDrive -VMName * | Where {$_.Path -like "*\vmguest.iso"} | Set-VMDvdDrive -Path $null

Спустя 5 минут после этого образ будет успешно обновлён и в журнале появится соответствующее событие:

Log Name:      Microsoft-Windows-Hyper-V-VMMS-Admin
Source:        Microsoft-Windows-Hyper-V-VMMS
Date:          11.02.2016 11:08:33
Event ID:      19500
Level:         Information    
User:          SYSTEM
Computer:      KOM-AD01-VM10.holding.com
Description:
The Integration Services Setup Disk image was successfully updated.

Не забывайте освобождать виртуальные приводы во избежание проблем подобного рода

If your virtual machine running on Hyper-V is stuck for some reason, stopped responding, and doesn’t start/stop/reset after clicking the corresponding buttons in the Hyper-V Manager console, you can force-stop (kill) the worker process for this VM on the Hyper-V host. We’ll show you how to force restart a hang Hyper-V VMs running on Windows Server 2022/2019/2016, Windows 10/11, or Free Hyper-V Server without rebooting the entire hypervisor host and all running VMs (useful if you don’t have a Hyper-V HA cluster and Live-Migration).

Hyper-V VM Stuck in the Stopping/Starting/Backing Up State

Suppose, that one of your virtual machines on a Hyper-V host is stuck in the Stopping (Stopping-Critical), Starting (Starting 10%), or Backing up state.

In this case, the guest OS stops responding, and the “Turn Off”, “Shut Down” and “Reset” buttons in the Hyper-V Manager become unavailable (grayed out), or return the following error when pressed:

The application encountered an error while attempting to change the state of VM.
Failed to change state.
The operation cannot be performed while the object is in its current state.

If your Hyper-V does not show the list of registered virtual machines in the Hyper-V Manager console and returns the “Connecting to Virtual Machine Management service” error, you need to restart the vmms.exe (Hyper-V Virtual Machine Management service) process. This is a safe operation and will not interrupt running VMs. The easiest way to restart the vmms.exe process of the vmms service is through the services.msc console or with the PowerShell service management cmdlets:

Get-Service vmms | Restart-Service

How to Stop/Kill a Hung Virtual Machine on Hyper-V?

The only way to force shutdown/restart such a stuck VM without rebooting the whole Hyper-V host is to kill its worker process on the host OS. All VMs on a Hyper-V host are started using the vmwp.exe process instances (Virtual Machine Worker Process). To find a specific process PID, you need to find out the GUID of the virtual machine.

You can get the VM GUID using the Hyper-V Manager console. Open the Hyper-V server settings. The Server section contains the directory where the VM configuration files are stored (in our case it is D:\VMStore).

Open this directory in File Explorer and find the folder with the name of your stuck virtual machine. Copy the GUID that is specified in the name of the VM configuration file with the *.vmcx extension.

Run the Task Manager and go to the Details tab. All virtual machines are running under their own instance of vmwp.exe process. To determine which process is responsible for your VM, you need the GUID of the hung-up VM you obtained earlier. Find the process vmwp.exe that has the GUID of your VM in the User name column. Kill this VM process (End Task).

Similarly, you can find and stop a hung virtual machine process on a Hyper-V host using the Process Explorer tool.

1. Run Process Explorer as administrator and click Find Handle or DLL (or press Ctrl-F);
2. Specify the path to the virtual disk (*.vhdx) of the Hyper-V VM that is stuck in the starting/stopping state;
3. Process Explorer will list all processes that are using the virtual machine VHDX file;
4. Locate the vmwp.exe virtual machine process and kill it (Right-click -> Kill Process).

The virtual machine will be forcibly stopped. Now you can do whatever you want with VM.

Force Stop a Hyper-V VM with PowerShell

It’s much easier to find and kill the not responding virtual machine process using PowerShell. Run the PowerShell console as an administrator (your account must be a member of the Hyper-V “Hyper-V administrators” group).

In this case, the built-in Stop-VM cmdlet from the Hyper-V PowerShell module will not let you shut down the VM. If you try to run the Stop-VM -Forcecommand, it also hangs. Obviously waiting for a response from the VM.

You need to kill a VM process by its GUID. You can get the VM GUID by its name. For example, to get the GUID of the VM with the name SVM-GUARDEDHOST1, run the command:

$VMGUID = (Get-VM "SVM-GUARDEDHOST1").ID

Copy your VMID from the resulting list.

Find the vmwp.exe process identifier (PID) for this VMGUID:

$VMWMProc = (Get-WmiObject Win32_Process | ? {$_.Name -match 'VMWP' -and $_.CommandLine -match $VMGUID})

Then you must forcefully terminate the process of a hung Hyper-V virtual machine, using the Stop-Process command:

Stop-Process ($VMWMProc.ProcessId) –Force

Hyper-V VM Stuck in Backing Up State

When backing up a VM on a Hyper-V host, you may experience the Hyper-V VM stuck in the Running state with the Backing up status. However, you cannot stop or start the VM through Hyper-V Manager.

If you do not want to reboot the Hyper-V host, check the status of the “Microsoft Hyper-V VSS Writer” service first:

vssadmin list writers

Make sure that the command doesn’t return an error. You must then restart the “Hyper-V Virtual Machine Management” service using the PowerShell command:

Get-service vmms | stop-process
Make sure the vmms.exe process has ended. If not, force it to terminate:

Get-Process | Where-Object { $_.ProcessName -eq 'vmms' } | Stop-Process

Now you can start the Hyper-V management service:

Start-Service vmms
Restarting the Virtual Machine Management service should reset the status of VSS Writer on the Hyper-V host.

Hyper-V Manager Failed to Change VM State

Sometimes it happens that even after killing a hung-up VM process, you cannot turn on the VM. Moreover, it freezes in the Starting state with an error:

Virtual Machine Connection
Failed to Change State.

In this case, check the following options:

• Check that there is enough free space on the disk on which the Hyper-V VM files are stored;
• If an ISO image is connected in the VM settings, check if this image file is available at the specified path;
• Check the network adapter settings of the VM. Virtual network adapters must be connected to an existing Hyper-V virtual switch (there must be no status Network Adapter – Configuration Error for any NIC);
• Check that the Hyper-V Virtual Management Service (VMMS) is running and didn’t stuck in the Stopping state;
• Make sure that your antivirus software doesn’t block access to VM files. Add paths to the VM directory to the antivirus exclusions (see hot add exclusions to the built-in Windows Defender antivirus on Windows Server);
• Check for Hyper-V related errors in the Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> Hyper-V-Worker;
• Disable sleep and hibernation on Virtual Machine guest operating systems. You can disable sleep in Windows via Control Panel –>Power Options -> Change plan settings -> Put the computer to sleep -> Never. To disable hibernation and sleep in an Ubuntu Linux guest OS, run the command:
  systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

If the methods above didn’t help, it looks like you’ll have to reboot the entire Hyper-V host.