Vmwp exe что это

Как остановить зависшую виртуальную машину на Hyper-V?

Если ваша виртуальная машина, запущенная на хосте 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 зависла, гостевая ОС перестала отвечать, а кнопки «Turn Off», «Shut Down» и «Reset» в консоли Hyper-V Manager стали недоступны либо при нажатии возвращают ошибку:

Ошибка Hyper-V: Connecting to Virtual Machine Management service

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

Завершение процесса зависшей ВМ с помощью 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).

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

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

Если вы не хотите набирать полное имя ВМ, можете вывести список всех ВМ, зарегистрированных на данном хосте Hyper-V:

Get-VM | Select Name, Id

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

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

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

Stop-Process ($VMWMProc.ProcessId) –Force

Вот так несложно можно принудительно завершить рабочий процесс подвисшей виртуальной машины Hyper-V.

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

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

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

Источник

Утечка памяти в Windows Server 2012 и Windows 8 в процесс Vmwp.exe на узле Hyper-V

Симптомы

Рассмотрим следующий сценарий:

Запустите Windows 8 и Windows Server 2012 как узел Hyper-V.

Настройка гостевой виртуальной машины Windows 7 в пределах узла Hyper-V.

Установить консоль управления независимых производителей на гостевой виртуальной машине Windows 7.

В этом случае кучи памяти для данной виртуальной машины рабочего процесса (Vmwp.exe) на узле Hyper-V утечек памяти и может привести к нестабильной работе системы.

Причина

Эта проблема возникает, поскольку для буфера чтения не освобождаются правильно.

Решение

Сведения об исправлении

Доступно исправление от службы поддержки Майкрософт. Однако данное исправление предназначено для устранения только проблемы, описанной в этой статье. Применяйте это исправление только в тех случаях, когда наблюдается проблема, описанная в данной статье. Это исправление может проходить дополнительное тестирование. Таким образом если вы не подвержены серьезно этой проблеме, рекомендуется дождаться следующего пакета обновления, содержащего это исправление.

Если исправление доступно для скачивания, имеется раздел «Пакет исправлений доступен для скачивания» в верхней части этой статьи базы знаний. Если этот раздел не отображается, обратитесь в службу поддержки для получения исправления.

Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Чтобы просмотреть полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание, посетите следующий веб-сайт корпорации Майкрософт:

Примечание. В форме «Пакет исправлений доступен для скачивания» отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.

Предварительные условия

Это исправление необходимо установить Windows Server 2012 и Windows 8.

Необходимость перезагрузки

Не требуется перезагружать компьютер после установки данного исправления.

Сведения о замене исправлений

Это исправление не заменяет все ранее выпущенные исправления.

Источник

Скачать, исправить и обновить Vmwp.exe

Последнее обновление: 07/07/2021 [Время, требуемое для чтения: 3,5 мин.]

Файл vmwp.exe, также известный как файл Virtual Machine Worker Process, был создан компанией Microsoft для разработки Microsoft® Windows® Operating System. Файлы EXE относятся к категории типов файлов Win64 EXE (Исполняемое приложение).

Файл vmwp.exe изначально был выпущен с Trillian 6.1.0.17 09/04/2019 для ОС Windows 10. Датой самого последнего выпуска файла для Microsoft Office Access 2010 14 является 07/04/2011 [версия 10.0.16299.1004 (WinBuild.160101.0800)]. Файл vmwp.exe входит в состав Microsoft Office Access 2010 14 и Trillian 6.1.0.17.

В этой статье приведены подробные сведения о vmwp.exe, руководство по устранению неполадок с файлом EXE и список версий, доступных для бесплатной загрузки.

Рекомендуемая загрузка: исправить ошибки реестра в WinThruster, связанные с vmwp.exe и (или) Microsoft Office Access 2010.

Совместимость с Windows 10, 8, 7, Vista, XP и 2000

Средняя оценка пользователей

Обзор файла

✻ Фрагменты данных файлов предоставлены участником Exiftool (Phil Harvey) и распространяются под лицензией Perl Artistic.

Что такое сообщения об ошибках vmwp.exe?

vmwp.exe — ошибки выполнения

