Почему Hyper-V после установки роли не становится Type 2?

Нет, не становится. После включения роли гипервизор Hyper-V запускается ниже разделов Windows: Windows Server для управления работает в корневом разделе, а гостевые VM — в дочерних. Корневой раздел управляет ресурсами и доступом к устройствам, но наличие Windows в нём не означает, что Hyper-V является приложением поверх основной ОС.

Чем KVM отличается от QEMU и libvirt?

KVM отвечает за использование аппаратных возможностей процессора для выполнения гостевого кода. Сам по себе он не является универсальной платформой управления виртуальными машинами. QEMU обычно работает как пользовательский процесс: создаёт виртуальную машину, представляет ей виртуальные устройства и при наличии KVM передаёт выполнение гостевого кода процессору с аппаратным ускорением. libvirt расположен на уровне управления. Это набор API, служб и утилит, с помощью которых можно создавать и администрировать VM, сети и хранилища. Он способен управлять QEMU/KVM, но не выполняет функции KVM и не моделирует оборудование вместо QEMU. Поэтому выражение «виртуализация KVM» на практике часто обозначает стек нескольких компонентов. Например, Proxmox VE использует KVM/QEMU для виртуальных машин. При выборе платформы важно проверять не только наличие KVM, но и состав конкретного решения, его границы управления и поддерживаемую конфигурацию.

Достаточно ли Intel VT-x или AMD-V для установки гипервизора?

Перед установкой сначала зафиксируйте точный состав сервера: модель, процессоры, RAID/HBA-контроллеры, сетевые адаптеры, накопители и версию BIOS/UEFI. Затем сопоставьте этот список с официальной матрицей совместимости именно того релиза платформы виртуализации, который планируется использовать. Похожая модель устройства не является подтверждением поддержки. После этого убедитесь, что VT-x или AMD-V поддерживается процессором и не отключена в firmware. Если сценарий зависит от виртуализации памяти, проверьте SLAT; если требуется назначать VM PCIe-устройства, нужны IOMMU и поддержка со стороны firmware, гипервизора, самого устройства и гостевого драйвера. Наконец, сверяйте требования к сети, хранилищу, драйверам, загрузочному режиму и лицензированию. Для кластера, миграций или высокой доступности проверяют не один хост, а все узлы и общие компоненты инфраструктуры.

Нужен ли IOMMU для passthrough сетевой карты или GPU в VM?

Да, для контролируемого назначения PCIe-устройств виртуальной машине нужен Intel VT-d или AMD IOMMU. VT-x и AMD-V относятся к виртуализации CPU и не подтверждают наличие IOMMU. Помимо него требуется поддержка со стороны firmware, выбранного гипервизора, самого устройства и драйвера в гостевой ОС.

Можно ли использовать паравиртуальные драйверы с обычной гостевой ОС?

Да, обычно можно. Современную поддерживаемую гостевую ОС не требуется переделывать или собирать заново: достаточно включить встроенный либо установить совместимый паравиртуальный драйвер или пакет интеграции. Например, для KVM/QEMU используются VirtIO, а для Hyper-V и VMware доступны собственные интеграционные компоненты.

Гипервизоры и типы виртуализации: Type 1, Type 2, полная и паравиртуализация

Type 1-гипервизор размещается на сервере как слой виртуализации с прямым контролем аппаратных ресурсов, а Type 2 работает поверх основной ОС хоста и обычно удобен для локальных лабораторий, разработки и тестов. Полная виртуализация позволяет запускать немодифицированную гостевую ОС, а паравиртуализация добавляет оптимизированные интерфейсы и драйверы для обмена с гипервизором. Intel VT-x и AMD-V помогают процессору выполнять гостевой код в специальных режимах виртуализации, но сами по себе не подтверждают совместимость сервера с выбранной платформой.

Что такое гипервизор и где он находится

Гипервизор — программный слой, который запускает виртуальные машины, изолирует их и предоставляет им виртуальные процессоры, память, диски, сетевые адаптеры и другие устройства. Базовый принцип работы VM и распределения ресурсов разобран в статье «Серверная виртуализация: что это, как работает и зачем нужна».

