Когда включают Hyper-V, где на самом деле работает хостовый Windows?

Гипервизор берёт прямой контроль над тем, как распределяются физические ЦП и память, а хостовый Windows работает внутри особого раздела, который называется корневым разделом. Управление физическими устройствами обычно выполняют драйверы на стороне корневого раздела. Корневой раздел держит драйверы устройств и стек управления виртуализацией, но владение физическими ЦП принадлежит гипервизору.

Значит ли «Виртуализация: включено» в Диспетчере задач, что Hyper-V работает?

Нет. Это отображение показывает, включены ли расширения виртуализации ЦП (Intel VT-x/AMD-V) в прошивке. Чтобы увидеть, работает ли гипервизор на самом деле, ищите «A hypervisor has been detected» в systeminfo или проверяйте Win32_ComputerSystem.HypervisorPresent.

Почему гипервизор работает, хотя я никогда не создавал ВМ?

В Windows 11 безопасность на основе виртуализации (VBS) включена по умолчанию на устройствах, которые удовлетворяют условиям — например, чистая установка на совместимом оборудовании, — а VBS построена на гипервизоре Windows. То же верно, если вы используете WSL2 или Windows Sandbox. То, что гипервизор работает без всякой связи с использованием ВМ, — не редкость.

Что такое SLAT и почему он обязателен для Hyper-V?

SLAT (Second Level Address Translation) — механизм, которым ЦП переводит гостевые физические адреса в настоящие физические; реализации — Intel EPT и AMD RVI. Без него гипервизору пришлось бы вести таблицы перевода программно, что с точки зрения производительности нереалистично, поэтому актуальный Hyper-V считает это жёстким требованием.

Если включить Hyper-V, перестанут ли работать VirtualBox и VMware?

Поскольку гипервизор монопольно использует расширения виртуализации ЦП, сторонний гипервизор не может работать традиционным способом. Однако актуальные VirtualBox и VMware имеют режим, который работает поверх гипервизора Windows (через Windows Hypervisor Platform), поэтому недавние версии каждого могут сосуществовать.

Глубины виртуализации Windows (часть 1) — где на самом деле работает ваш Windows? Гипервизор и разделы

22 Aug 2026 02:00 · Го Комура · Windows, Виртуализация, Hyper-V, Гипервизор, SLAT, VMBus

Откройте сведения о системе (msinfo32) в Windows 11 — и часто увидите «Работает» в поле «Безопасность на основе виртуализации», даже на машине, где вы никогда не создавали ВМ.

Что это значит — следующий факт. На этом ПК сам хостовый Windows уже работает поверх гипервизора. «Виртуализация» больше не технология только для тех, кто создаёт ВМ в диспетчере Hyper-V. В Windows 11 безопасность на основе виртуализации (VBS) включена по умолчанию на конфигурациях, которые удовлетворяют условиям — например, чистая установка на совместимом оборудовании¹, — а и WSL2, и Windows Sandbox построены на том же гипервизоре Windows. Под Windows, которым вы пользуетесь каждый день, уже есть ещё один слой программного обеспечения.

Эта серия, «Глубины виртуализации Windows», прослеживает, что происходит в этом слое, начиная с основ.

«Глубины виртуализации Windows» — все 3 части

Часть 1 (эта статья): гипервизор и разделы
Прослеживаем, где оказывается хостовый Windows, когда включают Hyper-V.
Часть 2: память, которую не видит даже ядро — VBS, HVCI и Credential Guard
Прослеживаем, куда Windows кладёт секреты, которые не может прочитать ни администратор, ни ядро.
Часть 3: виртуальные машины, которые загружаются за секунды — WSL2, Windows Sandbox и контейнеры
Прослеживаем по тому, как разделяются память и образы, почему WSL2 и Sandbox легки, хотя полная ВМ тяжела.

Вопрос, на который отвечает часть 1, ровно один.

Когда включают Hyper-V, где оказывается хостовый Windows?

Целевые читатели — разработчики и эксплуатационщики, которые пользуются Hyper-V, WSL2 или Windows Sandbox и хотят понять с механизма, что работает внизу. Предпосылки — x64 Windows 10/11 или актуальный Windows Server (разбор колец, VT-x/AMD-V и EPT/RVI в этой статье предполагает x64; у Arm64 другой механизм, например уровни исключений). Нужный фон — примерно различие режима ядра и пользовательского режима; опыт операций с ВМ или знания по разработке гипервизоров не нужны. Сложность — средняя. Разбираем понятие расширений виртуализации ЦП, но в детали набора инструкций не заходим.

1. Сначала вывод

Когда люди слышат Hyper-V, они могут представить «программу для запуска ВМ, которая сидит поверх Windows». Фактическая структура — наоборот.

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

Гипервизор — тонкий программный слой, который сидит между оборудованием и ОС, создаёт изолированные среды выполнения, называемые «разделами», и посредничает в доступе к оборудованию.² Тот, в который попадает хостовый Windows, — корневой раздел; те, в которые попадают ВМ, — дочерние разделы. Корневой раздел обрабатывают особо (у него прямой доступ к физическим устройствам и он держит стек управления), но в том смысле, что он не управляет физическими ЦП напрямую, он стоит в той же позиции, что и дочерний раздел.

flowchart TB
    accTitle: Общая структура после включения Hyper-V
    accDescr: Гипервизор сидит прямо на физическом оборудовании, а над ним — корневой раздел, который держит хостовый Windows, и дочерние разделы, которые держат ВМ
    hw["Физическое оборудование"] --> hv["Гипервизор"]
    hv --> root["Корневой раздел (хостовый Windows)"]
    hv --> child1["Дочерние разделы (ВМ)"]
    root -.-> stack["Держит стек управления виртуализацией и драйверы устройств"]

