Hyper-V (Hyper-V)

Перейти к навигации Перейти к поиску
Hyper-V
Скриншот программы Hyper-V
Тип Гипервизор
Разработчик Microsoft
Операционные системы

Windows Server

Windows 8, Windows 8.1, Windows 10, Windows 11 (x64; Pro, Enterprise and Education)
Первый выпуск 28 июня 2008

Microsoft Hyper-V (кодовое имя Viridian[1]) — система аппаратной виртуализации для x64-систем на основе гипервизора[2]. Бета-версия Hyper-V была включена в x64-версии Windows Server 2008, а законченная версия (автоматически, через Windows Update) была выпущена 26 июня 2008[3]. Ранее была известна как виртуализация Windows Server (Windows Server Virtualization).

Версии и варианты[править | править код]

Hyper-V существует в двух вариантах:

  1. Как отдельный продукт 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.
  2. Как роль 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.[4] Бесплатная 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

Главнейшие особенности архитектуры 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). Так же, как и USD и 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 через удаленный рабочий стол. При этом все текстуры предзагружаются в память терминала.

Системные требования / Спецификации[править | править код]

  1. x64-совместимый процессор, поддерживающий запуск x64-версии Windows Server 2008 Standard, Windows Server 2008 Enterprise или Windows Server 2008 Datacenter.
  2. Аппаратная поддержка виртуализации. Это особенность процессоров, дающая возможность аппаратной виртуализации; касается технологий Intel VT и AMD Virtualization (AMD-V, ранее известная как Pacifica).
  3. NX-бит-совместимый процессор и активированная аппаратная поддержка Data Execution Prevention (DEP).
  4. Память объёмом не менее 2 ГБ (каждая виртуальная ОС требует собственного объёма памяти, поэтому в действительности нужно больше).
  5. Windows 2008 Standard (64-bit) Hyper-V Core требует примерно 3 ГБ дискового пространства в установленном виде.
  6. Windows 2008 Standard (64-bit) Hyper-V с GUI требует примерно 8 ГБ дискового пространства в установленном виде.
  7. Windows 2008 Standard (64-bit) Hyper-V с GUI или в виде Core-версии поддерживает до 31 ГБ памяти для работы VM, плюс 1 ГБ для родительской ОС Hyper-V. [1]
  8. Windows 2008 Standard (64-bit) Hyper-V с GUI или в виде Core поддерживает до 8 процессоров с 1, 2 или 4 ядрами.
  9. Windows 2008 Standard (64-bit) Hyper-V с GUI или в виде Core поддерживает до 384 гостевых ОС [2].
  10. Windows 2008 Standard (64-bit) Hyper-V с GUI или в виде Core поддерживает 32-разрядные (x86) и 64-разрядные (x86_64) гостевые виртуальные машины.

Отдельный Hyper-V Server не требует установленного Windows Server 2008, минимальный объём памяти — 1 ГБ, минимум места на диске — 2 ГБ.

Поддержка гостевых ОС[править | править код]

Поддерживаемые/протестированные операционные системы:[5]

Гостевые Windows Server 2008 и Windows HPC Server 2008 могут быть сконфигурированы для 1-, 2- или 4-процессорного SMP, Windows Server 2003 и Windows Vista для 1- или 2-процессорного SMP. Прочие гостевые ОС, такие как Ubuntu Linux 6.06/6.10/7.10 или Fedora 8/9, не поддерживаются, но, тем не менее, могут успешно запускаться.[6][7][8]

Гостевые ОС с поддержкой технологии Enlightened I/O и ядром с поддержкой режима гипервизора, как, например, Windows Server 2008, Windows Vista SP1 и готовящееся предложение от Citrix XenServer и Novell позволят использовать ресурсы хоста более эффективно благодаря тому, что VSC-драйверы в этих гостевых ОС будут взаимодействовать напрямую с VSP через VMbus.[9] ОС без поддержки Enlightened I/O будут запускаться с эмуляцией ввода-вывода;[10] тем не менее компоненты интеграции (которые включают в себя VSC-драйверы) доступны для Windows Server 2003 SP2, Windows XP SP3, Windows Vista SP1 и Linux и позволяют достичь большей производительности.

Гостевые системы Linux также могут быть паравиртуализованы в Hyper-V. Однако сейчас подобным образом официально поддерживаются Microsoft при установке компонентов интеграции только SLES 10 SP3, SLES 11, RHEL и CentOS 5.2, 5.3, 5.4, 5.5, 5.6, 6.0 и 6.1 для x86 и x64.

