Когда инженер включает компонент Hyper-V в Windows 10 или Windows 11 и после перезагрузки замечает, что эмулятор Android стал вялым, а игра потеряла кадры, он обычно винит "кривую оптимизацию". На самом деле произошло нечто фундаментальное: операционная система, которую пользователь считает хозяином железа, перестала им быть. Она превратилась в привилегированную виртуальную машину, работающую поверх тонкого слоя кода, загрузившегося раньше неё. Эта статья разбирает архитектуру Hyper-V на фоне классических мониторов виртуальных машин второго типа, объясняет устройство партиций, шины VMbus, синтетических устройств, виртуального коммутатора, требования SLAT и вложенной виртуализации, а также показывает, почему WSL2, Docker Desktop и функции безопасности Windows неразрывно связаны с гипервизором, и где заканчиваются мифы о "половине съеденных ресурсов".
Гипервизор первого типа стартует до операционной системы
Главное отличие Hyper-V от VirtualBox и VMware Workstation лежит в точке входа в систему. Классические продукты настольной виртуализации относятся к гипервизорам типа 2: это обычные пользовательские приложения со связкой драйверов, которые запускаются уже после того, как хостовая ОС полностью загрузилась и управляет памятью, планировщиком и устройствами. VirtualBox существует как процесс поверх ядра Windows или Linux и просит у этого ядра ресурсы через стандартные механизмы. VMware Workstation устроен хитрее - его драйвер VMM умеет перехватывать процессор в монопольный режим, но юридически он всё равно остаётся подданным хостовой ОС: память выделяет планировщик хоста, прерывания приходят через ядро хоста.
Hyper-V работает иначе. Когда администратор включает роль Hyper-V через dism или OptionalFeatures, в конфигурацию загрузки добавляется параметр hypervisorlaunchtype auto. После перезагрузки загрузчик Windows сначала стартует модуль hvix64.exe (на системах Intel) или hvax64.exe (на системах AMD) - это и есть гипервизор типа 1, microkernel размером порядка нескольких сотен килобайт кода. Он переводит процессор в режим корневой виртуализации, настраивает таблицы трансляции второго уровня и только затем запускает ядро Windows - уже внутри созданной им корневой партиции.
Из этого следует неприятное для геймера следствие: после включения Hyper-V "домашняя Windows" никогда больше не работает с железом напрямую. Каждый системный вызов, каждое обращение к таймеру, каждый выход в ring 0 исполняется на процессоре, который уже находится под контролем гипервизора. Игры и эмуляторы третьих сторон, откомпилированные под собственное обращение к VT-x, теряют доступ к аппаратной виртуализации: инструкция VMXON в root-партиции проваливается, потому что процессор уже в vmxon-состоянии. Отсюда и "тормоза" Android-эмуляторов старого поколения и некоторых античит-систем, - они вынуждены переходить на интерфейс Windows Hypervisor Platform или на чисто программную интерпретацию. Именно поэтому современные эмуляторы (Google Emulator, BlueStacks новых версий) переписаны под WHPX и после включения Hyper-V работают почти без потерь, а старые бинарники деградируют катастрофически.
Партиции root и child, VMbus и синтетические устройства
Hyper-V называет виртуальные машины партициями. Корневая партиция (root partition) - это та самая загруженная пользователем Windows; она сохраняет владение физическими устройствами, драйверами и стеком ввода-вывода. Дочерние партиции (child partitions) - гостевые ОС, изолированные друг от друга и не имеющие доступа к железу, за исключением устройств, явно назначенных через механизм DDA (Discrete Device Assignment).
Между root и child нет общей памяти и нет прямых вызовов. Общение организовано через VMbus - логическую шину межпартиционного обмена, построенную на гипервызовах (hypercall) и разделяемых кольцевых буферах. Архитектура следует классической схеме VSP/VSC: в корневой партиции живут Virtualization Service Providers - реальные исполнители запросов (Сеть, Хранилище, Видео), а в госте устанавливаются Virtualization Service Clients, входящие в комплект Integration Services. Когда гость читает блок диска через синтетический контроллер, запрос упаковывается в сообщение VMbus, попадает в VSP StorVsp в root-партиции, тот выполняет настоящий ввод-вывод и возвращает результат по тому же каналу.
Контраст с VMware Workstation и VirtualBox здесь принципиален. По умолчанию эти продукты эмулируют реальное железо: контроллеры LSI Logic или BusLogic, сетевые адаптеры Intel E1000, видеокарты VGA. Гостевой драйвер пишет в регистры портов ввода-вывода эмулированного устройства, каждый такой доступ ловится VM-выходом, обрабатывается кодом эмуляции в пользовательском процессе хоста - это десятки тысяч выходов в секунду при активном вводе-выводе. Синтетические устройства Hyper-V такой эмуляции избегают: гость знает, что он виртуален (это и есть паравиртуализация, или Enlightened I/O в терминологии Microsoft), и обменивается данными пакетами через общие страницы памяти без эмуляции регистров. Даже legacy-сетевой адаптер в Hyper-V оставлен лишь для PXE-загрузки старых гостей; штатный путь - Network Adapter, синтетический интерфейс на VMbus. Просветлённые гости Windows используют также синтетические таймеры и enlightenments ядра, которые сокращают число гипервызовов для примитивов синхронизации.
Виртуальный коммутатор и сетевая подсистема
Сетевое взаимодействие партиций идёт через виртуальный коммутатор Hyper-V (vSwitch). Он существует в трёх вариантах: External привязывается к физическому адаптеру и отдаёт гостям прямой выход в сеть (физический интерфейс при этом переехивается под управление коммутатора, а хост получает виртуальный vEthernet-адаптер); Internal соединяет гостей между собой и с корневой партицией; Private объединяет только гостей без выхода к хосту. В серверной линейке vSwitch расширяем: третьи стороны могут писать фильтрующие и пересылающие расширения на базе NDIS, что используется, например, в SDN-стеке Azure Stack HCI. На десктопе важнее другое: создание External-коммутатора меняет привязки протоколов физической карты, поэтому иногда временно пропадает сеть - это нормальная фаза переконфигурации стека.
VT-x, EPT и требование SLAT
Hyper-V в принципе не запустится без аппаратной виртуализации и трансляции адресов второго уровня: Intel VT-x с EPT или AMD-V с RVI/NPT. Требование SLAT (Second Level Address Translation) жёсткое начиная с Windows 8 и Server 2012: systeminfo.exe в секции требований Hyper-V прямо показывает все четыре флага. Причина проста - без EPT гипервизору пришлось бы теневым образом поддерживать таблицы страниц каждого гостя, что резко удорожает переключения и увеличивает поверхность ошибок. С EPT гость управляет своими таблицами сам, а гипервизор держит лишь второй уровень отображения guest physical в system physical.
Вложенная виртуализация (nested virtualization) появилась в Windows Server 2016 и Windows 10 Anniversary Update: командой Set-VMProcessor -VMName X -ExposeVirtualizationExtensions $true гипервизор экспонирует VT-x внутрь гостя, и тот может сам стать хостом Hyper-V или запускать WSL2. Плата - отключение динамической памяти для такой VM и заметный рост VM-выходов при глубокой вложенности, но для лабораторий и CI-агентов это штатный сценарий.
WSL2, Docker Desktop и безопасность на основе виртуализации
Одна из причин, по которой Hyper-V незаметно оказался включённым на миллионах домашних машин, - WSL2. Подсистема Linux второго поколения это не транслятор syscall, а настоящее ядро Linux, исполняемое в лёгкой служебной виртуальной машине, так называемой Utility VM. Она стартует за доли секунды, потребляет память по требованию и освобождает её при давлении со стороны хоста, а файловая система проецируется через план-сервер 9P. Docker Desktop в режиме Windows по умолчанию использует тот же механизм: либо WSL2-бэкенд, либо собственную Utility VM. Поэтому включение WSL2 автоматически поднимает стек виртуализации платформы Windows - и пользователь неожиданно обнаруживает, что его система уже работает под гипервизором со всеми вытекающими эффектами для сторонних эмуляторов.
Вторая волна скрытого распространения гипервизора - Virtualization-based Security, VBS. Когда VBS активен, гипервизор создаёт изолированный корневой мир Virtual Trust Level 1, где исполняется защищённое мини-ядро, а обычная Windows работает в VTL0. Поверх этого строятся: Credential Guard, уносящий секреты LSASS в изолированный процесс LSAIso, недоступный даже коду ядра обычной ОС; HVCI (Memory Integrity, целостность кода с enforced подписью через политику второго уровня страниц); Device Guard с политиками целостности кода, ограничивающими исполняемые бинарники доверенным списком. Всё это возможно только потому, что гипервизор владеет EPT и может делать страницы памяти недоступными для записи даже из ring 0 основной ОС. На свежих машинах с Windows 11 VBS и HVCI нередко включены из коробки, что заметно по крошечным, но измеримым потерям в процессорозависимых играх - обычно в пределах нескольких процентов.
Управление и эксплуатация
Инструментарий администратора строится вокруг связки графической консоли Hyper-V Manager (virtmgmt.msc), приложения VMConnect (vmconnect.exe), дающего консольный и Enhanced Session Mode доступ к гостю по каналу VMbus через RDP, и модуля PowerShell. Основные операции типичны: New-VM создаёт машину с поколением 1 (BIOS-совместимая, эмулированные устройства) или поколением 2 (UEFI, Secure Boot, только синтетика); Set-VMProcessor управляет числом виртуальных процессоров, вложенной виртуализацией и совместимостью для миграции; Set-VMMemory включает динамическую память.
- Чекпоинты бывают standard (сохраняется состояние памяти и устройств, гость "заморожен" посередине работы) и production (снимок строится через VSS внутри гостя Windows, состояние приложений согласовано, память в снимок не входит) - для продуктивных серверов рекомендован второй вариант.
- Динамическая память реализована балунингом: драйвер внутри гостя "надувает" баллон, возвращая страницы хосту при недостатке, и сдувается при избытке, поэтому VM с startup 2 ГБ может комфортно жить на перегруженном хосте.
- Live Migration в серверной линейке переносит работающую VM между узлами кластера без простоя: страницы копируются итеративно, грязные страницы догоняются, финальный переключатель занимает миллисекунды; для переноса между разными поколениями CPU применяется флаг совместимости процессора.
Миф о половине ресурсов и реальные издержки
Фольклор гласит, что Hyper-V "съедает половину мощности машины". Практика измерений опровергает это: нагрузки, связанные с гипервизором, на современных CPU с EPT измеряются в единицах процентов - типично от полутора до пяти процентов на CPU-bound задачах, заметно больше лишь на интенсивном вводе-выводе через эмулированные устройства (которых в Hyper-V почти нет) или при включённой HVCI в старых играх, чувствительных к задержкам выделения страниц. Причины перепутывания лежат в косвенных эффектах: эмуляторы, потерявшие VT-x, действительно проседают в разы, но виноват не расход ресурсов, а смена модели исполнения; игры страдают от VBS и изоляции ядра, а не от "половины процессора". Понимание архитектуры - гипервизор типа 1, корневая партиция вместо хозяина железа, VMbus вместо эмуляции железа - позволяет предсказывать поведение системы и осознанно выбирать: оставить Hyper-V ради WSL2, Docker и Credential Guard или выключить компонент ради legacy-инструментов, приняв компромисс сознательно, а не по мифу.