Windows hypervisor platform api что это

Обновлено: 04.07.2024

Я использую 64-разрядную версию Windows 10 Pro с включенной технологией виртуализации Hyper-V и Intel VT-x. Когда я пытаюсь запустить VirtualBox 64bit, Windows переходит в BSOD. Когда я запускаю VMware, он показывает ошибку.

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

Вот некоторые мои выводы. Большинство сайтов предлагают добавить загрузочную запись с BCDedit или отключить Hyper-V с BCDedit. например, создать загрузочную запись «без гипервизора» , запустить Hyper-V и VirtualBox на одном компьютере . Но я могу запустить QEMU с Hyper-V . Qemu не показывает никаких ошибок с Hyper-V и работает без сбоев.

Hyper-V не поддерживает вложенную виртуализацию (с аппаратным ускорением). Тем не менее, он не потерпит крах при нормальных обстоятельствах. VirtualBox будет жаловаться, что не может запустить x64 гостей и все. Так что что-то еще не так, как неисправный драйвер устройства или что-то еще. Я вижу, это действительно терпит крах. Однако, опять же: это не нормально. Авария никогда не бывает нормальной. Похоже, это ошибка в Hyper-V. Возможно, вам следует связаться с Microsoft по этому поводу. Стоит отметить, что QEMU не является гипервизором. Hyper-V делает поддержку вложенную виртуализацию.

VirtualBox и VMware Workstation (и VMware Player) являются «гипервизорами 2-го уровня». Hyper-V и VMware ESXi являются «гипервизорами 1-го уровня».

Основное отличие заключается в том, что гипервизор 2-го уровня - это приложение, работающее в существующей ОС, а гипервизор 1-го уровня - это сама ОС.

Это означает, что при включении Hyper-V ваш «хост» Windows 10 стал виртуальной машиной. Особый, но тем не менее виртуальная машина.

Итак, ваш вопрос будет более уместным: «Почему VirtualBox и VMware Workstation не работают внутри виртуальной машины Hyper-V?» Можно ответить, потому что как виртуальная машина инструкция Intel VT-X больше не доступна с вашей виртуальной машины, только хост имеет к ней доступ.

QEMU работает, потому что он не выполняет виртуализацию, а эмулирует, что совершенно отличается и объясняет, почему QEMU мучительно медленен. Виртуализация - это процесс запуска полностью изолированной машины внутри другой, но с помощью процессора. Это требует, чтобы виртуальная машина и хост были совместимы с инструкциями.

Эмуляция - это процесс запуска любой машины в работающей ОС, ограничения платформы нет, и поэтому QEMU может запускать машину ARM на платформе amd64.

Hyper-V APIs give users the freedom to build and manage virtual machines or containers at various levels in the virtualization stack.

Hyper-V WMI provider

The WMI provider for Hyper-V enable developers, and scripters, to quickly build custom tools, utilities, and enhancements for the virtualization platform. The WMI interfaces can manage all aspects of the Hyper-V services.

Host Compute System APIs

The main purpose of the Host Compute System API is to provide platform-level access to VMs and containers on Windows.

The HCS APIs are aimed at developers who want to build applications or management services for VMs or containers. End users are not expected to directly interact with the HCS APIs, the end-user experience (graphical or command line interfaces, higher-level APIs, …) is expected to be provided by the applications or management service that are built on top of the platform APIs.

Windows Hypervisor Platform

This API is available starting in the Windows April 2018 Update.

The Windows Hypervisor Platform adds an extended user-mode API for third-party virtualization stacks and applications to create and manage partitions at the hypervisor level, configure memory mappings for the partition, and create and control execution of virtual processors.

Ex: A client such as QEMU can run on the hypervisor while maintaining its management, configuration, guest/host protocols and guest supported drivers. All while running alongside a Hyper-V managed partition with no overlap.

Comparison between WHP, WMI and HCS APIs

WHP APIs required the third-party virtualization stack to run VM, while HCS APIs and WMI APIs are built in virtualization stack of Windows. As the scenerio extended, WMI APIs would provice more management instructions as well as more restrictions and policies.

WMI APIs are really tailored towards high level workflows in server virtualization scenarios, while HCS APIs are designed to manage local VM workflow intentionally that provide more flexibility but more responsibility for application services that need more direct access to containers or local VMs on a single machine.