Рис. 1: Hyper-V — не «ПО для ВМ поверх Windows», а слой, который уходит под Windows, и сама хостовая ОС работает внутри корневого раздела.

Можно подумать: «Если после включения ничего не чувствуется, неужели такая крупная инверсия действительно произошла?» Произошла. Именно поэтому эту структуру обычно не замечают. В этой статье мы разбираем эту одну схему по трём осям: ЦП, память и ввод-вывод устройств.

2. Со стороны ЦП — ещё одна привилегия ниже колец

2.1. Краткое повторение защиты кольцами

У x64-ЦП есть уровни привилегий (кольца), и Windows выполняет режим ядра в кольце 0, а пользовательский режим — в кольце 3. Приложения не могут трогать оборудование напрямую, потому что привилегированные инструкции из кольца 3 выполнить нельзя.

Так как же безопасно разместить несколько ядер ОС, каждое из которых работает в кольце 0, на одном физическом ЦП? Каждое ядро написано из допущения «я управляю ЦП». Дать кольцо 0 всем — они столкнутся; отказать — они не заработают.

flowchart TB
    accTitle: Проблема нескольких ядер ОС, требующих кольцо 0
    accDescr: И хостовое, и гостевое ядро написаны из допущения полной власти в кольце 0, поэтому одной традиционной лестницы колец недостаточно, чтобы безопасно разместить их на одном физическом ЦП
    k1["Хостовое ядро (исходит из кольца 0)"] --> want["Требует управление физ. ЦП"]
    k2["Гостевое ядро (исходит из кольца 0)"] --> want
    want --> conflict["Традиционные кольца не мирят это"]
    conflict --> need["Нужен посредник выше кольца 0"]

Рис. 2: Лестница колец строилась из допущения одной ОС, поэтому размещение нескольких ядер требует ещё одной привилегии над ней.

2.2. Расширения виртуализации — режим, зарезервированный для гипервизора

То, что решает эту проблему, — расширения виртуализации ЦП (Intel VT-x/AMD-V). Hyper-V требует процессор с этой возможностью.² Расширения виртуализации добавляют на оси, отдельной от традиционных колец, «режим выполнения для гипервизора» и «режим выполнения для гостей». Это привилегия ещё сильнее кольца 0, иногда прозванная «кольцо −1».

Гостевое ядро продолжает работать в кольце 0, как прежде. Переписывать его не нужно.
Однако это кольцо 0 — «кольцо 0 внутри гостевого режима», и оно не управляет физическим ЦП в целом.
Когда гость натыкается на конкретную операцию, которой нужно вмешательство гипервизора (инструкция, настроенная как перехват, или исключение, или нарушение), ЦП автоматически передаёт управление гипервизору (VM Exit). Когда гипервизор заканчивает обработку, он возвращается к гостю (VM Entry). Обычные обращения к памяти проходят без VM Exit, пока перевод SLAT успешен.

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

flowchart TB
    accTitle: Поток выполнения гостя и VM Exit
    accDescr: Гостевое ядро и приложения работают в кольце 0 и кольце 3 в гостевом режиме; обычные обращения к памяти проходят через перевод SLAT, а настроенные перехваты и исключения вызывают VM Exit, который передаёт управление гипервизору, затем тот возвращается к гостю через VM Entry
    guest["Выполнение в гостевом режиме (включая ядро кольца 0)"] --> op{"Нужно вмешательство? (настроенные перехваты/исключения)"}
    op -->|Нет| cont["Продолжить выполнение как есть"]
    op -->|Да| exitEv["VM Exit (ЦП передаёт управление)"]
    exitEv --> hvp["Гипервизор обрабатывает"]
    hvp --> entry["Вернуться к гостю через VM Entry"]
    entry --> guest

Рис. 3: Гостевая ОС продолжает работать в кольце 0 без переписывания, и ЦП вызывает гипервизор только когда нужно.

Этот круговой путь очень похож на поток, который мы прослеживали в серии про память, — «войти в ядро на ошибке страницы, затем вернуться к той же инструкции». ЦП перехватывает управление через механизм исключения или перехода, даёт решить менеджеру более высокого уровня и затем возвращается. В глубинах Windows эта форма появляется снова и снова.

2.3. Тип 1 и тип 2 — разница в том, где он сидит

Гипервизоры широко делят на тип 1 (bare-metal), который работает прямо на оборудовании, и тип 2 (hosted), который работает поверх хостовой ОС. Hyper-V — тип 1.³ VirtualBox и VMware Workstation (когда запускают автономно) относят к типу 2.

Услышав «тип 1», люди склонны представить «конфигурацию только для сервера без хостовой ОС», но Hyper-V другой. Хостовый Windows не исчезает — он «переезжает» в корневой раздел. Когда включают Hyper-V и перезагружаются, гипервизор стартует первым во время загрузки, а хостовый Windows затем поднимается как корневой раздел поверх него.

flowchart TB
    accTitle: Разница между гипервизорами типа 1 и типа 2
    accDescr: В типе 2 хостовая ОС сидит на оборудовании, а гипервизор и ВМ — на хостовой ОС, тогда как в типе 1 Hyper-V гипервизор сидит прямо на оборудовании, а сама хостовая ОС уходит в корневой раздел над ним
    subgraph t2 ["Тип 2 (hosted)"]
        hw2["Оборудование"] --> hostos["Хостовая ОС"]
        hostos --> hv2["Гипервизор"]
        hv2 --> vm2["ВМ"]
    end
    subgraph t1 ["Тип 1 (Hyper-V)"]
        hw1["Оборудование"] --> hv1["Гипервизор"]
        hv1 --> root1["Корневой раздел (хостовая ОС)"]
        hv1 --> vm1["ВМ"]
    end
    vm2 ~~~ hw1