Ошибки выполнения — это ошибки Microsoft Office Access 2010, возникающие во время «выполнения». Термин «выполнение» говорит сам за себя; имеется в виду, что данные ошибки EXE возникают в момент, когда происходит попытка загрузки файла vmwp.exe — либо при запуске приложения Microsoft Office Access 2010, либо, в некоторых случаях, во время его работы. Ошибки выполнения являются наиболее распространенной разновидностью ошибки EXE, которая встречается при использовании приложения Microsoft Office Access 2010.

В большинстве случаев ошибки выполнения vmwp.exe, возникающие во время работы программы, приводят к ненормальному завершению ее работы. Большинство сообщений об ошибках vmwp.exe означают, что либо приложению Microsoft Office Access 2010 не удалось найти этот файл при запуске, либо файл поврежден, что приводит к преждевременному прерыванию процесса запуска. Как правило, Microsoft Office Access 2010 не сможет запускаться без разрешения этих ошибок.

К числу наиболее распространенных ошибок vmwp.exe относятся:

Не удается запустить программу из-за отсутствия vmwp.exe на компьютере. Попробуйте переустановить программу, чтобы устранить эту проблему.

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

Поиск причины ошибки vmwp.exe является ключом к правильному разрешению таких ошибок. Несмотря на то что большинство этих ошибок EXE, влияющих на vmwp.exe, происходят во время запуска, иногда ошибка выполнения возникает при использовании Microsoft® Windows® Operating System. Причиной этого может быть недостаточное качество программного кода со стороны Microsoft Corporation, конфликты с другими приложениями, сторонние плагины или поврежденное и устаревшее оборудование. Кроме того, эти типы ошибок vmwp.exe могут возникать в тех случаях, если файл был случайно перемещен, удален или поврежден вредоносным программным обеспечением. Таким образом, крайне важно, чтобы антивирус постоянно поддерживался в актуальном состоянии и регулярно проводил сканирование системы.

Как исправить ошибки vmwp.exe — 3-шаговое руководство (время выполнения:

Если вы столкнулись с одним из вышеуказанных сообщений об ошибке, выполните следующие действия по устранению неполадок, чтобы решить проблему vmwp.exe. Эти шаги по устранению неполадок перечислены в рекомендуемом порядке выполнения.

Шаг 1. Восстановите компьютер до последней точки восстановления, «моментального снимка» или образа резервной копии, которые предшествуют появлению ошибки.

Чтобы начать восстановление системы (Windows XP, Vista, 7, 8 и 10):

Если на этапе 1 не удается устранить ошибку vmwp.exe, перейдите к шагу 2 ниже.

Шаг 2. Если вы недавно установили приложение Microsoft Office Access 2010 (или схожее программное обеспечение), удалите его, затем попробуйте переустановить Microsoft Office Access 2010.

Чтобы удалить программное обеспечение Microsoft Office Access 2010, выполните следующие инструкции (Windows XP, Vista, 7, 8 и 10):

После полного удаления приложения следует перезагрузить ПК и заново установить Microsoft Office Access 2010.

Если на этапе 2 также не удается устранить ошибку vmwp.exe, перейдите к шагу 3 ниже.

Microsoft Office Access 2010 14

Шаг 3. Выполните обновление Windows.

Когда первые два шага не устранили проблему, целесообразно запустить Центр обновления Windows. Во многих случаях возникновение сообщений об ошибках vmwp.exe может быть вызвано устаревшей операционной системой Windows. Чтобы запустить Центр обновления Windows, выполните следующие простые шаги:

Если Центр обновления Windows не смог устранить сообщение об ошибке vmwp.exe, перейдите к следующему шагу. Обратите внимание, что этот последний шаг рекомендуется только для продвинутых пользователей ПК.

Если эти шаги не принесут результата: скачайте и замените файл vmwp.exe (внимание: для опытных пользователей)

Если этот последний шаг оказался безрезультативным и ошибка по-прежнему не устранена, единственно возможным вариантом остается выполнение чистой установки Windows 10.

Источник

Архитектура 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 рода запускается на «голом железе».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Драйвер виртуальной инфраструктуры (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, но поддерживающая компоненты интеграции

Существуют так же ОС, не относящиеся к семейству 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 и была подготовлена статья.

Источник