WMI APIs mainly focus on on-prem server management, which provide high level abstractions that really fit into on-prem server virtualization workflows. For example, when WMI APIs were chosen, the WMI model would be fully applied to VMs, which would add full list of default virtual devices even you only want to create a simple VM. As for HCS APIs, becuase of the broad scope of different use cases for VM outside of server virtualization, like container and WSL, the goal of HCS APIs is to provide more low-level, more granular API service, on the one side to give more flexibility about things like how VM configured, on the other side to assign more management work to the users, which means it doesn't force the specific management model onto the call of the APIs.

Virtualization Related Tools

Virtual Hard Disk Interface

The Virtual Hard Disk (VHD) format is a publicly-available image format specification that specifies a virtual hard disk encapsulated in a single file, capable of hosting native file systems while supporting standard disk and file operations. The Windows SDK supports an API to create and manage the virtual disk.

Host Compute Network Service API

Host Compute Network (HCN) service API is a public-facing Win32 API that provides platform-level access to manage the virtual networks, virtual network endpoints, and associated policies.

Hypervisor Instruction Emulator API

Hypervisor Instruction Emulator API is used to handle the communication between the accelerators and the device emulation that are not provided directly by Windows Hypervisor Platform APIs.

VM Saved State Dump Provider

The Windows SDK includes an API for accessing raw dumps of a VM saved state.

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

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») не приведет к сбою всех запущенных виртуальных машин.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эмулируемые устройства – эмулируют определенные аппаратные устройства, такие, к примеру, как видеоадаптер 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 с установленными компонентами интеграции

Клиенты служб виртуализации. 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 и была подготовлена статья.

В тройке лидеров на рынке софта для виртуализации операционных систем – VMware, VirtualBox и Hyper-V – последний гипервизор занимает особое место. Такое особое место обусловлено тем, что Hyper-V является штатным компонентом серверных систем Windows и некоторых версий Windows для настольных ПК. Уступая VMware Workstation и VirtualBox в функциональности, кроссплатформенности и отчасти в удобстве пользования, Hyper-V, тем не менее, не лишен своих преимуществ. И главное из них – более высокая производительность гостевых ОС.

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

1. Hyper-V - штатный гипервизор от Microsoft

Штатный компонент Hyper-V система Windows 10 унаследовала от версий Windows 8 и 8.1, а в них гипервизор перекочевал из Windows Server. И Windows 8.1, и Windows 10 опционально предусматривают компонент Hyper-V в редакциях Pro и Enterprise. Работа гипервизора возможна только в 64-битных системах.

Длительное время Hyper-V не поддерживал никаких иных гостевых ОС, кроме как Windows. Однако относительно недавно компания Microsoft позаботилась о поддержке гипервизором гостевой ОС Linux. И сегодня с помощью Hyper-V можно тестировать некоторые дистрибутивы Linux, в частности, популярный Ubuntu.

2. Требования для работы Hyper-V

Минимальный объем оперативной памяти физического компьютера для работы Hyper-V – 4 Гб.

Процессор компьютера должен поддерживать технологию SLAT (Intel EPT или AMD RVI). Практически все современные процессоры соответствуют этому требованию.

Другое требование к процессору, также предусматриваемое многими современными моделями – поддержка технологии аппаратной виртуализации и, соответственно, ее активное состояние в BIOS. В BIOS материнских плат для процессоров Intel такая технология (в зависимости от версии) может называться по-разному – Intel-VT, Intel Virtualization Technology, Intel VT-x, Vanderpool или Virtualization Extensions. У AMD технология аппаратной виртуализации называется AMD-V или SVM (Secure Virtual Machines). Например, в AMI BIOS версии 17.9 функцию аппаратной виртуализации процессора AMD можно найти по пути Cell Menu – CPU Feature – SVM Support.

У процессоров AMD функция аппаратной виртуализации, как правило, включена по умолчанию. Поддерживает ли конкретная модель процессора аппаратную виртуализацию, этот момент можно выяснить на сайтах компаний Intel и AMD.

3. Активация и запуск Hyper-V

Hyper-V в комплекте Windows 10 Pro и Enterprise поставляется опционально. Изначально штатный гипервизор отключен. Включается он в разделе панели управления «Программы и компоненты». Самый быстрый способ попасть туда – внутрисистемный поиск.

Запускаем «Включение и отключение системных компонентов».

В появившемся небольшом окошке галочкой отмечаем все подпункты пункта Hyper-V. Жмем «Ок».

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

Доступ к ярлыку диспетчера Hyper-V также можно получить с помощью внутрисистемного поиска.

Запускаем диспетчер Hyper-V.

4. Настройка доступа к сети