Рис. 4: В типе 2 гипервизор сидит на хостовой ОС, тогда как в типе 1 Hyper-V порядок обратный и сама хостовая ОС сидит на слое на одну ступень ниже.

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

flowchart TB
    accTitle: Порядок загрузки после включения Hyper-V
    accDescr: После включения питания гипервизор стартует первым во время загрузки, хостовый Windows затем поднимается как корневой раздел поверх него, а ВМ, VBS и подобное стартуют после этого
    poweron["Включение и старт загрузки"] --> bhv["Гипервизор стартует первым"]
    bhv --> broot["Хостовый Windows стартует как корневой раздел"]
    broot --> blater["ВМ, VBS, WSL2 и так далее стартуют поверх этого"]
    broot -.-> feel["Ощущения пользователя не меняются"]

Рис. 5: Обращение порядка уже закончено до появления экрана входа, и хостовая ОС поднимается на гипервизоре с самого начала.

3. Разделы — единица изоляции

3.1. Роли, которые есть только у корневого раздела

Раздел — логическая единица изоляции, которую даёт гипервизор.² Однако не все разделы равны. Есть вещи, которые есть только у корневого раздела.

Прямой доступ к физическим устройствам. Драйверы устройств для дисков, сетевых адаптеров, GPU и подобного живут в Windows внутри корневого раздела, а не в гипервизоре. У Hyper-V на Windows Server есть конфигурация, которая назначает конкретное устройство PCIe напрямую дочернему разделу (Discrete Device Assignment); в этом случае корень отпускает это устройство (на клиентском Windows этого нет).⁴
Стек управления виртуализацией. VMMS (Virtual Machine Management Service), который управляет созданием, запуском и остановкой ВМ, и рабочий процесс на каждую ВМ (vmwp.exe) работают в пользовательском режиме в корневом разделе.⁵ Это часть функций управления ВМ Hyper-V, поэтому на хосте, где гипервизор работает только ради VBS или WSL2, их может не быть.
Право создавать дочерние разделы. Корневой раздел создаёт дочерние разделы через API гипервызовов (интерфейс вызова в гипервизор).²

У этой конструкции есть причина. Если положить каждый драйвер устройства в сам гипервизор, гипервизор станет огромным, а число ошибок и точек входа атаки вырастет. Гипервизор ограничивается минимальной работой посредничества по ЦП и памяти и оставляет заботу об устройствах Windows в корневом разделе. Это разделение ролей и держит Hyper-V тонким.

flowchart TB
    accTitle: Разделение ролей корневого и дочерних разделов
    accDescr: Корневой раздел держит стек управления виртуализацией и драйверы физических устройств и создаёт дочерние разделы через гипервызовы; дочерний раздел обычно видит только виртуальные устройства, а при Discrete Device Assignment на Windows Server обращается к назначенному устройству напрямую
    subgraph rootp ["Корневой раздел"]
        vmms["VMMS и рабочие процессы"]
        drv["Драйверы физ. устройств"]
    end
    subgraph childp ["Дочерний раздел"]
        gos["Гостевая ОС"]
        vdev["В обычной конфигурации видны только вирт. устройства"]
    end
    vmms -->|Создать и управлять через гипервызовы| childp
    hv2["Гипервизор (ограничивается посредничеством ЦП и памяти)"] --- rootp
    hv2 --- childp

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

3.2. Мир, каким его видит дочерний раздел

Гостевая ОС в дочернем разделе в обычной конфигурации виртуальных устройств не видит физическое оборудование напрямую (единственное исключение — устройство, назначенное через Discrete Device Assignment на Windows Server, как в предыдущем разделе). Что она видит — виртуальные процессоры, пространство памяти, которое кажется её собственным, и виртуальные устройства. Запросы к виртуальным устройствам пересылаются в корневой раздел через VMBus или гипервизор.² Распределение процессорного времени и перевод памяти через SLAT, с другой стороны, гипервизор обрабатывает напрямую, не заходя в корень. То, чем корень посредничает, — ввод-вывод устройств, а не каждый физический ресурс.

flowchart TB
    accTitle: Мир, каким его видит дочерний раздел
    accDescr: Что видит гостевая ОС — виртуальные процессоры, пространство памяти, частное для раздела, и виртуальные устройства; запросы к виртуальным устройствам пересылаются в корневой раздел через VMBus и подобное, время ЦП и перевод памяти обрабатывает гипервизор напрямую, а в конфигурации Discrete Device Assignment на Windows Server только назначенные устройства доступны напрямую
    gos2["Гостевая ОС"] --> vcpu["Вирт. процессоры"]
    gos2 --> rest{"Память / устройства?"}
    rest --> gpa2["Частное пространство"]
    rest --> vdev2["Вирт. устройства"]
    vdev2 --> rootx["Переслано в корень"]
    rootx -.-> vbus["Через VMBus"]
    gos2 -.-> phys2["Физ. ЦП / ОЗУ / устр."]
    phys2 -.-> hid["Не видно напрямую"]
    phys2 -.-> dda2["DDA: назначенные"]
    dda2 -.-> ddaN["Windows Server"]
    vcpu ~~~ phys2

Рис. 7: В обычной конфигурации виртуальных устройств всё, что видит гость, — виртуальное окно, и путь к физическому идёт через посредника; исключение — только устройство, назначенное через DDA на Windows Server.