При использовании гостевых ОС Windows версий до Server 2003 невозможно использование виртуальных SCSI-дисков и адаптеров в них. Это связано с тем, что гостевой драйвер виртуального SCSI-контроллера (STORVSC) основан на подсистеме STORPORT, которая появилась только в Server 2003.

Поддержка Linux[править | править код]

Hyper-V обеспечивает базовую поддержку виртуализации гостевых Linux-систем в режиме эмуляции устройств, не требуя никаких изменений. Эмулируются контроллеры дисков IDE PIIX4 и PCI Ethernet-адаптер DEC 21140 Tulip, однако скорость работы может быть невысокой и имеется ограничение 128 ГБ на диск.

Паравиртуализация достижима при включении модулей ядра Linux или при установке дополнительных компонентов интеграции (Integration Components). Ранние версии компонентов интеграции функционировали как прослойка между интерфейсом гостевого ядра Xen и Hyper-V (Hypercall Translator). Позднее была реализована прямая поддержка шины VMBbus без Xen. 20 июля 2009 года Microsoft опубликовала эти драйверы под лицензией GPL, и они были официально включены в ядро Linux (опция STAGING/HYPERV). В процессе работы над драйверами различные компоненты постепенно покидали ветку STAGING и начиная с версии ядра Linux 3.4 были перенесены в основное дерево[11]. Таким образом, дистрибутивы с ядрами новее, чем 2.6.32, могут включать встроенную поддержку паравиртуализации Hyper-V (однако, как правило, не включают). Данные драйверы содержат поддержку шины VMbus и позволяют гостевой операционной системе Linux работать c устройствами в режиме Enlightened I/O. Поддерживаются устройства Synthetic IDE, Synthetic SCSI и Synthetic Ethernet. Поддерживаются SMP до 4 ядер и такие функции, как синхронизация времени (в RHEL5 только для 32-битных систем), остановка системы (shutdown) и проверка активности (heartbeat).

Для поддерживаемых систем SLES, RHEL и CentOS компания Microsoft бесплатно распространяет Linux Integration Components 2.1 (недоступная ссылка) (для SuSe и RHEL5), Linux Integration Components 3.4 (для RHEL6), которые содержат исходные тексты и скрипты для компиляции, автоматической установки драйверов и автоматической загрузки модулей при старте. Начиная с RHEL 6.4, паравиртуальные драйверы Hyper-V входят в состав системы, поэтому Integration Components более не нужны (хотя и могут применяться).

Интеграция функций мыши гостевой системы Linux ранее достигалась при установке драйверов Citrix XEN Satori InputVSC (являются комбинацией исходных текстов под GPL2 и проприетарных бинарных объектных файлов). В ядре Linux 2.6.39 появилась свободная поддержка InputVSC-мыши. Linux IС 3 также содержат модули поддержки мыши.

Гостевая машина c RedHat Enterprise Linux, работающая под Hyper-V, может пользоваться службами RedHat Networks благодаря лицензии Flex Guest Entitlements[12] (начиная с версии RHEL 5.5). Однако при автоматическом обновлении ядра гостевой системы RHEL 5 может возникнуть проблема, описанная в статье KB2387594.

По состоянию как минимум на 2015 год "гостевые" драйвера Hyper-V для Debian входили в сам дистрибутив, и автоматически устанавливались.

Hyper-V для Windows Server 2012[править | править код]

Версия Hyper-V в Windows Server 2012 года поддерживает Windows 8.1 (32- и 64-разрядную). Также стоит отметить, что максимальное число поддерживаемых процессоров для операционных систем Windows Server и Linux увеличено с четырех до 64.

Веб-интерфейс для Hyper-V[править | править код]

Совместимость VHD с Virtual Server 2005 и Virtual PC 2004/2007[править | править код]

Hyper-V, как Virtual Server 2005 и Virtual PC 2004/2007, хранит виртуальные диски (в том числе системные тома гостевых ОС) в файлах с расширением VHD. Этот файл содержит гостевую ОС целиком, хотя для некоторых файлов можно настроить откаты и пр.

Старые vhd-файлы от Virtual Server 2005 и Virtual PC 2004/2007 можно скопировать и использовать с помощью Windows 2008 Hyper-V Server, но некоторые изменения в виртуальном оборудовании (видео- и сетевая карта) будут означать потребность гостевых ОС в обновлении драйверов, и, как следствие, в случае последних версий Windows может потребоваться повторная активация.