В диспетчере Hyper-V сеть настраивается отдельным этапом, и сначала нужно создать виртуальный коммутатор – параметр, обеспечивающий доступ к сети. Делаем клик на названии физического компьютера, а в правой части окна выбираем «Диспетчер виртуальных коммутаторов…».

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

Внешняя – этот тип использует сетевую карту или адаптер Wi-Fi физического компьютера и подключает виртуальную машину к той же сети, в которой находится физический компьютер. Соответственно, это тип сети, предусматривающий доступ виртуальной машины к Интернету;
Внутренняя – этот тип обеспечивает сеть между физическим компьютером и виртуальными машинами Hyper-V, но не предусматривает их доступ к Интернету;
Частная – этот тип позволяет создать сеть между виртуальными машинами Hyper-V, но в этой сети не будет физического компьютера, равно как и не будет выхода в Интернет.

В нашем случае доступ виртуальной машины к Интернету необходим, потому выберем первый тип - внешнюю сеть. Жмем «Создать виртуальный коммутатор».

В окне свойств виртуального коммутатора задаем ему имя, это может быть какое угодно имя, например, «Сетевая карта 1». При необходимости виртуальному коммутатору можно добавить примечание. Если физический компьютер имеет на борту и сетевую карту, и адаптер Wi-Fi, конкретное устройство, посредством которого виртуальная машина будет подключаться к сети, можно выбрать из выпадающего списка в графе «Тип подключения». После проделанных настроек жмем «Применить» внизу окна.

5. Создание виртуальной машины

Теперь можно приступить непосредственно к созданию виртуальной машины. Слева в окне Hyper-V выбор по-прежнему должен быть на названии физического компьютера. В правом углу вверху жмем «Создать», затем – соответственно, «Виртуальная машина».

В приветственном окне запустившегося мастера жмем «Далее».

Задаем виртуальной машине имя; также можно сменить ее месторасположение на диске физического компьютера, указав нужный раздел диска и нужную папку с помощью кнопки обзора. Жмем «Далее».

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

Что это значит? Поколение 1 – это виртуальные машины, поддерживающие 32- и 64-битные системы Windows. Поколение 1 совместимо с прежними версиями Hyper-V.

Поколение 2 – виртуальные машины нового формата со встроенным программным обеспечением на базе UEFI. Такие виртуальные машины поддерживают ряд новых возможностей и способны обеспечить небольшой прирост производительности. На виртуальные машины поколения 2 в качестве гостевых ОС устанавливаются только 64-битные версии Windows 8.1 и 10, а также серверные Windows Server 2012, Server 2012 R2 и Server 2016.

Платформа UEFI обуславливает еще одно требование для использования виртуальных машин поколения 2 – загрузочный носитель UEFI. Этот момент необходимо уточнять, скачивая ISO-образ с дистрибутивом Windows со сторонних источников в Интернете. Но лучше все же скачивать дистрибутивы Windows с официальных источников компании Microsoft. Так, утилита Media Creation Tool, скачивающая с сайта Microsoft дистрибутивы Windows 8.1 и 10 , на выходе создает загрузочный ISO-образ, поддерживающий среду UEFI.

В случае установки в качестве гостевой ОС Windows 10 именно такой способ получения ISO-образа системы и рекомендуется. Windows 10 предусматривает процесс установки с возможностью отложенного ввода ключа продукта. В нашем случае в качестве гостевой ОС будет установлена Windows 8.1, а ее официальный дистрибутив, получаемый с помощью утилиты Media Creation Tool, в процессе установки требует ввод ключа продукта. Обеспечить поддержку среды UEFI и воспользоваться бесплатной возможностью протестировать систему Windows 8.1 поможет сайт Центра пробного ПО TechNet. На этом сайте можно скачать англоязычную редакцию 64-битной Windows 8.1 Корпоративная и бесплатно тестировать систему целых 3 месяца. Проблему с отсутствием поддержки русского языка после установки системы можно решить отдельно, установив языковой пакет и настроив русский основным языком системы.

Возвращаемся к мастеру создания виртуальной машины. В окне выделения памяти оставляем предустановленные параметры, если физический компьютер имеет не более 4 Гб оперативной памяти. Если ее больше 4 Гб, можно увеличить показатель, выделяемый при запуске виртуальной машины. Для гостевой Windows ХР показатель оперативной памяти можно, наоборот, уменьшить до 512 Мб. Жмем «Далее».

В окне настроек сети из выпадающего списка выбираем ранее созданный виртуальный коммутатор. Жмем «Далее».