Важно здесь то, что для приложения, которое работает на хостовом Windows, эта структура почти прозрачна. Вызовы Win32 API и обработка ошибок страницы по-прежнему обрабатываются ядром Windows внутри корневого раздела, как прежде. Гипервизор вмешивается только когда попадается настроенный перехват или исключение.

4. Со стороны памяти — перевод адреса получает ещё один уровень

4.1. Три вида адресов

В части 1 серии про память мы прослеживали поток, которым виртуальный адрес переводится через таблицу страниц в физический адрес («Момент, когда виртуальный адрес становится физической ОЗУ»). В виртуализированной среде под этим переводом добавляется ещё один уровень, и видов адресов становится три.

Адрес	Сокр.	Кто управляет
Гостевой виртуальный адрес	GVA	Таблица страниц гостевой ОС
Гостевой физический адрес	GPA	Адрес, который гостевая ОС считает «физическим»
Системный физический адрес	SPA	Гипервизор (фактическое место в ОЗУ)

Гостевая ОС переводит GVA в GPA своей таблицей страниц. Однако GPA, который видит гость, — не настоящий физический адрес; это частное пространство памяти, выделенное каждому разделу.² Отображение GPA на фактическое место в ОЗУ (SPA) — работа гипервизора.

4.2. SLAT — двухуровневый перевод аппаратно

Если делать этот перевод второго уровня только программно, гипервизору придётся отслеживать каждое обновление гостевой таблицы страниц по одному, что с точки зрения производительности нереалистично. Поэтому ЦП даёт механизм, который обходит таблицы перевода второго уровня аппаратно. Это SLAT (Second Level Address Translation); реализации — Intel EPT (Extended Page Tables) и AMD RVI. Актуальный Hyper-V требует 64-разрядный процессор с поддержкой SLAT.⁴

flowchart TB
    accTitle: Двухуровневый перевод адреса через SLAT
    accDescr: Гостевой виртуальный адрес переводится в гостевой физический таблицей страниц гостевой ОС, затем дальше переводится в системный физический адрес SLAT, которым управляет гипервизор, и достигает фактической ОЗУ
    gva["Гостевой вирт. адрес (GVA)"] -->|Таблица страниц гостевой ОС| gpa["Гостевой физ. адрес (GPA)"]
    gpa -->|"SLAT (таблицы перевода EPT/RVI)"| spa["Системный физ. адрес (SPA)"]
    spa --> ram["Физическая ОЗУ"]
    gpa -.-> note["Слой, который гость лишь считает физическим"]

Рис. 8: Под таблицей страниц гостя сидит ещё одна таблица перевода, которой управляет гипервизор, и ЦП обходит обе аппаратно.

SLAT — не возможность, которая существует только ради эффективности выполнения ВМ. VBS, которую мы увидим в части 2, использует свойство «можно иметь разную таблицу перевода SLAT на уровень привилегий» как материал границы безопасности. Причина, по которой можно создать память, которую не видит даже ядро, в том, что гипервизор держит этот перевод второго уровня. Это становится сквозной линией всей серии, поэтому запомните один пункт: «владелец таблиц перевода — гипервизор».

5. Со стороны ввода-вывода устройств — VMBus и два вида устройств

5.1. Пределы эмулируемых устройств

Классический способ показать устройство дочернему разделу — полностью имитировать настоящее оборудование (например, старый контроллер IDE) программно. Совместимость высока, потому что встроенные драйверы гостевой ОС работают как есть, но VM Exit происходит каждый раз, когда гость попадает в порт ввода-вывода, и производительность не масштабируется.

flowchart TB
    accTitle: Почему ввод-вывод к эмулируемому устройству медленный
    accDescr: Каждый раз, когда гость оперирует портом ввода-вывода, управление передаётся на сторону гипервизора через VM Exit, устройство имитируется программно, и гостя возвращают, поэтому круговой путь повторяется и медленный
    gio["Гость оперирует портом I/O"] --> vex["Происходит VM Exit"]
    vex --> emu2["Устройство эмулируется программно"]
    emu2 --> back["Вернуться к гостю через VM Entry"]
    back -->|Повторяется на следующей операции порта| gio

Рис. 9: Этот круговой путь выполняется много раз за одним обращением к диску, и цена совместимости платится производительностью.

5.2. VMBus и VSP/VSC — быстрый путь, спроектированный для виртуализации

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

VMBus: логический канал связи между разделами. Даёт высокоскоростное межраздельное взаимодействие, которое использует разделяемую память.³
VSP (Virtualization Service Provider): служба, которая живёт на стороне корневого раздела, принимает запросы устройств от дочернего и мостит их в стек устройств/серверной части на стороне корня. Запрос может достичь физического устройства или обрабатываться серверной частью на стороне хоста вроде виртуального диска или виртуального коммутатора.
VSC (Virtualization Service Consumer): драйвер синтетического устройства, который входит в гостевую ОС на стороне дочернего раздела. Он отправляет запросы VSP по VMBus.

Взяв запрос хранения гостевой ОС как пример, поток выглядит так. WriteFile гостевого приложения спускается по стеку ввода-вывода гостевого ядра и внизу достигает VSC (вместо настоящего оборудования). VSC кладёт запрос на VMBus и передаёт его VSP в корневом разделе, а VSP вливает запрос в стек ввода-вывода на стороне корня. В конфигурации виртуального диска (VHDX) эта запись обрабатывается как запись в файл VHDX на хосте и в конце концов достигает физического диска. Этот подход называют Enlightened I/O (ввод-вывод, который знает о виртуализации), и он повышает эффективность, обходя слой эмуляции устройств.²