Microsoft не предоставляет ни DLL, ни API для посекторного доступа к vhd-файлам, однако формат открыт и опубликован[13], и многие фирмы разработали такую поддержку сами.

Ограничения[править | править код]

По состоянию на декабрь 2008 года Hyper-V не поддерживает доступ к USB-устройствам или воспроизведение звуков в гостевых ВМ. Тем не менее, обходным маневром для доступа к USB-накопителям в гостевых ВМ может послужить использование Microsoft Remote Desktop Client для открытия доступа к накопителям хоста для «гостей» через соединение Remote Desktop Connection.[14] (по состоянию даже на 2015 год "родная" консоль Hyper-V имеет Enhanced Mode, который по факту и есть Remote Deskop, но с другим способом доступа по сети). Другая возможность — использовать устройства типа USB-over-Network с установкой драйверов в каждую виртуальную машину.

Также Hyper-V весьма слаб в поддержке старых приложений для MS-DOS, в том числе игр. Unreal mode в «гостях» не поддерживается вовсе, хотя он правильно поддерживается в Virtual PC.

Также Hyper-V поддерживает живую миграцию (начиная с Windows Server 2008 R2) гостевых ВМ, где живая миграция понимается как поддержка сетевых соединений и отсутствие прерываний выполнения служб во время переноса ВМ. Ранее вместо этого Hyper-V на Server 2008 редакций Enterprise и Datacenter поддерживал быструю миграцию, во время которой гостевая ВМ приостанавливается на одном хосте и «пробуждается» уже на другом. Такая операция занимает столько времени, сколько требуется для передачи активной памяти гостевой ВМ по сети от первого хоста второму.[15]

См. также[править | править код]

Примечания[править | править код]

  1. Microsoft to ship Windows Server 2008, over time, in eight flavors. Дата обращения: 13 ноября 2007. Архивировано 23 марта 2012 года.
  2. Paul Thurrott. Windows Server Virtualization Preview. Дата обращения: 25 сентября 2007. Архивировано 23 марта 2012 года.
  3. http://www.microsoft.com/presspass/features/2008/jun08/06-26hyperv.mspx (англ.). Дата обращения: 26 июня 2008. Архивировано 23 марта 2012 года.
  4. "Microsoft помогает покупателям преодолеть сложности с виртуализацией и получить виртуальность немедленно". PressPass (Press release). Microsoft. 2008-10-01. Дата обращения: 2 октября 2008. {{cite press release}}: |archive-url= требует |archive-date= (справка)
  5. Supported Guest OS on Windows Server 2008 Hyper-V. Дата обращения: 13 декабря 2010. Архивировано из оригинала 25 августа 2009 года.
  6. Установка Fedora Core 8 на Hyper-V. Дата обращения: 12 февраля 2009. Архивировано 10 февраля 2010 года.
  7. Предварительный обзор: Fedora 9 Alpha, запущенная на Hyper-V Beta: CRN Архивировано 23 июля 2010 года.
  8. Установка Ubuntu 7.10 на Hyper-V. Дата обращения: 12 февраля 2009. Архивировано из оригинала 24 февраля 2009 года.
  9. Обзор продукта Hyper-V. Дата обращения: 12 февраля 2009. Архивировано 4 июля 2008 года.
  10. Microsoft Hyper-V: из-за чего столько шума? Дата обращения: 12 февраля 2009. Архивировано из оригинала 15 мая 2009 года.
  11. Hyper-V drivers in mainline kernel - what's next. Дата обращения: 14 июня 2012. Архивировано из оригинала 10 декабря 2012 года.
  12. What are Flex Guest Entitlements in Red Hat Network?
  13. Virtual Hard Disk Image Format Specification. Дата обращения: 29 октября 2017. Архивировано 22 января 2011 года.
  14. Получаем доступ к USB-устройствам в виртуальных машинах Microsoft. Дата обращения: 12 февраля 2009. Архивировано 20 ноября 2008 года.
  15. Hyper-V: Живая миграция против быстрой. Дата обращения: 12 февраля 2009. Архивировано 19 ноября 2008 года.

Литература[править | править код]

  • Morimoto, Rand; Jeff Guillet. Windows Server 2008 Hyper-V Unleashed (неопр.).

Дополнительные источники[править | править код]