Классификация Type 1 и Type 2 описывает прежде всего архитектурное место гипервизора относительно оборудования и основной ОС. Она не является автоматическим рейтингом производительности, безопасности, отказоустойчивости или набора корпоративных функций. Эти свойства определяются конкретной платформой, её версией, настройкой, драйверами, оборудованием и архитектурой всей инфраструктуры.

Архитектурное различие типов гипервизоров

Критерий	Type 1	Type 2
Расположение	Гипервизор работает непосредственно над оборудованием сервера.	Гипервизор работает как приложение основной ОС хоста.
Доступ к устройствам	Используются драйверы и компоненты самой платформы виртуализации либо её управляющего домена или раздела.	Доступ к оборудованию обычно проходит через драйверы и службы основной ОС.
Типичный сценарий	Серверные VM, выделенные хосты и инфраструктурные нагрузки.	Разработка, обучение, изолированные тесты на рабочем компьютере.
Примеры	VMware ESXi, Hyper-V, Xen; стек KVM/QEMU на Linux используют в том числе Proxmox VE.	VirtualBox, VMware Workstation.
Что нельзя заключить только по типу	Что платформа быстрее, безопаснее или подходит для любой нагрузки.	Что она непригодна для любой серверной задачи: решение зависит от требований и поддержки.

Type 1: почему его называют bare-metal

Гипервизор Type 1 часто называют bare-metal («на голом оборудовании»), потому что его базовый слой запускается непосредственно на физическом сервере, а не как обычная программа внутри универсальной настольной или серверной ОС. Это не означает, что в архитектуре вообще нет ОС: у платформы могут быть управляющие компоненты, сервисные домены или отдельные разделы с ОС.

К распространённым примерам Type 1 относят VMware ESXi, Hyper-V и Xen. Это примеры архитектурной категории, а не утверждение, что продукты равнозначны по поддерживаемым устройствам, средствам управления, миграции, высокой доступности или лицензированию. Сравнение платформ по этим критериям — отдельная задача: «VMware, Hyper-V, Proxmox, KVM и Xen: выбор платформы виртуализации».

Почему Hyper-V не становится Type 2 после установки роли

Hyper-V может устанавливаться как роль Windows Server, но после включения роли архитектура не сводится к приложению, работающему над Windows. Гипервизор Hyper-V запускается ниже разделов: Windows Server, с которого администратор обычно управляет хостом, работает в корневом разделе (root partition), а гостевые VM — в дочерних разделах (child partitions). Корневой раздел имеет особую роль в управлении и доступе к устройствам; дочерние разделы получают доступ к оборудованию через предоставляемые виртуальные устройства и службы. Поэтому наличие Windows в управляющем разделе не делает Hyper-V гипервизором Type 2.

Xen: гипервизор, Dom0 и DomU

В Xen сам гипервизор расположен над оборудованием. Привилегированный Dom0 запускает и обслуживает гостевые домены, обычно участвуя в обработке их ввода-вывода. Гостевые DomU выполняют ОС и приложения как непривилегированные домены. Dom0 — управляющая ОС или домен, но не признак Type 2: гипервизор Xen остаётся отдельным нижележащим слоем.

KVM, QEMU, libvirt и Proxmox VE: разные роли

KVM — подсистема ядра Linux для аппаратно ускоренной виртуализации, а не самостоятельная универсальная управляющая платформа. Обычно пользовательский процесс QEMU создаёт VM, моделирует её виртуальное оборудование и при наличии KVM передаёт выполнение гостевого кода процессору с аппаратным ускорением. libvirt — отдельный набор API, служб и утилит для управления VM, сетями и хранилищами; он может управлять QEMU/KVM, но не заменяет ни KVM, ни QEMU.

