Общие сведения об архитектуре Hyper-V
На рисунке 2-5 подробно описана архитектура Hyper-V.
Рисунок 2-5. Обзор архитектуры Hyper-V. Как видно из рисунка 2-5, Hyper-V состоит из низкоуровневой оболочки корпорации Майкрософт, которая выполняется на физическом оборудовании. Это свидетельствует о том, что Hyper-V является платформой низкоуровневой оболочки типа 1. Над низкоуровневой оболочкой выполняется один родительский раздел и один или несколько дочерних разделов. В отношении виртуализации раздел представляет собой единицу пространства в пределах оболочки, которой выделено адресное пространство физической памяти и виртуальные процессоры. Существует два типа разделов: Родительский раздел представляет собой управляющий раздел, в котором выполняется стек виртуализации. Родительский раздел также владеет аппаратными устройствами и управляет ресурсами для дочерних разделов Дочерний раздел — это любой раздел, созданный родительским разделом. Гостевые операционные системы и их приложения выполняются в дочерних разделах. В реализации модели низкоуровневой оболочки типа 1, созданной корпорацией Майкрософт, — то есть, в Hyper-V — в качестве ОС родительского раздела используется установка Full или Server Core Windows Server 2008 версии Standard, Enterprise, Datacenter или более поздние версии. Дополнительные сведения о типах компьютеров, необходимых для Hyper-V, см. ниже в разделе «Системные требования для использования Hyper-V R2». Взаимодействие разделов с уровнем низкоуровневой оболочки выполняется с помощью гипервызовов — программных интерфейсов API, которые могут использоваться ОС с разделами для применения оптимизаций оболочки. Чтобы получить дополнительные сведения о разработке приложений, применяющих гипервызовы, обратитесь к библиотеке MSDN по адресу Общие сведения о родительском разделе При виртуализации сервера Hyper-V родительский раздел содержит несколько специальных компонентов, которые отсутствуют в дочерних разделах. На рисунке 2-6 подробно показаны различные компоненты родительского раздела, в том числе процессы режима пользователя (кольцо 3) и режима ядра (кольцо 0). Родительский раздел создается сразу при запуске низкоуровневой оболочки. Родительский раздел создается для экземпляра ОС Windows Server 2008 R2, в котором размещена серверная роль Hyper-V. Родительский раздел Hyper-V выполняет следующие задачи:
Аппаратные ресурсы родительского раздела используются совместно или выделяются дочерним разделам. Родительский раздел занимается управлением электропитанием, операциями Plug and Play, а также журналированием всех возникших аппаратных ошибок.
Рисунок 2-6. Подробное представление компонентов родительского раздела в Hyper-V. Стек виртуализации Компоненты виртуализации, размещенные в родительском разделе, называются стеком виртуализации. Стек виртуализации выполняется в родительском разделе и имеет прямой доступ к оборудованию базового главного компьютера за счет технологий, описанных ниже. В реализации модели низкоуровневой оболочки типа 1 для Hyper-V стек состоит из следующих компонентов:
В родительский раздел также входят другие компоненты:
Все эти компоненты подробно рассматриваются в следующих разделах. Служба управления виртуальными машинами Служба управления виртуальными машинами (служба VMM или VMMS) отвечает за управление состоянием всех виртуальных машин в дочерних разделах, в том числе за управление остановленными или автономными виртуальными машинами, создание мгновенных снимков, а также за добавление и удаление устройств. При запуске виртуальной машины в дочернем разделе служба VMMS открывает новый рабочий процесс виртуальной машины, который используется для выполнения задач по управлению этой машиной. Служба VMMS также управляет операциями, которые могут выполняться на виртуальной машине в определенном состоянии. Например, при удалении моментального снимка виртуальной машины служба VMMS запрещает его применение. Дополнительные сведения о моментальных снимках см. ниже в разделе «Работа с моментальными снимками». Служба VMMS управляет следующими состояниями виртуальной машины:
Служба VMMS не управляет интерактивными операциями виртуальной машины (приостановкой, сохранением и отключением питания). Управление ими осуществляется через рабочий процесс виртуальной машины, который запускается службой VMMS для соответствующей виртуальной машины. Служба VMMS реализована в режиме пользователя и режиме ядра в виде системной службы VMMS.exe. Она зависит от служб удаленного вызова процедур (RPC) и Windows Management Instrumentation (WMI). Служба VMMS содержит несколько компонентов, одним из которых является поставщик WMI, предоставляющий набор интерфейсов API на базе WMI для управления и контроля за виртуальными машинами. Эти интерфейсы Hyper-V WMI API могут использоваться вместе с VBScript или Windows PowerShell для управления многими аспектами среды Hyper-V из командной строки или с помощью скриптов. Интерфейсы Hyper-V WMI API также обеспечивают управление серверами Hyper-V через продукты Microsoft System Center. Работа с Hyper-V в System Center будет подробно рассмотрена в главе 5 «Управление виртуализацией». Рабочие процессы виртуальной машины Рабочий процесс виртуальной машины (vmwp.exe) представляет собой процесс режима пользователя, который предоставляет гостевым операционным системам дочерних разделов службы управления виртуальной машиной из экземпляра Windows Server 2008 R2 в родительском разделе. Служба VMMS запускает отдельный рабочий процесс для каждой запущенной виртуальной машины, что позволяет изолировать машины друг от друга. Таким образом, при сбое одного из рабочих процессов будет затронута только виртуальная машина, связанная с этим процессом. Для обеспечения дополнительной безопасности рабочие процессы виртуальной машины выполняются со встроенным удостоверением сетевой службы. Рабочий процесс управляет следующими аспектами связанной с ним виртуальной машины:
Кроме того, рабочие процессы виртуальной машины содержат виртуальную материнскую плату (VMB). Виртуальная материнская плата представляет виртуальной машине гостевую память, средства создания IRQ, а также ввод-вывод с привязкой к памяти и портам в виде отдельных устройств. Виртуальная материнская плата также управляет виртуальными устройствами (см. ниже). Совет Чтобы просмотреть идентификатор GUID виртуальной машины, связанной с определенным рабочим процессом, откройте диспетчер задач, перейдите на вкладку «Процессы» и добавьте столбец «Командная строка» в представление «Процессы». Это позволяет отобразить все запущенные экземпляры vmwp.exe на компьютере и их идентификаторы GUID. Виртуальные устройства Виртуальные устройства представляют собой программные модули, предоставляющие дочерним разделам возможности конфигурации устройств и управления ими. Шина VMB содержит стандартный набор виртуальных устройств, в т. ч. шину PCI и устройства уровня микросхемы с материнской платы Intel 440BX. Виртуальные устройства делятся на два типа:
Драйвер инфраструктуры виртуализации Драйвер инфраструктуры виртуализации (Vid.sys) является компонентом стека виртуализации в режиме ядра и предоставляет всем дочерним разделам службы управления разделами, виртуальным процессором и памятью. Драйвер Vid.sys также позволяет компонентам стека взаимодействовать с низкоуровневой оболочкой в режиме пользователя. Библиотека интерфейса низкоуровневой оболочки Windows Библиотека интерфейса низкоуровневой оболочки Windows (WinHv.sys) является DLL-библиотекой в режиме ядра. Она загружается в экземпляре Windows Server 2008 R2 в родительском разделе, а также в гостевой операционной системе на всех дочерних разделах с поддержкой Hyper-V. WinHv.sys выделяет подробные сведения реализации гипервызова и позволяет драйверам операционной системы вызывать низкоуровневую оболочку с помощью стандартных соглашений об именовании Windows. Поставщики услуг виртуализации Поставщики услуг виртуализации (VSP) размещаются в родительском разделе и представляют собой способ публикации служб устройств на дочерних разделах. Они предоставляют ресурсы ввода-вывода всем клиентам служб виртуализации (VSC), запущенным на дочерних разделах. Поставщики услуг виртуализации являются серверной конечной точкой, а клиенты являются клиентской конечной точкой взаимодействия «клиент-сервер» для обеспечения функциональности устройств.Обмен информацией между поставщиками и клиентам выполняется через шину VMBus. Шина виртуальной машины Шина виртуальной машины (VMBus) является логическим и канальным механизмом взаимодействия родительского раздела с дочерними разделами. Назначение VMBus заключается в предоставлении высокоскоростного и оптимизированного взаимодействия виртуализованных разделов, которое в отличие от других способов не требует эмуляции, повышающей нагрузку. Гостевые операционные системы, не поддерживающие службы интеграции, не поддерживают низкоуровневую оболочку и могут использовать только эмуляцию. Таким образом, низкоуровневая оболочка должна перехватывать вызовы физического оборудования и маршрутизировать их в эмулированное устройство, запущенное в рабочем процессе виртуальной машины родительского раздела. Эмуляция требует существенно больше ресурсов по сравнению с взаимодействием через VMBus, поэтому после установки гостевой операционной системы пользователям настоятельно рекомендуется установить службы интеграции Hyper-V. Это связано с тем, что на родительском разделе размещены поставщики услуг виртуализации, которые взаимодействуют друг с другом через шину VMBus и обрабатывают запросы на доступ к устройствам из дочерних разделов. Дочерние разделы содержат клиенты служб виртуализации, которые перенаправляют запросы на доступ к устройствам поставщикам в родительском разделе с помощью VMBus. Процесс взаимодействия родительского и дочернего раздела через VMBus доступен гостевой операционной системе. Общие сведения о дочерних разделах Как показано на рис. 2-7, в реализации модели низкоуровневой оболочки типа 1 для Hyper-V поддерживается три типа дочерних разделов:
Рисунок 2-7. Различные типы дочерних разделов, поддерживаемые Hyper-V. Дочерние разделы, на которых размещена ОС Windows с поддержкой Hyper-V Как показано в левой части рисунка 2-7, дочерние разделы под управлением ОС Windows с поддержкой Hyper-V содержат следующие компоненты виртуализации в режиме ядра:
Примечание Компоненты VMBus и WinHv.sys были описаны выше в разделе «Общие сведения о родительском разделе». Дочерние разделы, на которых размещена ОС Windows с поддержкой Hyper-V Как показано на средней части рисунка 2-7, дочерние разделы под управлением сторонних ОС с поддержкой Hyper-V для доступа к оборудованию и взаимодействия через VMBus с поставщиками в родительском разделе используют клиенты служб виртуализации сторонних производителей. Такие клиенты предоставляются дочерним разделам путем установки служб виртуализации. Службы интеграции в первую очередь используются для устранения ошибок работы, возникающих в связи с изолированностью среды виртуальных машин. Службы интеграции также предоставляют компоненты, которые позволяют дочерним разделам взаимодействовать с другими разделами и с низкоуровневой оболочкой. В более ранних платформах виртуализации корпорации Майкрософт (например, в Microsoft Virtual Server и Microsoft Virtual PC) службы интеграции назывались дополнениями к виртуальной машине. Службы интеграции также предоставляют дочернему разделу следующие функции:
Hyper-V содержит службы интеграции для версий x86 и x64 следующих гостевых ОС Windows:
Корпорация Майкрософт также разработала компоненты интеграции Linux для Hyper-V. Чтобы загрузить их, выполните поиск по запросу Linux Integration Components for Windows Server 2008 Hyper-V R2 в центре загрузок Майкрософт по адресу https://www.microsoft.com/downloads. Эти компоненты выпускаются корпорацией Майкрософт на условиях лицензии GPL v2, а код интегрируется в дерево ядра Linux средствами проекта Linux Driver Project (см. сайт http://www.linuxdriverproject.org). Дочерние разделы, на которых размещена ОС без поддержки Hyper-V Как показано в левой части рисунка 2-7, в дочерних разделах под управлением ОС без поддержки Hyper-V (как ОС Windows, так и сторонних систем) установка служб интеграции невозможна. Таким образом, гостевые ОС используют эмулированные устройства вместо синтетических, что существенно снижает их производительность из-за необходимости эмуляции. |
.png)
.png)
.png)