flowchart TB
    accTitle: Путь ввода-вывода синтетического устройства
    accDescr: Запрос ввода-вывода от приложения в дочернем разделе достигает VSC через гостевое ядро, пересекает VMBus к VSP в корневом разделе и на стеке ввода-вывода стороны корня, в который VSP мостит, может достичь настоящего устройства через драйвер физического устройства или обрабатываться серверной частью хоста вроде виртуального диска или виртуального коммутатора
    app["Приложение в дочернем разделе"] --> gk["Стек I/O гостевого ядра"]
    gk --> vsc["VSC (драйвер синтетического устройства)"]
    vsc -->|VMBus| vsp["VSP (сторона корневого раздела)"]
    vsp --> rio["Стек I/O стороны корня"]
    rio --> pdrv["Драйвер физ. устройства"]
    rio --> hb["Серверная часть хоста (вирт. диск, вирт. коммутатор и так далее)"]
    pdrv --> dev["Физическое устройство"]

Рис. 10: С синтетическим устройством гостевой ввод-вывод пересекает к корневому разделу по VMBus и через стек стороны корня достигает настоящего устройства или серверной части хоста.

Иными словами, быстр ли дисковый ввод-вывод или сеть ВМ, зависит не только от стороны гостя, но и от состояния стека ввода-вывода и драйверов устройств на стороне корневого раздела. Причина, почему наблюдение со стороны хоста незаменимо, когда расследуете проблему производительности ВМ, в том, что путь на самом деле проходит через хост.

flowchart TB
    accTitle: Эмулируемые устройства против синтетических устройств
    accDescr: Эмулируемое устройство имитирует настоящее оборудование, чтобы встроенные гостевые драйверы работали, но медленное; синтетическое устройство — целевой драйвер, который исходит из VMBus, и быстрое
    dev2{"Устройство, показанное дочернему разделу"} --> emu["Эмулируемое устройство"]
    dev2 --> syn["Синтетическое устройство"]
    emu -.-> emuP["Эмулирует настоящее оборудование; совместимость прежде всего"]
    emuP -.-> emuC["Нужно вмешательство на каждом I/O; медленно"]
    syn -.-> synP["Спроектировано вокруг VMBus; быстро"]
    synP -.-> synC["Требует подходящий драйвер в госте"]

Рис. 11: Из двух видов виртуальных устройств эмулируемые несут совместимость сразу после установки ОС, а синтетические — производительность в повседневном использовании.

6. Почему это не чужая проблема, даже если вы никогда не используете ВМ

Структура до сих пор может выглядеть как «история для тех, кто поднимает ВМ». Как сказано во вступлении, однако, на актуальном Windows гипервизор — часть повседневности.

Безопасность на основе виртуализации (VBS). Использует гипервизор Windows, чтобы создать изолированную среду, и размещает там функции безопасности. В Windows 11 включена по умолчанию, когда удовлетворены условия вроде чистой установки на совместимом оборудовании.¹ Подробности — в части 2.
WSL2. Запускает настоящее ядро Linux внутри лёгкой служебной ВМ.⁶
Windows Sandbox. Одноразовая среда Windows, изолированная гипервизором.⁷ Оба разобраны в части 3.

flowchart TB
    accTitle: Повседневные функции, которые сидят на одном гипервизоре
    accDescr: Не только ВМ Hyper-V, но и VBS, которая включена по умолчанию на устройствах, удовлетворяющих условиям вроде чистой установки, плюс WSL2 и Windows Sandbox — все построены на одном гипервизоре Windows
    base["Гипервизор Windows"] --> f1["ВМ Hyper-V"]
    base --> f2["VBS (вкл. по умолч. на чистых установках и подобном)"]
    base --> f3["WSL2"]
    base --> f4["Windows Sandbox"]
    f2 -.-> daily["Почему работает даже на ПК, которые никогда не используют ВМ"]

Рис. 12: Основание одно, и на этой схеме рушится допущение «виртуализация — история для тех, кто пользуется ВМ».

Ещё одна вещь, на которую на практике часто наступают, — сосуществование со сторонним ПО виртуализации. Поскольку гипервизор монопольно использует расширения виртуализации ЦП, в среде, где работает гипервизор Windows, VirtualBox и подобное не могут работать традиционным способом (способом, который сам использует расширения виртуализации ЦП). Для этого предусмотрен открытый API под названием Windows Hypervisor Platform, и сторонний стек виртуализации может работать, садясь поверх гипервизора Windows.⁸ Актуальные VirtualBox/VMware могут сосуществовать с WSL2 благодаря этому механизму, но различия в производительности и возможностях, которые приходят со сменой режима, иногда наблюдают как «после того как я включил Hyper-V (или VBS), ПО виртуализации стало вести себя иначе».

flowchart TB
    accTitle: Кто владеет расширениями виртуализации ЦП и путь для стороннего ПО виртуализации
    accDescr: Пока гипервизор Windows работает, он монопольно владеет расширениями виртуализации ЦП; стороннее ПО виртуализации, которое поддерживает WHP, работает поверх него через Windows Hypervisor Platform, а реализации без поддержки WHP не могут работать или ограничены
    vt["Расширения виртуализации ЦП (VT-x/AMD-V)"] --> hvon{"Гипервизор Windows работает?"}
    hvon -->|Нет| direct["Стороннее ПО может использовать напрямую"]
    hvon -->|Да| own["Гипервизор использует монопольно"]
    own --> whp["Windows Hypervisor Platform"]
    whp --> third["Стороннее ПО с WHP работает поверх"]
    third -.-> nowhp["Реализации без поддержки не работают или ограничены"]

Рис. 13: Владелец расширений виртуализации один, и единственное стороннее ПО, которое может сосуществовать, пока гипервизор работает, — ПО, которое поддерживает открытый API (WHP).