Стек KVM/QEMU используется, в частности, Proxmox VE для виртуальных машин. В упрощённой классификации серверный Linux с KVM/QEMU обычно рассматривают в одном ряду с Type 1-подходом, поскольку виртуализация опирается на KVM в ядре и аппаратные механизмы CPU, а не на приложение поверх основной настольной ОС по модели Type 2. Однако для проектирования важнее проверить состав конкретной платформы, её границы управления и поддерживаемую конфигурацию. Практическое разграничение компонентов описано в статье «KVM, QEMU и libvirt в Linux: установка, VM, virsh и Guest Agent».

Type 2: гипервизор поверх основной ОС

Гипервизор Type 2 запускается как программа в основной ОС — например, Windows, Linux или macOS. Для работы с сетью, дисками, USB и другими устройствами он обычно использует драйверы и службы этой ОС. К этому типу обычно относят VirtualBox и VMware Workstation.

Такая архитектура удобна, когда VM нужна рядом с рабочими приложениями: для обучения, воспроизведения ошибки, сборки ПО или изолированного теста. Она не отменяет необходимости выделять ресурсы и обновлять хостовую ОС, но обычно не является исходной моделью для постоянно работающей серверной инфраструктуры. Для локальной лаборатории см. «VirtualBox и VMware Workstation для лаборатории: выбор и первая VM».

Type 1 — недостаточный критерий выбора

Перед выбором серверной платформы отдельно проверьте поддержку модели сервера, контроллеров хранения, сетевых адаптеров, загрузочного режима, версий firmware, средств управления, условий лицензирования и требований к доступности. Даже два Type 1-решения могут заметно различаться по этим параметрам.

Полная виртуализация: немодифицированная гостевая ОС

Полная виртуализация предоставляет VM виртуальную аппаратную платформу: виртуальные CPU, контроллеры, сетевые адаптеры, диски, таймеры и другие устройства. Гостевая ОС взаимодействует с этим окружением так, как если бы оно было физической машиной. Поэтому полная виртуализация позволяет запускать немодифицированную гостевую ОС — при условии, что её версия и виртуальное оборудование поддерживаются выбранной платформой.

Виртуальное оборудование не обязательно совпадает с физическими компонентами хоста. Например, гипервизор может представить гостю распространённый эмулируемый сетевой контроллер, хотя физический NIC сервера имеет другую модель. Такое программное воспроизведение интерфейса называется эмуляцией. Эмуляция устройства — не то же самое, что полная эмуляция процессора или другой аппаратной архитектуры.

Паравиртуализация и паравиртуальные драйверы

Паравиртуализация заменяет часть взаимодействий гостевой системы с виртуальной платформой специальными интерфейсами, рассчитанными на работу с гипервизором. Вместо имитации некоторых операций и устройств гость использует осведомлённый о виртуальной среде механизм: например, гипервызовы или специализированный драйвер сетевого либо дискового устройства.

Исторически паравиртуализация могла требовать изменения исходного кода гостевого ядра или его специальной сборки. В распространённом современном сценарии переделывать ядро не требуется: в поддерживаемой гостевой ОС включают встроенный либо устанавливают совместимый паравиртуальный драйвер. Например, VirtIO предоставляет стандарт паравиртуальных устройств для KVM/QEMU; VMware Tools могут содержать драйверы и интеграционные компоненты для поддерживаемых гостевых ОС; Hyper-V Integration Services обеспечивают интеграцию гостя с Hyper-V. Набор доступных компонентов зависит от версии платформы и гостевой ОС.

Полная виртуализация и паравиртуализация решают разные части задачи

Аспект	Полная виртуализация	Паравиртуализация
Что видит гость	Виртуальную аппаратную платформу.	Специальный интерфейс или устройство для части операций.
Нужна ли специальная модификация ОС	Нет, если ОС поддерживается виртуальным оборудованием.	Не всегда: часто достаточно установить совместимый драйвер или интеграционный пакет.
Пример	Гость загружается с эмулируемого контроллера диска.	Гость использует сетевой или дисковый драйвер VirtIO.
Совместимость между подходами	Может использоваться одновременно с паравиртуальными устройствами.	Не отменяет полную виртуализацию CPU и базовой аппаратной платформы.

