Microsoft Hyper-V (кодовое имя Viridian) — система аппаратной виртуализации для x64-систем на основе гипервизора. Бета-версия Hyper-V была включена в x64-версии Windows Server 2008, а законченная версия (автоматически, через Windows Update) была выпущена 26 июня 2008. Ранее была известна как виртуализация Windows Server (Windows Server Virtualization).
Версии и варианты Hyper-V существует в двух вариантах: Как отдельный продукт Microsoft Hyper-V Server. Существуют следующие версии: Hyper-V Server 2022 (текущая версия Hyper-V), Hyper-V Server 2019, Hyper-V Server 2016, Hyper-V Server 2012 R2, Hyper-V Server 2012, Hyper-V Server 2008 R2 и Hyper-V Server 2008. Как роль Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008 и x64-разрядной Pro- и Enterprise-версии Windows 8, Windows 8.1, Windows 10. Отдельная версия Hyper-V Server — бесплатная. Первая версия была выпущена 1 октября 2008 года. Является базовым («Server Core») вариантом Windows Server 2008, то есть включает в себя полную функциональность Hyper-V; прочие роли Windows 2008 Server отключены, также ограничены службы Windows. Бесплатная 64-разрядная Core-версия Hyper-V ограничена интерфейсом командной строки (CLI PowerShell), где конфигурация текущей ОС, физического аппаратного и программного оборудования выполняется при помощи команд оболочки. Новое меню интерфейса управления позволяет выполнить простую первичную конфигурацию, а некоторые свободно распространяемые скрипты расширяют данную концепцию. Администрирование и конфигурирование виртуального сервера (или гостевых ОС) выполняется с помощью ПО, установленного на ПК под управлением Windows Vista, Windows 7 или Windows 2008 Server с установленным дополнением для администрирования Hyper-V из MMC. Другим вариантом администрирования/конфигурирования сервера Windows 2008 Core является использование удалённой Windows или Windows Server при перенаправлении (некоторой) консоли управления (MMC), указывающей на Core Server. Это значительно упрощает настройку, сводя её к нескольким щелчкам мыши.
В Windows Server 2012 включена обновлённая версия Hyper-V.
Архитектура
Главнейшие особенности архитектуры Hyper-V:
ядро гипервизора (hvix.sys для процессоров Intel, или hvax.sys для процессоров AMD) загружается еще до ядра Windows. сама основная Windows хоста виртуализации исполняется «под гипервизором» в разделе (виртуальной машине) 0, имеющей прямой доступ ко всей аппаратуре. ядро гипервизора принципиально не поддерживает никакие кернел-модули, драйвера и плагины. ядро гипервизора имеет API системных вызовов. Реализован как некоторые ошибочные коды инструкций машинного кода (документация есть на сайте Microsoft). среди системных вызовов имеются: создание и уничтожение разделов (виртуальных машин) настройки используемой разделом памяти, а также присвоение физических процессоров — виртуальным процессорам раздела прямое переотображение страниц из одного раздела в другой генерация «аппаратных» прерываний в другом разделе канал для обмена сообщениями между разделами такой же канал, только для чтения, вторым (пишущим) концом является ядро гипервизора, предназначенный для ведения журнала событий, случившихся в ядре (возможно, в реальном времени) по утверждениям сотрудников Microsoft, сделанным на форумах — ядро гипервизора является hard realtime OS, что навсегда избавило Microsoft от нужды поддерживать hard realtime в ядре Windows. в отдельный раздел может загружаться не только полная гостевая ОС, но и ее эмуляция — тот же API, но реализованный как обмен сообщений с сервером, находящемся в родительском разделе. такой «огрызок» Windows (только Win32, и то не полный) используется, начиная с Windows 10 и Server 2016, для хранения критичных по безопасности данных LSA (подсистемы проверки паролей/аутентификации, аналогичная pamd в Linux), а также для исполнения проверки ЭЦП на драйверах режима ядра (и других исполняемых файлах) основной Windows. поддерживается Hyper-V внутри Hyper-V, то есть «гость», сам являющийся хостом виртуализации. по утверждениям сотрудников Microsoft — а) оптимизация кода под исполнение в «госте» («мягкая» паравиртуализация) для Hyper-V делается так же, как и для Xen и б) сама OS Windows, примерно во времена Windows 7, была старательно оптимизирована таким образом.
Что касается «гостевой» аппаратуры и ввода-вывода, то в Hyper-V она поддерживается так:
в разделе 0 (основной Windows хоста) размещается некий код, реагирующий на некие события в «гостях», и реализующий всю логику работы виртуального устройства Этот код (сервер эмуляции устройства) называется «VSP» (Virtualization Service Provider). Например — storvsp.sys — сервер эмуляции дисков, обращается к нижележащему .sys модулю поддержки форматов VHD(X), а тот в свою очередь — к файловой системе хоста (все внутри ядра хоста). Аналогично vmswitch.sys — VSP для «гостевых» сетевых адаптеров (вдобавок содержит функционал, аналогичный драйверу «br» в ядре Linux, и, в частности, дает Windows поддержку VLAN — для включения и настройки нужно использовать PowerShell, создание виртуальных машин при этом — не обязательно, достаточно установки Hyper-V). обычно VSP является кернел-модулем основной Windows, это позволяет ему обращаться к нижележащему (например, к файловой системе, где находится .VHDX «диск в файле») — наиболее быстрым образом, без системных вызовов и тем более без аналогов copy_to/from_user() (тут использован термин из Linux) для основных потоков данных. в основной Windows есть и процесс VMMS.EXE, следящий за виртуальной машиной, но он не занимается вводом-выводом больших потоков данных виртуальные устройства бывают трех разновидностей: эмулируемые (медленные): эмуляция на уровне регистров, портов, памяти и прерываний. Одна транзакция с таким устройством будет включать в себя большое количество «наступаний» на виртуализированные регистры, а каждое такое «наступание» означает «провал» в ядро гипервизора, отправку сообщения в раздел VSP, исполнение там, и отправку ответа. Это необходимо тогда, когда есть необходимость использовать имеющиеся драйвера настоящего оборудования внутри «гостя». синтетические (быстрые), они же — «Enlightened I/O»: используется два способа общения с VSP: а) устройство на «госте» понимается как поддерживающее DMA, при этом ниже драйвера устройства на «госте» создается эмулируемый IOMMU (I/O Memory Management Unit — «Устройство управления памятью ввода-вывода», исполняющее для DMA ту же роль, что и таблицы страниц/TLB для процессора), который переотображает страницы DMA-буфера в память раздела с VSP, применяя системные вызовы ядра гипервизора. Это используется для основного потока больших данных. б) отправка сообщений в VSP через канал обмена сообщениями, который поддерживается системными вызовами ядра гипервизора. Это используется для команд и ответов на них. на такую архитектуру прекрасно ложится, например, протокол SCSI, который предусматривает два в общем случае различных канала связи — один для коротких команд и ответов на них, другой для самих данных, при этом к данным не добавляется никаких дополнительных заголовков и иных метаданных, и при этом данные пишет в (или читает из) память хоста/контроллера/инициатора — периферийное устройство по своей инициативе (а не наоборот). Естественно, «инициатива» в конечном счете вызвана полученной устройством от инициатора командой. синтетические устройства обязательно требуют специального драйвера в «госте». «Гостевой» драйвер синтетического устройства называется «VSC», то есть Virtualization Service Client (например — storvsc.sys — драйвер синтетического SCSI контроллера для «гостей» с Windows). этот драйвер основан на так называемой VMBus. VMBus представляет собой некоторый аналог шины USB (скорее даже 1394, основанный на Remote DMA, то есть возможности для периферии по своей инициативе писать/читать выделенные части памяти хоста), в которой вместо кабеля используется канал обмена сообщениями между разделами и переотображение страниц из раздела в раздел (эмулируемый IOMMU является частью VMBus). Так же, как и USB и 1394, VMBus совместима с Plug and Play в Windows. VSC являются дочерними устройствами VMBus, примерная аналогия с USB: к компьютеру подключен внешний жесткий диск со встроенным хабом, в порты хаба воткнуты переходник USB->Ethernet и USB Wi-FI адаптер. В случае VMBus — вместо кабеля — канал обмена сообщениями и переотображение страниц, вместо VSP — встроенные чипы USB-устройств и их прошивки, вместо VSC — встроенные в Windows драйверы UAStor (USB диски) и RNDIS (USB сетевые устройства). естественно, драйвер синтетического устройства требует всего стека VMBus. Однако такие стеки разработаны Microsoft, например, для Debian Linux, еще году в 2014. с частичным прямым доступом к аппаратуре со стороны «гостя» (самые быстрые). едва ли не единственным примером такого является технология SR-IOV для сетевых адаптеров. она выглядит примерно так: «взрослые» сетевые адаптеры имеют аппаратный классификатор входящих пакетов, который раскладывает их по нескольким независимым DMA-движкам для записи в память. Классификация может быть — по MAC, по VLAN, по IP и др. Также они имеют несколько очередей отправления, каждая — со своим DMA-движком. Известно, что драйвер «br» в Linux умеет этим пользоваться (если аппаратура поддерживает это) для реализации настраиваемого свитча с поддержкой VLAN и QoS. Это называется «полу-аппаратным свитчеванием», и часто применяется между LAN-портами роутеров (свитчи скорее используют полностью аппаратное свитчевание, когда данные вообще не попадают в основную память, а обрабатываются внутри многопортового Ethernet чипа). если такой адаптер совместим с SR-IOV, то все его DMA-движки правильно описаны как совершенно независимые суб-устройства в PCI config space. при эмуляции PCI config space в «гостях» (включая VM 0) Hyper-V распределяет DMA-движки между «гостями» (и хостом), показывая каждому «гостю» лишь части этого сложного PCI-устройства. в каждом «госте» (и хосте) BAR-апертуры этого «частичного PCI-устройства» получают прямой доступ со стороны данного раздела. там к суб-устройству загружается драйвер (возможно, тот же, что и для него «вообще» без использования Hyper-V), который видит эту «часть движков» и назначает им MAC-адрес. по утверждению сотрудников Microsoft, еще никогда возможность, которая для пользователя выглядит как включение всего одной галочки, не потребовала такого огромного труда. Правки вносились и в ядро Hyper-V, и в pci.sys из Windows, и в vmswitch.sys, и в netvsc.sys Hyper-V поставляется с эмулируемым ATA контроллером диска (с обычным драйвером в «госте») и с синтетическим драйвером SCSI контроллера. что касается виртуализации видеокарты, то Hyper-V поддерживает две технологии: эмулируемый примитивный framebuffer (видеокарта вообще без GPU, даже 2D) VESA VGA, который, в частности, используется для инсталляции гостевой ОС синтетический RemoteFX Video Adapter. Он разработан по образу и подобию rdpdd.sys — видеодрайвера для удаленного рабочего стола, который все рисование отправляет по сети в терминал выбор между двумя возможностями делается в стандартной Hyper-V консоли vmconnect.exe. Enhanced Mode — это второе. vmconnect.exe в Enhanced Mode работает примерно так же, как и Remote Desktop Client (с поддержкой, например, clipboard). Разница лишь в том, что используется другой IP адрес и порт, а именно — IP хоста виртуализации и порт одного из процессов VMMS.EXE в нем (в случае Remote Desktop, которым также можно пользоваться, нужен IP адрес «гостя», а порт — стандартный для Remote Desktop). Кроме того, Enhanced Mode не требует включения Remote Desktop в «госте». технология RemoteFX (есть и для Remote Desktop) позволяет использовать Direct3D через удаленный рабочий стол. При этом все текстуры предзагружаются в память терминала.
Системные требования / Спецификации