7. Посмотрите сами

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

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

# Whether we are running on top of a hypervisor
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent

# VBS status (same source as "Virtualization-based security" in msinfo32)
Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus

VirtualizationBasedSecurityStatus возвращает состояние работы VBS числом (2 — «Работает»).⁹

Одна оговорка. Всё, что говорит HypervisorPresent, — «работаем ли мы поверх гипервизора»; корень от дочернего он не различает. Если запустить на Windows внутри ВМ, он всё равно вернёт True как дочерний раздел. Если True на Windows на физическом ПК, этот Windows внутри корневого раздела — читайте вместе со средой выполнения.

Далее классика из командной строки.

systeminfo

Смотрите «Hyper-V Requirements» в конце вывода. На машине, где гипервизор ещё не работает, перечислены отдельные требования — поддержка SLAT, включены ли расширения виртуализации и так далее. На машине, где гипервизор уже работает, вместо требований одна строка: «A hypervisor has been detected. Features required for Hyper-V will not be displayed.»⁴ Поэтому эта одна строка — утверждение, что ваш Windows работает поверх какого-то гипервизора. Как и с HypervisorPresent, нужно читать это как «внутри корневого раздела» на физическом ПК или «как дочерний раздел» внутри ВМ.

Даже если каждое требование systeminfo — «Yes», это значит только, что сторона оборудования готова. Сама возможность Hyper-V есть в редакциях Pro, Enterprise и Education и нет в Home.¹⁰

В графическом интерфейсе проверьте строку «Безопасность на основе виртуализации» в «Сведениях о системе» в msinfo32. Заметьте: «Виртуализация: включено» на панели ЦП Диспетчера задач показывает только включены ли расширения виртуализации в прошивке, что отдельная информация от того, работает ли гипервизор.

flowchart TB
    accTitle: Как проверить, работает ли гипервизор
    accDescr: Если systeminfo говорит, что гипервизор обнаружен, вы работаете на гипервизоре (внутри корневого раздела на физическом ПК); если появляется список Hyper-V Requirements, он ещё не работает, поэтому проверяете каждое требование вроде SLAT, VM Monitor Mode Extensions и DEP, но все Yes значат только, что сторона оборудования готова, а у возможности Hyper-V ещё есть требование редакции
    start2["Запустить systeminfo"] --> q1{"Поле требований?"}
    q1 -->|Detected| running["Гипервизор работает"]
    running -.-> runN["Внутри корня"]
    runN -.-> runN2["на физическом ПК"]
    q1 -->|Listed| notyet["Ещё не работает"]
    notyet --> q2{"Все требования Yes?"}
    q2 -->|Все Yes| can["Сторона оборудования готова"]
    can -.-> ed["Нужен Pro / Ent / Edu"]
    q2 -->|Некоторые No| uefi["Проверить пункты UEFI/BIOS"]

Рис. 14: Поле «Hyper-V Requirements» в systeminfo служит и проверкой состояния работы, и проверкой предпосылок.

8. Три прочтения, которых стоит избегать на практике

8.1. «Мы не включали Hyper-V, так что виртуализация к нашим ПК не относится»

Даже если вы не включали возможность Hyper-V (средства управления и среду выполнения ВМ), гипервизор Windows работает, если включён VBS. Когда расследуете проблему совместимости драйвера, тест производительности или неприятность со сторонним ПО виртуализации, проверяйте HypervisorPresent и состояние работы VBS — не то, включена ли возможность.

8.2. «Диспетчер задач говорит „Виртуализация: включено“, значит Hyper-V работает»

Это отображение — о настройке прошивки (доступны ли VT-x/AMD-V). Состояние работы гипервизора судите по «A hypervisor has been detected» в systeminfo. Наоборот, если Диспетчер задач говорит «Отключено», включить Hyper-V или WSL2 тоже нельзя, поэтому сначала проверьте настройки UEFI/BIOS.

flowchart TB
    accTitle: Три проверки, которые легко перепутать
    accDescr: Поле виртуализации Диспетчера задач показывает настройку прошивки, список компонентов Windows — состояние установки, а systeminfo или HypervisorPresent — состояние работы; каждое отвечает на другой вопрос
    q3{"Какой вопрос?"}
    q3 --> fw{"Прошивка или Windows?"}
    q3 --> c3["Гипервизор работает?"]
    fw --> a3["Расширения прошивки?"]
    fw --> b3["Возможность Hyper-V вкл.?"]
    a3 -.-> a3t["Панель ЦП Диспетчера задач"]
    b3 -.-> b3t["Интерфейс компонентов Windows"]
    c3 -.-> c3t["systeminfo"]
    c3 -.-> c3tp["HypervisorPresent"]

Рис. 15: Это три независимых вопроса, и выводить два других из любого одного отображения — ошибочное прочтение.

8.3. «Если ВМ медленная, это проблема гостевой ОС»

Ввод-вывод синтетического устройства пересекает VMBus к VSP в корневом разделе и идёт через стек устройств/серверной части стороны корня (физические драйверы плюс обработка виртуального коммутатора и виртуального диска). Если смотреть только счётчики внутри гостя, узкое место, которое сидит в хранилище или сетевом адаптере на стороне хоста, вы не найдёте. Принцип для проблем производительности ВМ — наблюдать с обеих сторон: гость и хост (корневой раздел).

9. Итоги

Когда включают Hyper-V, гипервизор работает прямо на оборудовании, а хостовый Windows работает как корневой раздел.²
Ядро гостевой ОС продолжает работать в кольце 0, и только операции, настроенные как перехваты, плюс исключения передаются гипервизору через VM Exit. Обычные обращения к памяти проходят через перевод SLAT.
Только корневой раздел держит драйверы физических устройств и стек управления виртуализацией и создаёт дочерние разделы через гипервызовы.²
Память становится двухуровневым переводом GVA→GPA→SPA, и второй уровень обрабатывается аппаратно SLAT (EPT/RVI). Актуальный Hyper-V требует SLAT.⁴
Вводом-выводом устройств доминирует путь синтетического устройства VSC→VMBus→VSP, и производительность зависит также от стека ввода-вывода на стороне хоста.²
В Windows 11, поскольку VBS включена по умолчанию на устройствах, которые удовлетворяют условиям вроде чистой установки, не необычно, что гипервизор работает даже на ПК, который никогда не использует ВМ.¹ Состояние работы можно подтвердить через HypervisorPresent и systeminfo.

Общая картина части 1 сжимается в эту одну схему.

flowchart TB
    accTitle: Общая картина части 1
    accDescr: Гипервизор сидит под корневым разделом и дочерними разделами; ЦП распределяются планированием виртуальных процессоров (VM Exit только на настроенных перехватах и исключениях), память посредничается двухуровневым переводом SLAT, ввод-вывод синтетических устройств пересылается по VMBus и обрабатывается VSP корневого раздела, а у эмулируемых устройств и Discrete Device Assignment другие пути
    up["Корень + дочерние разделы"] --> hvS["Гипервизор"]
    hvS --> cpuS["ЦП: планировать VP"]
    hvS --> memS["Память: SLAT"]
    cpuS -.-> cpuN["VM Exit на перехвате"]
    memS -.-> memN["Двухуровневый перевод"]
    memS ~~~ devS
    devS["Устройства: I/O VMBus"] --> vspS["Обрабатывает VSP стороны корня"]
    devS -.-> devN["Эмулируемые / DDA: другие"]

Рис. 16: Планирование ЦП и перевод памяти гипервизор обрабатывает напрямую (VM Exit только при вмешательстве), а ввод-вывод синтетических устройств посредничает корневой раздел (VSP) по ту сторону VMBus.

Продолжение в части 2, «Память, которую не видит даже ядро — VBS, HVCI и Credential Guard».

Берём сквозную линию этой статьи — что гипервизор держит таблицы перевода SLAT — и прослеживаем, как Windows создаёт «память, которую не может прочитать ни администратор, ни ядро».

Смежные области консультирования

KomuraSoft LLC занимается проектированием сред проверки Windows-приложений, расследованием производительности в виртуализированных средах и анализом проблем совместимости драйверов и периферии.

Справочные ссылки

Microsoft Learn, Silicon assisted security. О том, что VBS использует аппаратную виртуализацию, чтобы изолировать Secure Kernel от обычной ОС, и о том, что VBS и HVCI включены по умолчанию на устройствах, которые удовлетворяют предпосылкам при новой установке Windows 11. ↩ ↩² ↩³
Microsoft Learn, Hyper-V Architecture. О том, что гипервизор даёт разделы как единицу изоляции; корневой раздел создаёт дочерние разделы через API гипервызовов; разделы работают в частном виртуальном пространстве памяти без прямого доступа к физическим процессорам; о ролях VMBus, VSP, VSC и Enlightened I/O; и о том, что требуются аппаратные расширения виртуализации (Intel VT/AMD-V). ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²
Microsoft Learn, Hyper-V architecture (Performance Tuning). О том, что Hyper-V — гипервизор типа 1, корневой раздел владеет физическими устройствами ввода-вывода, а VMBus даёт высокопроизводительное межраздельное взаимодействие, которое использует разделяемую память. ↩ ↩²
Microsoft Learn, System requirements for Hyper-V on Windows and Windows Server. О том, что требуются 64-разрядный процессор с поддержкой SLAT и VM Monitor Mode Extensions; о возможности подтвердить, что требования выполнены, в поле «Hyper-V Requirements» systeminfo; о том, что пока гипервизор работает, отображается «A hypervisor has been detected»; и о том, что Discrete Device Assignment может назначить конкретное устройство напрямую дочернему разделу. ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Appendix B: Hyper-V Architecture and Feature Overview. О том, что VMMS (Virtual Machine Management Service) управляет состоянием ВМ в дочерних разделах, и для каждой ВМ в пользовательском режиме в корневом разделе стартует рабочий процесс (VMWP). ↩
Microsoft Learn, Comparing WSL Versions. О том, что WSL2 запускает настоящее ядро Linux внутри лёгкой служебной ВМ, и об оговорках при совместном использовании с актуальными VMware и VirtualBox. ↩
Microsoft Learn, Windows Sandbox architecture. О том, что Windows Sandbox — лёгкая среда Windows, которая сочетает технологию контейнеров с изоляцией гипервизором. ↩
Microsoft Learn, Windows Hypervisor Platform. О том, что предусмотрен API пользовательского режима, чтобы сторонний стек виртуализации мог создавать и управлять разделами поверх гипервизора Windows. ↩
Microsoft Learn, Enable Hotpatch for Azure Arc-enabled servers. О том, что состояние работы VBS (виртуального безопасного режима) можно подтвердить через VirtualizationBasedSecurityStatus класса Win32_DeviceGuard. ↩
Microsoft Learn, Install Hyper-V. О том, что Hyper-V можно включить в Windows 10/11 Pro или Enterprise и подобном и нельзя установить в редакции Home. ↩

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

Глубины виртуализации Windows (часть 3) — виртуальные машины, которые загружаются за секунды: почему WSL2, Windows Sandbox и контейнеры такие лёгкие

Почему WSL2 и Windows Sandbox стартуют за секунды и ощущаются такими лёгкими? Статья разбирает механизмы — от динамического базового обра...

Читать статью

Глубины виртуализации Windows (часть 2) — память, которую не видит даже ядро: как работают VBS, HVCI и Credential Guard

На чистой установке на совместимом оборудовании VBS включена по умолчанию и с помощью гипервизора и SLAT создаёт изоляцию сильнее ядра. С...

Читать статью

Win32 Thread Pool API — параллелизм без создания потоков через CreateThreadpoolWork

По всему нативному коду разбросаны вызовы CreateThread? Статья разбирает Thread Pool API Win32, переработанный в Vista, — четыре объекта ...

Читать статью

Именованные каналы на практике — стандартный IPC Windows: от проектирования до безопасности

Практическое руководство по именованным каналам — стандартному межпроцессному взаимодействию Windows. Статья по первичным источникам разб...

Читать статью

Обработка ошибок и повторные попытки в PowerShell — от ловушки нерабочего try/catch до exit code и типовых схем повтора

Разбираем на практике различия между завершающими и незавершающими ошибками в PowerShell, ловушку неработающего try/catch и приём -ErrorA...

Читать статью

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Технические темы Windows

Раздел о разработке Windows, расследовании сбоев и использовании существующих активов.

Открыть тему

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Разработка приложений для Windows

Бизнес-приложения, интеграция оборудования и средства связи — от требований до разработки.

Открыть услугу Связаться с нами

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Когда включают Hyper-V, где на самом деле работает хостовый Windows?: Гипервизор берёт прямой контроль над тем, как распределяются физические ЦП и память, а хостовый Windows работает внутри особого раздела, который называется корневым разделом. Управление физическими устройствами обычно выполняют драйверы на стороне корневого раздела. Корневой раздел держит драйверы устройств и стек управления виртуализацией, но владение физическими ЦП принадлежит гипервизору.
Значит ли «Виртуализация: включено» в Диспетчере задач, что Hyper-V работает?: Нет. Это отображение показывает, включены ли расширения виртуализации ЦП (Intel VT-x/AMD-V) в прошивке. Чтобы увидеть, работает ли гипервизор на самом деле, ищите «A hypervisor has been detected» в systeminfo или проверяйте Win32_ComputerSystem.HypervisorPresent.
Почему гипервизор работает, хотя я никогда не создавал ВМ?: В Windows 11 безопасность на основе виртуализации (VBS) включена по умолчанию на устройствах, которые удовлетворяют условиям — например, чистая установка на совместимом оборудовании, — а VBS построена на гипервизоре Windows. То же верно, если вы используете WSL2 или Windows Sandbox. То, что гипервизор работает без всякой связи с использованием ВМ, — не редкость.
Что такое SLAT и почему он обязателен для Hyper-V?: SLAT (Second Level Address Translation) — механизм, которым ЦП переводит гостевые физические адреса в настоящие физические; реализации — Intel EPT и AMD RVI. Без него гипервизору пришлось бы вести таблицы перевода программно, что с точки зрения производительности нереалистично, поэтому актуальный Hyper-V считает это жёстким требованием.
Если включить Hyper-V, перестанут ли работать VirtualBox и VMware?: Поскольку гипервизор монопольно использует расширения виртуализации ЦП, сторонний гипервизор не может работать традиционным способом. Однако актуальные VirtualBox и VMware имеют режим, который работает поверх гипервизора Windows (через Windows Hypervisor Platform), поэтому недавние версии каждого могут сосуществовать.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.

Открыть профиль Связаться с нами

Публичные ссылки

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

Вернуться в блог

«Глубины виртуализации Windows» — все 3 части

1. Сначала вывод

2. Со стороны ЦП — ещё одна привилегия ниже колец

2.1. Краткое повторение защиты кольцами

2.2. Расширения виртуализации — режим, зарезервированный для гипервизора

2.3. Тип 1 и тип 2 — разница в том, где он сидит

3. Разделы — единица изоляции

3.1. Роли, которые есть только у корневого раздела

3.2. Мир, каким его видит дочерний раздел

4. Со стороны памяти — перевод адреса получает ещё один уровень

4.1. Три вида адресов

4.2. SLAT — двухуровневый перевод аппаратно

5. Со стороны ввода-вывода устройств — VMBus и два вида устройств

5.1. Пределы эмулируемых устройств

5.2. VMBus и VSP/VSC — быстрый путь, спроектированный для виртуализации

6. Почему это не чужая проблема, даже если вы никогда не используете ВМ

7. Посмотрите сами

8. Три прочтения, которых стоит избегать на практике

8.1. «Мы не включали Hyper-V, так что виртуализация к нашим ПК не относится»

8.2. «Диспетчер задач говорит „Виртуализация: включено“, значит Hyper-V работает»

8.3. «Если ВМ медленная, это проблема гостевой ОС»

9. Итоги

Похожие статьи

Смежные области консультирования

Справочные ссылки

Похожие статьи

Глубины виртуализации Windows (часть 3) — виртуальные машины, которые загружаются за секунды: почему WSL2, Windows Sandbox и контейнеры такие лёгкие

Глубины виртуализации Windows (часть 2) — память, которую не видит даже ядро: как работают VBS, HVCI и Credential Guard

Win32 Thread Pool API — параллелизм без создания потоков через CreateThreadpoolWork

Именованные каналы на практике — стандартный IPC Windows: от проектирования до безопасности

Обработка ошибок и повторные попытки в PowerShell — от ловушки нерабочего try/catch до exit code и типовых схем повтора

Связанные темы

Технические темы Windows

Услуги по этой теме

Разработка приложений для Windows

Частые вопросы

Об авторе

Го Комура