Следовательно, полная виртуализация и паравиртуализация — не взаимоисключающие режимы «всей VM». Типичная современная VM запускает немодифицированную ОС на виртуальном оборудовании с аппаратной виртуализацией CPU, но для диска и сети использует паравиртуальные драйверы. Xen также поддерживает разные модели, включая HVM, PV и PVH; выбор зависит от поддерживаемых возможностей гостя и платформы.

Аппаратная виртуализация CPU: Intel VT-x и AMD-V

Intel VT-x и AMD-V — аппаратные расширения x86-процессоров для виртуализации CPU. Они позволяют гипервизору выполнять гостевой код в специальных режимах процессора и контролируемо обрабатывать чувствительные операции гостя. Это основа аппаратно ускоренного запуска большинства современных x86 VM; общее понятие раскрыто в глоссарии «Аппаратная виртуализация».

Выражение «программная виртуализация» неоднозначно. Иногда им называют старые подходы, где часть привилегированных операций обрабатывалась программно без расширений CPU. Иногда под ним понимают эмуляцию, когда программа воспроизводит процессор или устройства. Это разные механизмы: эмуляция может быть нужна, например, для другой архитектуры CPU, а аппаратная виртуализация ускоряет выполнение совместимого гостевого кода на процессоре хоста.

SLAT, EPT и NPT/RVI: виртуализация памяти

Для памяти процессор должен преобразовать виртуальные адреса процессов гостевой ОС сначала в адреса, которые гость считает физическими, а затем в реальные физические адреса хоста. SLAT — аппаратная двухуровневая трансляция адресов, уменьшающая необходимость постоянного участия гипервизора в этой работе. У Intel соответствующий механизм называется Extended Page Tables (EPT), у AMD — Nested Page Tables (NPT); в документации AMD также встречается название Rapid Virtualization Indexing (RVI).

SLAT не заменяет выделение достаточного объёма оперативной памяти и не исправляет медленное хранилище или перегрузку CPU. Его назначение — снизить накладные расходы преобразования адресов при виртуализации памяти. Анализ дефицита CPU, памяти, диска и сети вынесен в статью «Производительность виртуализации: ресурсы VM и поиск узких мест».

VT-d и IOMMU — отдельная проверка для устройств

Intel VT-x и AMD-V относятся к выполнению кода виртуальных CPU. Для контролируемого назначения PCIe-устройств VM и управления DMA нужны другие механизмы: Intel VT-d или AMD IOMMU. Наличие VT-x либо AMD-V не означает, что доступен IOMMU, и наоборот. Это особенно важно для passthrough сетевых адаптеров, HBA или GPU; требования разобраны в статье «GPU passthrough и вложенная виртуализация: требования, настройка и ограничения».

Почему VT-x или AMD-V недостаточно для выбора гипервизора

Строка «Intel VT-x» или «AMD-V» в спецификации процессора подтверждает лишь наличие определённого CPU-механизма. Она не доказывает, что конкретный сервер готов к установке конкретного гипервизора или запуску требуемой VM. Возможность зависит от модели CPU, версии и настроек BIOS/UEFI, релиза гипервизора, режима загрузки, поддержки контроллеров и NIC, наличия SLAT или IOMMU для нужного сценария, а также от ограничений самой платформы.

Как проверить готовность сервера к виртуализации до установки

Это проверка совместимости, а не процедура включения параметров firmware.

1
Зафиксируйте состав сервера
Запишите точную модель сервера, процессоров, RAID/HBA-контроллеров, сетевых адаптеров, накопителей и версию BIOS/UEFI. Ожидаемый результат — инвентарный список, по которому можно искать совместимость. Если модель устройства неизвестна, сначала получите её из интерфейса управления сервером, ОС или инвентаризации.
2
Проверьте матрицу совместимости выбранной платформы
Сопоставьте сервер и его адаптеры с официальной матрицей совместимости либо руководством именно того релиза гипервизора, который планируется установить. Ожидаемый результат — подтверждённая поддержка или понятный список неподдерживаемых компонентов. Если устройства нет в документации, не заменяйте проверку предположением по похожей модели: выберите поддерживаемый компонент или уточните поддерживаемую архитектуру.
3
Проверьте доступность CPU-функций
Убедитесь, что процессор поддерживает VT-x или AMD-V, а firmware не отключает виртуализацию. Для функций, зависящих от памяти или passthrough, отдельно проверьте SLAT и IOMMU. Ожидаемый результат — платформа или ОС видит необходимые возможности. Если функция не обнаружена, проверьте модель CPU, настройки firmware и необходимость полного выключения питания по документации сервера.
4
Сверьте требования сценария
Отдельно проверьте требования к сети, хранилищу, загрузочному режиму, драйверам и лицензированию. Ожидаемый результат — список зависимостей для установки и дальнейшей эксплуатации. Если нужен кластер, миграции или назначение устройств VM, не ограничивайтесь проверкой одного хоста: оцените все узлы и общие компоненты.

О firmware и меню платформы

Названия параметров BIOS/UEFI, разделов меню, кнопок и статусов зависят от производителя, модели и поколения сервера, установленного CPU и версии firmware. Требования VT-x/AMD-V, SLAT, IOMMU и поддерживаемого оборудования также зависят от версии гипервизора. Для конкретной системы сверяйтесь с официальным руководством производителя сервера и матрицей совместимости выбранной платформы; практический порядок включения рассмотрен в статье «Как включить Intel VT-x, AMD-V и IOMMU в BIOS/UEFI сервера».

Как применить классификации к задаче

Для локального стенда на рабочем компьютере обычно рассматривают Type 2-гипервизор: важны удобство запуска, совместимость с основной ОС и воспроизводимость теста.
Для выделенного сервера с постоянно работающими VM обычно начинают с серверной Type 1-платформы или стека KVM/QEMU, затем проверяют совместимость оборудования, модель управления, лицензирование и требования к доступности.
Если требуется запуск обычной гостевой ОС без переделки ядра, нужна поддерживаемая полная виртуализация; затем имеет смысл проверить доступность оптимизированных драйверов диска и сети.
Если планируется passthrough устройств, кроме VT-x или AMD-V отдельно требуются IOMMU, поддержка со стороны firmware, гипервизора, устройства и гостевого драйвера.
Выбор между VMware, Hyper-V, Proxmox VE, KVM/QEMU/libvirt и Xen нельзя делать только по ярлыку Type 1: сравнивают поддерживаемые релизы, эксплуатацию, миграции, HA, экосистему и компетенции команды.

Термины в статье

Аппаратная виртуализация: Аппаратная виртуализация — способ запуска ВМ с поддержкой процессора и платформы, где привилегированные операции гостя обрабатываются специальными механизмами CPU, а не только программной эмуляцией.
Виртуальная машина: Изолированная вычислительная среда с виртуальными процессорами, памятью, дисками и сетевыми адаптерами, в которой под управлением гипервизора работает гостевая ОС.
Виртуальное оборудование: Виртуальное оборудование — логическая аппаратная платформа, которую гипервизор предоставляет ВМ: виртуальные процессоры, память, устройства и системную прошивку.
Высокая доступность: Высокая доступность (HA) — способность системы сохранять сервис или автоматически восстанавливать его с минимальным простоем при отказе компонентов.
Гипервизор: Программный слой, который абстрагирует ресурсы физического хоста, выполняет виртуальные машины и управляет ими.
Гипервизор Type 1: Гипервизор, работающий непосредственно на аппаратном уровне, а не как приложение хостовой ОС, и распределяющий ресурсы сервера между виртуальными машинами.
Гипервизор Type 2: Гипервизор Type 2 — гипервизор, работающий как приложение поверх основной ОС хоста и использующий её драйверы и службы, в отличие от гипервизора Type 1, запускаемого непосредственно на оборудовании.
Паравиртуализация: Метод виртуализации, при котором гостевая ОС или её драйверы используют интерфейсы гипервизора и гипервызовы вместо эмуляции части виртуального оборудования.
Полная виртуализация: Тип системной виртуализации, при котором гипервизор предоставляет ВМ виртуальную аппаратную платформу для запуска немодифицированной гостевой ОС.
Процесс: Процесс — экземпляр выполняемой программы в Linux с PID, виртуальным адресным пространством, состоянием и связанными с ним ресурсами.
Эмуляция: Эмуляция — программное воспроизведение устройства или аппаратной платформы, при котором гостевая система использует их интерфейс без прямого доступа к реальному оборудованию.
Ядро Linux: Ядро Linux — центральный компонент ОС, управляющий аппаратными ресурсами и предоставляющий системные интерфейсы; оно не включает пользовательские утилиты и менеджер пакетов.
Dom0: Dom0 — первый привилегированный управляющий домен Xen, который запускает гостевые домены и обычно обслуживает их ввод-вывод; сам гипервизор Xen работает ниже.
DomU: DomU — непривилегированный гостевой домен Xen, выполняющий ОС и приложения с изолированными ресурсами; доступ к большинству устройств он получает через Dom0.
Guest OS: Операционная система, установленная в виртуальной машине и работающая под управлением гипервизора; не следует путать с хостовой ОС гипервизора типа 2.
HBA: HBA — адаптер ввода-вывода, соединяющий сервер с накопителями или SAN и не формирующий аппаратные RAID-массивы.
Hypercall: Hypercall — вызов интерфейса гипервизора из гостевой ОС для выполнения привилегированной операции, недоступной гостю напрямую на физическом оборудовании.
Intel VT-d: Intel VT-d — технология аппаратной виртуализации ввода-вывода Intel, ограничивающая DMA устройств и позволяющая безопаснее назначать их виртуальным машинам.
Intel VT-x: Intel VT-x — расширение процессоров Intel для аппаратной виртуализации x86, вводящее режимы VMX для выполнения гостевых ОС под контролем гипервизора без полной программной эмуляции.
IOMMU: IOMMU — аппаратный блок, который преобразует адреса DMA-запросов устройств в адреса физической памяти и ограничивает их доступ; нужен для изоляции и прямого назначения PCIe-устройств ВМ.
KVM: Подсистема аппаратной виртуализации ядра Linux, предоставляющая пользовательским мониторам ВМ, обычно QEMU, интерфейс для запуска изолированных виртуальных машин.
libvirt: libvirt — открытый набор библиотек, API, служб и утилит для унифицированного управления ВМ, контейнерами, сетями и хранилищами на платформах виртуализации.
QEMU: QEMU — открытый эмулятор вычислительных систем и монитор виртуальных машин; в Linux он может использовать KVM для виртуализации с аппаратным ускорением.
RAID: Технология объединения нескольких накопителей в логические блочные устройства для повышения производительности и/или отказоустойчивости в зависимости от RAID-уровня.
SLAT: SLAT — аппаратная двухуровневая трансляция адресов памяти, при которой процессор преобразует адреса гостевой ВМ в физические адреса хоста без постоянного участия гипервизора.
vCPU: vCPU — виртуальный логический процессор, предоставляемый виртуальной машине; гипервизор планирует его выполнение на процессорных ресурсах хоста.
VirtIO: VirtIO — стандарт паравиртуальных устройств для виртуальных машин, заменяющий эмулируемое оборудование интерфейсом, оптимизированным для обмена с гипервизором.
VMware: VMware — бренд Broadcom и семейство продуктов виртуализации; серверная платформа vSphere объединяет гипервизор ESXi и средства управления vCenter Server.
VMware Tools: Набор гостевых драйверов и служб VMware, улучшающий интеграцию виртуальной машины с гипервизором и средствами управления.
Xen: Xen — гипервизор первого типа, работающий непосредственно на сервере и поддерживающий режимы виртуализации HVM, PV и PVH.