В окне подключения виртуального жесткого диска задаем виртуальной машине имя, указываем расположение на диске физического компьютера, указываем размер. Это параметры создания нового жесткого диска. Второй пункт этого шага мастера используется, когда на компьютере уже имеется виртуальный жесткий диск, в частности, с установленной гостевой ОС. При выборе виртуальной машины поколения 2 файл такого виртуального жесткого диска должен иметь формат VHDX (а не VHD), а гостевая ОС должна поддерживать среду загрузки UEFI. Жмем «Далее».

Если в предыдущем шаге мастера выбран пункт создания нового виртуального жесткого диска, следующим шагом будет указание пути к дистрибутиву Windows. Виртуальные машины поколения 2 уже не предусматривают загрузку с физического CD/DVD-привода. Источниками загрузки дистрибутива гостевой ОС могут быть только сеть и ISO-образ. В нашем случае это ISO-образ. Жмем «Далее».

Завершающий этап мастера – жмем «Готово».

6. Подключение виртуальной машины

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

В открывшемся окне подключения жмем зеленую кнопку запуска.

Далее нажимаем любую кнопку, чтобы виртуальная машина загрузилась с ISO-образа.

Последует обычный процесс установки Windows 8.1, как это происходило бы на физическом компьютере.

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

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

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

Все – Windows 8.1 установилась. Выключить, приостановить, сохранить виртуальную машину или сбросить ее состояние можно и командами в диспетчере Hyper-V, и кнопками на верхней панели окна подключения.

7. Приоритет загрузки

Чтобы в дальнейшем при запуске виртуальной машины не терять время на окно загрузки с CD/DVD-диска, нужно в выключенном ее состоянии открыть окно параметров и убрать путь к ISO-файлу с дистрибутивом. Это делается во вкладке DVD-привода настроек оборудования виртуальной машины.

Альтернативный вариант – поднять жесткий диск в приоритете загрузки выше DVD-привода (но не выше файла «bootmgfw.efi»). Это делается во вкладке «Встроенное ПО» настроек оборудования.

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

8. Обход ограничений окна подключения Hyper-V

Во главу угла работы гипервизора Hyper-V поставлена производительность виртуальных машин, а не функциональность. В отличие от своих конкурентов – VMware и VirtualBox – виртуальные машины Hyper-V не работают с подключенными флешками, не воспроизводят звук, а взаимодействие с физическим компьютером осуществляется только вставкой внутри гостевых ОС текста, скопированного в основной ОС. Такова цена производительности виртуальных машин Hyper-V. Но это если работать с обычным окном подключения Hyper-V.

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

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

Подключение к виртуальной машине таким образом обеспечит в гостевой ОС воспроизведение звука и двустороннюю передачу файлов.

Платформа виртуализации Hyper-V, разработанная в Microsoft, появилась достаточно давно — первый доклад о ней опубликован на конференции WinHEC в 2006 году, сама платформа была интегрирована в Windows Server 2008. На первых порах в Microsoft охотно делились описанием API Hyper-V (он даже присутствовал в Microsoft SDK 7.0), но со временем официальной информации об интерфейсах Hyper-V становилось все меньше. В конце концов она осталась только в виде Hyper-V Top Level Function Specification, которые предоставляют разработчикам операционных систем, желающим создать условия для работы своей ОС внутри Hyper-V.

Еще большие проблемы возникли после того, как в Windows 10 внедрили технологию Virtualization Based Security (VBS), компоненты которой (Device Guard, Code Integrity и Credential Guard) используют Hyper-V для защиты критичных компонентов операционной системы. Оказалось, что существующие системы виртуализации, такие как QEMU, VirtualBox и VMware Workstation, не могут работать в этих условиях при использовании функций аппаратной виртуализации процессора. Работающий Hyper-V просто блокировал их выполнение.

VBS появился в Enterprise-версии Windows 10, build 1511 (ноябрь 2015 года) как отдельный компонент, но в сборке 1607 уже стал частью ОС, а в декабре 2019-го его сделали активным по умолчанию. Из-за этого начались сбои сторонних виртуальных машин.

Для решения этой проблемы Microsoft разработала Windows Hypervisor Platform API, которые предоставляют следующие возможности для сторонних разработчиков:

создание «разделов» Hyper-V и управление ими;
управление памятью для каждого раздела;
управление виртуальными процессорами гипервизора.

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

API стали доступны в Windows 10 начиная со сборки 1803 (April 2018 update), через компонент Windows Hypervisor Platform (WHPX). Первым поддержкой WHPX обзавелся эмулятор QEMU, для которого программисты Microsoft разработали модуль ускорения WHPX, продемонстрировав, что их API работоспособны. За ними последовали разработчики Oracle VirtualBox, которым пришлось несколько раз переписать код поддержки WHPX по причине изменений в Windows 10 1903.

Компания VMware выпустила версию своей виртуальной машины с поддержкой Hyper-V только 28 мая 2020 года (версия 15.5), аргументировав столь долгую задержку необходимостью переписать весь стек виртуализации.

При этом реализация VMware для Hyper-V потеряла поддержку вложенной виртуализации, и будет ли она добавлена — неизвестно. Также сейчас обсуждают, что производительность заметно снизилась.

Итого в настоящее время WHPX API используются:

в QEMU;
VirtualBox;
VMware Workstation, начиная с версии 15.5 (а также Preview версии 20H2); ; .

Можно сказать, что пока API получается использовать эффективно только в user mode (QEMU, Bochs). И что будет дальше — непонятно. С одной стороны, можно заметить, что API меняются. Новые функции появляются каждые полгода при выходе новой версии Windows и даже при выпуске ежемесячных кумулятивных обновлений.

Например, вот список функций, экспортируемых vid.dll в зависимости от версии Windows.

Как видно, набор функций меняется, особенно для серверных версий Windows.

Для WHVP API все гораздо более стабильнее, что, в общем-то, логично для публичных API.

Официальная документация Hyper-V TLFS обновляется крайне редко — последний апдейт затронул появление вложенной виртуализации, но информации не слишком много, она позволяет считать данные о внутренних структурах гипервизора, что я делал в свое время с помощью утилиты LiveCloudKd. Пока эту информацию получается использовать только в исследовательских целях — применить ее на практике, интегрировав, например, в отладчик, не представляется возможным.

Отдельно стоит упомянуть, что облако Microsoft Azure использует одну и ту же кодовую базу с Hyper-V, о чем говорит менеджер Hyper-V Бен Армстронг (запись сессии — на третьей минуте). Однако основной модуль Hyper-V в Azure отличается и явно собран с некоторыми директивами условной компиляции (достаточно сравнить hvix64/hvax64 для Windows Server 2019 и Windows 10, чтобы определить, что они отличаются достаточно сильно).

Термины и определения

WDAG — Windows Defender Application Guard (или MDAG — Microsoft Defender Application Guard в более новых версиях Windows).
Full VM — стандартная полноценная виртуальная машина, созданная в Hyper-V Manager. Отличается от контейнеров WDAG, Windows Sandbox, Docker в режиме изоляции Hyper-V.
Root ОС — операционная система, в которой установлена серверная часть Hyper-V.
Гостевая ОС — операционная система, которая работает в контексте эмуляции Hyper-V, в том числе используя виртуальные устройства, предоставляемые гипервизором. В статье могут иметься в виду как Full VM, так и контейнеры.
TLFS — официальный документ Microsoft Hypervisor Top-Level Functional Specification 6.0.
GPA (guest physical address) — физический адрес памяти гостевой операционной системы.
SPA (system physical address) — физический адрес памяти root ОС.
Гипервызов (hypercall) — сервис гипервизора, вызываемый посредством выполнения команды vmcall (для процессоров Intel) с указанием номера гипервызова.
VBS (Virtualization Based Security) — средство обеспечения безопасности на основе виртуализации.
EXO-раздел — объект «раздел», создаваемый при запуске виртуальных машин, работающих под управлением Windows Hypervisor Platform API.
WHVP API — Windows Hypervisor Platform API.

Устройство памяти EXO-разделов

В своем исследовании я использовал Windows 10 x64 Enterprise 20H1 (2004) в качестве root ОС и для некоторых случаев Windows 10 x64 Enterprise 1803 с апдейтами на июнь 2020-го (ее поддержка закончится в ноябре 2020-го, поэтому информация предоставлена исключительно для сравнения). В качестве гостевой ОС — Windows 10 x64 Enterprise 20H1 (2004).

В Windows SDK 19041 (для Windows 10 2004) присутствуют три заголовочных файла:

WinHvPlatform.h;
WinHvPlatformDefs.h;
WinHvEmulation.h.

Функции экспортируются библиотекой winhvplatform.dll и описаны в заголовочном файле WinHvPlatform.h . Эти функции — обертки над сервисами, предоставляемыми vid.dll (библиотека драйверов инфраструктуры виртуализации Microsoft Hyper-V), которая, в свою очередь, вызывает сервисы драйвера vid.sys (Microsoft Hyper-V Virtualization Infrastructure Driver).

Продолжение доступно только участникам

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Читайте также: