Национальная библиотека им. Н. Э. Баумана Bauman National Library. К какой категории гипервизоров принадлежит microsoft virtual pc

О гипервизорах, виртуализации систем и о том, как это работает в облачной среде

Гипервизоры, виртуализация и облако

Бхану П. ТолетиОпубликовано 23.07.2012

Серия контента:

Этот контент является частью # из серии # статей: Гипервизоры, виртуализация и облако

https://www.ibm.com/developerworks/ru/library/?series_title_by=**auto**

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Гипервизоры, виртуализация и облако

Следите за выходом новых статей этой серии.

Виртуализация оптимизирует использование ИТ-ресурсов, рассматривая физические ресурсы компании в качестве резервуаров, из которых можно динамически черпать виртуальные ресурсы.

Об этом цикле статей

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

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

Виртуализация означает сдвиг в мышлении от физического подхода к логическому, рассматривая ИТ-ресурсы в качестве логических, а не отдельных физических ресурсов. Используя виртуализацию, можно консолидировать ресурсы, такие как процессоры, дисковое пространство и сети, в своей среде, что дает следующие преимущества:

консолидация с целью уменьшения стоимости оборудования;
оптимизация рабочей нагрузки;
гибкость и оперативность ИТ-услуг.

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

Виртуализация обычно применяется к физическим аппаратным ресурсам путем объединения нескольких физических ресурсов в общие пулы, из которых пользователи получают виртуальные ресурсы. С помощью виртуализации из одного физического ресурса можно сделать несколько виртуальных.

Более того, виртуальные ресурсы могут иметь функции или особенности, отсутствующие у исходных физических ресурсов.

При виртуализации в рамках одной физической системы создается несколько виртуальных систем. Виртуальные системы ― это независимо функционирующие среды, которые используют виртуальные ресурсы. Виртуальные системы, работающие на системах IBM®, часто называют логическими разделами или виртуальными машинами. Виртуализация системы чаще всего осуществляется с помощью технологии гипервизора.

Гипервизор ― это программное или микропрограммное обеспечение, позволяющее виртуализировать системные ресурсы.

Рисунок 1. Виртуализация, переход от физического подхода к логическому

Теперь рассмотрим типы гипервизоров.

Общие сведения о гипервизорах

Существует два типа гипервизоров:

гипервизоры типа 1 и
гипервизоры типа 2.

Гипервизоры типа 1 работают непосредственно на оборудовании системы. Гипервизоры типа 2 работают поверх базовой операционной системы, которая обеспечивает службы виртуализации, такие как поддержка устройства ввода/вывода и управление памятью. На рисунке 2 показано, чем различаются гипервизоры типа 1 и типа 2.

Рисунок 2. Различия между гипервизорами типа 1 и типа 2

Гипервизоры, описанные в этом цикле статей, поддерживают различные аппаратные платформы в различных облачных средах.

PowerVM: принадлежность серверов на базе IBM POWER5, POWER6 и POWER7, этот гипервизор поддерживается операционными системами IBM i, AIX® и Linux®; PowerVM поддерживается в среде IBM SmartCloud Enterprise.
VMware ESX Server: встроенный гипервизор VMware ESX работает непосредственно на аппаратуре серверов, не требуя дополнительной операционной системы. Он поддерживается в среде IBM SmartCloud Enterprise.
Xen: монитор виртуальных машин для процессорных архитектур IA-32, x86-64, Itanium и ARM, Xen позволяет выполнять несколько гостевых операционных систем на одном и том же оборудовании одновременно. Xen-системы имеют структуру, в которой гипервизор Xen занимает самый низкий и привилегированный уровень.

KVM: инфраструктура виртуализации для ядра Linux, KVM поддерживает платформенно-зависимую виртуализацию на процессорах с аппаратными расширениями для виртуализации. Первоначально он поддерживал процессоры x86, но в настоящее время к ним добавился широкий спектр процессоров и гостевых операционных систем, в том числе множество вариаций Linux, BSD, Solaris, Windows®, Haiku, ReactOS и AROS Research Operating System (есть даже модифицированная версия QEMU, способная использовать KVM для работы с Mac OS X).
z/VM: текущая версия операционной системы виртуальных машин IBM, z/VM работает на серверах IBM zSeries и может использоваться для поддержки большого числа (тысяч) виртуальных машин Linux.

Все эти гипервизоры поддерживаются оборудованием IBM.

В отдельных статях подробно описаны возможности соответствующих гипервизоров, их функциональность, а также методы развертывания и управления виртуальными системами с помощью этих гипервизоров.

Правильный выбор гипервизора

Один из лучших способов определить, какой гипервизор отвечает вашим потребностям, ― сравнение их показателей производительности. В число этих показателей входят нагрузка на процессор, размер максимальной хозяйской и гостевой памяти и поддержка виртуальных процессоров.

Но выбор нельзя основывать на одних лишь показателях производительности. Кроме возможностей гипервизора, необходимо проверить, какие гостевые операционные системы он поддерживает.

Если в сервисной сети используются разнородные системы, нужно выбирать гипервизор, поддерживающий те операционные системы, с которыми вы работаете в настоящее время. Если же сеть однородна и основана на ОС Windows или Linux, то будет достаточно поддержки меньшего числа гостевых операционных систем.

Гипервизоры разные, но все они имеют схожие черты. Знание их особенностей и поддерживаемых гостевых операционных систем ― важный аспект любого процесса выбора гипервизора для виртуализации оборудования. Решение будет основываться на соответствии этих данных требованиям вашей организации. (Начните этот процесс с детального изучения каждого гипервизора.)

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

Производительность виртуальной машины

Виртуальные системы должны соответствовать или превосходить по производительности свои физические аналоги, по крайней мере, в отношении приложений, работающих на каждом сервере. Все, что сверх этой производительности, пойдет на пользу.

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

Управление памятью

Ищите виртуализацию памяти с аппаратной поддержкой. Предпочтительными являются возможность выделения избыточного количества памяти и поддержка больших таблиц страниц в гостевой ВМ и в гипервизоре; дополнительно следует рассмотреть возможность обобщения страниц памяти (memory page sharing).

Высокая готовность

Каждый крупный производитель использует свое собственное решение для достижения высокой готовности, и эти решения могут быть очень разными, от очень сложного подхода до минималистского. Решающее значение имеет понимание как профилактических мер, так и способов аварийного восстановления каждой системы. Никогда не следует запускать никакие виртуальные машины без полного знания механизмов защиты и восстановления.

Динамическая миграция

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

Сети, системы хранения данных и безопасность

В сфере сетей гипервизоры должны поддерживать выравнивание нагрузки и групповую работу (teaming) сетевых карт (NIC), Unicast-изоляцию, а также поддержку объединения каналов (trunking) стандартных (802.1Q) виртуальных локальных сетей (VLAN).

Каждый гипервизор должен поддерживать также системы хранения данных на основе сетей iSCSI (и Fibre Channel) и корпоративное ПО защиты данных, причем некоторое предпочтение отдается инструментами и API, Fibre Channel over Ethernet (FCoE) и совместимости с мультигипервизором виртуальных дисков.

Функции управления

Обратите внимание на такие функции управления, как ловушки Simple Network Management Protocol (SNMP), интеграцию с другим программным обеспечением управления и отказоустойчивость сервера управления - эти функции имеют неоценимое значение для гипервизора.

Несколько советов...

Я не хочу сейчас влиять на ваш выбор гипервизора (в конце концов, требования каждого заказчика уникальны), но дам несколько общих советов, основанных на моем опыте внедрения гипервизоров для работы с облачными нагрузками.

Гипервизор PowerVM способен справляться с UNIX®-нагрузками, содержащими критические бизнес-приложения, которые выполняют тяжелые транзакции, когда важнейшим требованием является производительность.
VMware ESX достаточно хорошо работает с критически важными бизнес-приложениями на System X (серверы x86 для Windows и Linux).
Если приложение не особенно критично для бизнеса, можно попробовать KVM или Xen (первоначальные расходы на них тоже относительно невелики).

Можно даже попробовать некоторые бесплатные виртуальные машины, такие как Xen и KVM.

Заключение

ИТ-менеджеры все чаще смотрят в сторону технологии виртуализации, чтобы снизить затраты на ИТ за счет повышения эффективности, гибкости и оперативности. Виртуализация становится все более распространенным подходом, и важно, чтобы инфраструктура виртуализации могла наиболее эффективным образом решать проблемы и задачи, с которыми сталкивается центр обработки данных предприятия.

Любая инфраструктура виртуализации, которую предполагается широко развернуть в центрах обработки данных, должна обеспечивать лучшее в своем классе сочетание нескольких важных характеристик:

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

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

Ресурсы для скачивания

Гипервизоры. Что же это и как работает виртуальный сервер? / Блог компании VPS.house / Хабр

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

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

О преимуществах виртуального сервера и облачных вычислений уже сказано много слов и написано огромное количество статей, настолько много, что кажется будто эта технология уже устарела в быстро развивающемся мире ИТ инфраструктуры. Однако, все же стоит выбросить такие мысли из головы, ведь технология гипервизоров как раз может помочь в стимулировании инноваций в мире облачных вычислений.

Что такое гипервизор?

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

Гипервизор является движущей силой концепции работы VPS и виртуализации, позволяя физическому хост-компьютеру управлять несколькими виртуальными машинами в качестве гостевых ОС, что в свою очередь помогает максимально эффективно использовать вычислительные ресурсы, такие как память, пропускная способность сети и количество циклов процессора.

История гипервизоров

В конце 1960-х и вплоть 1970-х годов, большинство систем виртуализации и гипервизоров были замечены на мейнфреймах, разработанных компанией IBM. Использовались они для разработки процессов использования компьютера в режиме разделения времени, для тестирования новых операционных систем и идей для их усовершенствования или даже для изучения новых аппаратных концепций. Виртуализация позволила программистам развертывать системы и устранять неисправности, не подвергая угрозам стабильность основной производственной системы, ну и к тому же она позволила уйти от развертывания дополнительных дорогостоящих систем.

В середине 2000-х годов гипервизоры выходят на новый уровень, когда Unix, Linux и другие похожие на Unix операционные системы начали использовать технологии виртуализации. В чем же причины роста интереса к гипервизорам и виртуализации? Ну, во-первых, причина заключалась в улучшении аппаратных возможностей и мощностей, которые теперь позволили бы одной машине выполнять более синхронизированную работу; во-вторых, усиление контроля издержек, что привело к консолидации серверов; в-третьих, значимую роль сыграла безопасность и надежность благодаря усовершенствованию архитектуры гипервизоров; и конечно последняя, но не менее важная причина — возможность запуска зависимых от ОС приложений в различных аппаратных или операционных средах. Кроме того, в 2005 году разработчики процессоров начали добавлять аппаратную виртуализацию в свои продукты на базе x86, расширяя доступность (и преимущества) виртуализации для ПК и серверной аудитории.

Преимущества гипервизоров

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

Виртуальные машины также очень мобильны — поскольку они не зависят от основного оборудования, их можно перемещать или переносить между локальными или удаленными виртуальными серверами. И сделать это намного проще, в сравнении с традиционными приложениями, привязанными к физическому оборудованию.

Существует два типа гипервизоров с очень «креативными» названиями «ТИП 1» или «ТИП 2». Гипервизоры типа 1, иногда называемые «автономными гипервизорами», запускаются непосредственно на аппаратном обеспечении хоста для управления оборудованием и управления гостевыми виртуальными машинами. К современным гипервизорам первого типа относятся: Xen, Oracle VM Server для SPARC, Oracle VM Server для x86, Microsoft Hyper-V и VMware ESX / ESXi. Под управлением Hyper-V, кстати, работают все серверы VDS Windows на хостинге VSP.house.

Гипервизоры типа 2, иногда называемые «хостовыми гипервизорами», запускаются на обычной ОС, как и другие приложения в системе. В этом случае гостевая ОС выполняется как процесс на хосте, а гипервизоры разделяют гостевую ОС и ОС хоста. Примеры гипервизоров второго типа: VMware Workstation, VMware Player, VirtualBox и Parallels Desktop для Mac. На данный момент можно выделить трех основных крупнейших разработчиков гипервизоров: VMware, Microsoft и Citrix Systems.

Контейнеры против гипервизоров

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

Один из публицистов в статье 2016 для Network World высказал интересное мнение. Он заявил, что виртуальные машины используют много системных ресурсов, ведь каждая виртуальная машина запускает не только полную копию операционной системы, но и виртуальную копию всего оборудования, на котором должна запускаться операционная система. Соответственно, быстро возникает необходимость в использовании большого количества запоминающих устройств и машинных циклов. А все, что требуется контейнеру, — это операционная система, поддерживающая программы и каталоги, а также системные ресурсы для запуска конкретной программы.

Однако, не стоит думать, что контейнеры обязательно заменят гипервизоры и виртуальные машины, ведь существуют проблемы безопасности и практического использования виртуальных машин. Скорее всего компании будут использовать оба метода в совокупности. И кстати о безопасности, некоторые считают, что контейнеры менее безопасны, чем гипервизоры. Причина в том, что в контейнерах имеется только одна ОС, которую используют приложения, в то время как виртуальные машины изолируют не только приложения, но и ОС. Если одно из приложений попадает под угрозу, оно может атаковать и ОС в контейнере, что влияет в свою очередь и на другие приложения. В тоже самое время если на виртуальной машине приложение становится уязвимым, то оно сможет оказать вредоносное действие исключительно на одну ОС на сервере, а другие приложения или ОС на виртуальной машине остаются в безопасности.

Проблемы безопасности гипервизоров

Хотя благодаря многим мерам предосторожности гипервизоры считаются более безопасными, чем контейнеры, это не означает того факта, что у гипервизоров нет вообще проблем, связанных с безопасностью. Например, в теории хакеры могут создавать вредоносные программы и руткиты, которые устанавливаются под ОС как гипервизор. Этот процесс, известный как «гиперджекинг», сложно обнаружить, так как вредоносное ПО может перехватывать действия операционной системы (например, ввод пароля) без необходимости защиты от вредоносного ПО, поскольку данное вредоносное ПО уже работает под ОС.

Профессионалы в мире виртуализации могут бесконечно вести дискуссии и споры о том, можно ли обнаружить присутствие руткита на базе гипервизора. Уже даже созданы несколько подходов на эту тему, одними внедрена концепция вредоносного ПО (SubVirt и Blue Pill), другие продемонстрировали антируткит Hooksafe, который обеспечивает эффективную защиту ОС от руткитов режима ядра без заметных потерь в производительности.

Расширение возможностей гипервизора

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

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

Также встречается еще и встроенные гипервизоры. Что же это такое? Встроенные гипервизоры поддерживают требования встроенных систем. Они немного отличаются от гипервизоров, ориентированных на серверные и настольные приложения. Встроенный гипервизор с самого начала внедряется во встроенное устройство, а не загружается при последующем развертывании устройства. Во встроенной системе различные компоненты обычно функционируют совместно для обеспечения функциональности устройства.

habr.com

Сравнение гипервизоров: Hyper-V или Vmware

Технологии виртуализации уже насчитывается более 30 лет. Сегодня виртуализация стала ключевой технологией IT и стала основой сервисов нового поколения. Существует множество продуктов виртуализации и такое многообразие заставляет задуматься: какой гипервизор выбрать? Спешим вас огорчить, как нет универсального рецепта в кулинарии, так и нет универсального продукта виртуализации, который бы подошел всем. У каждого продукта есть свои преимущества и недостатки. Выбирать продукт виртуализации нужно, прежде всего, исходя из потребностей бизнеса. В одном случае будет хорош один продукт, в другом — совершенно другой. Многие компании, подбирающие решения для виртуализации, выбирают между продуктами KVM, VMware или Hyper-V. Надеемся, наши обзоры и сравнения гипервизоров помогут вам выбрать оптимальное для вашего предприятия решение.

Типы гипервизоров

Существует два типа гипервизоров. Гипервизоры первого типа запускаются непосредственно на «железе» и не требуют установки какой-либо операционной системы. Для работы монитора виртуальных машин второго типа нужна операционная система — через нее производится доступ к аппаратной части. Лучшим гипервизором считается тот, что относится к первому типу, т. к. его производительность выше, поскольку они работают напрямую с оборудованием.

Рис. 1. Принцип работы гипервизора 1-го типа

Рис. 2. Принцип работы гипервизора 2-го типа

Примеры гипервизоров 1-го типа: Hyper-V, KVM, ESXi. Гипервизоры 2-го типа: VMware Workstation, Oracle Virtual Box, OpenVZ. Нас интересуют только системы виртуализации первого типа, так как вторые больше подходят для индивидуального использования, чем в качестве решений уровня предприятия.

Отметим, что Hyper-V и WMware — это проприетарные решения, поэтому мы подготовили обзор и сравнение гипервизоров этих моделей. Мы также поговорим и о решении с открытым исходным кодом — KVM. Многие предприятия выбирают именно его, не смотря, что некоторые независимые эксперты считают это решение довольно сырым и непригодным на корпоративной кухне. Однако, согласно отчету IT Central Station за январь 2018 года, 25% операторов связи и 11% финансовых организаций считают именно KVM лучшим гипервизором. Так что при рассуждениях о том, какой гипервизор выбрать, это решение исключать нельзя.

Рис. 3. Немного статистики от IT Central Station

Сначала мы рассмотрим проприетарные решения, а затем попытаемся выяснить, стоит ли использовать KVM.

Битва гигантов: Hyper-V или VMware?

Рассматривая гипервизоры, обзор и сравнение мы начнем с Hyper-V. Здесь нужно понимать, что есть Windows Server 2016 со стандартной ролью Hyper-V и есть Hyper-V Server 2016. Windows Server 2016 поставляется в двух редакциях — Datacenter и Standard. У каждой из них есть роль. С точки зрения виртуализации обе редакции аналогичны, но есть нюансы, связанные с лицензированием, делающие одну версию гипервизора лучше другой. В редакции Standard по одной серверной лицензии можно поднять только две виртуальных машины. В редакции Datacenter можно поднять любое количество виртуальных машин. В стандартной редакции тоже можно запустить любое количество виртуальных машин, но это будет не очень верно с точки зрения лицензирования. С другой стороны, лицензируется не факт создания виртуальной машины, а только ОС внутри виртуальной машины. Если нужны виртуальные Linux-серверы, то можно запустить любое их количество в стандартной версии Windows Server. В 2016-ом году в лицензионной политике Microsoft произошли изменения. Теперь стоимость лицензии на сервер зависит от количества ядер на физическом сервере.

Hyper-V Server 2016 — специально для тех, кто не хочет платить за систему аппаратной виртуализации. Никаких ограничений на процедуры и при этом он абсолютно бесплатный. Что-то невероятное, особенно, когда речь идет о Microsoft. Но есть и подводные камни:

Нужно лицензировать все виртуальные машины, работающие под управлением Windows.
Отсутствует графический интерфейс, правда, есть удаленная консоль.
Отсутствие поддержки производителя (но есть обновления).

Хорошего администратора не испугает ни отсутствие поддержки, ни графического интерфейса. А вот необходимость в лицензировании каждой Windows-машины — это плохо. Иногда целесообразнее купить Datacenter — так будет выгоднее. С другой стороны, если планируете разворачивать только Linux-серверы, то данное решение можно действительно назвать бесплатным.

Теперь мы рассмотрим VMware ESXi гипервизоры, обзор и сравнение которых тоже будут интересными. В отличие от VMware Workstation, ESXi — это не приложение, это, можно сказать, операционная система, которая устанавливается на голое оборудование. ESXi похож на Linux — те же команды, те же названия стандартных каталогов, однако, он работает полностью на собственном проприетарном ядре VMkernel. Если вам интересно, информацию и более развернутые обзоры этого программного продукта вы можете найти в Сети.

Отдельно купить ESXi нельзя. Если вы хотите купить ESXi, вам нужно купить VMware vSphere 6. При этом лицензия покупается на каждый физический процессор на физическом сервере. Оперативная память и число виртуальных машин не влияет на стоимость.

А есть что-то бесплатное? Да, VMware предлагает VMware ESXi Free или VMware Free vSphere Hypervisor. Бесплатный VMware ESXi требует регистрации и может работать в режиме полной пробной версии 60 дней, после этого нужно или мириться с ограничениями бесплатной версии или же покупать полноценную.

Если облака для вас не просто теория

Широкий спектр услуг по выделенным северам и мультиклауд-решениям

Конфигурация VPS и бесплатный тест уже через 2 минуты

Организация вашей IT-инфраструктуры на основе мультиклауд-решения

На данный момент у бесплатного VMware Free vSphere Hypervisor нет ограничений для хоста по процессорам и памяти. Зато есть ряд других ограничений:

API продукта доступны только на чтение.
Виртуальная машина может иметь не более 8 vCPU.
Нельзя использовать вместе с Veeam для создания резервных копий.
Не поддерживается подключение к vCenter Server
Не поддерживаются технологии VM host live migration, VM storage live migration, не поддерживается высокая доступность.

Обмануть судьбу не получится. Коммерческого решения на базе бесплатного ESXi создать не выйдет.

Теперь немного цифр. Таблица 1 содержит сравнение гипервизоров MS Hyper-V 2016 и VMware vSphere 6.5.

Таблица 1. Сравнительный обзор характеристик проприетарных гипервизоров

Система Ресурс MS Hyper-V Free Hypervisor Essential Plus Enterprise Plus

Хост	Логические процессоры	512	576	576	576
	Физическая память, ТБ	24	4	4	12
	vCPU на 1 хост	2048	4096	4096	4096
	ВМ на 1 хост	1024	1024	1024	1024
	Вложенный гипервизор	+	+	+	+
Виртуальная машина (ВМ)	Виртуальные CPU на 1 ВМ	240 для поколения 2 или 64 для поколения 1	8	128	128
	Макс. ОЗУ для ВМ	12 Тб для пок. 2 или 1 Тб для пок. 1	6128 Гб	6128 Гб	6128 Гб
	Макс. дисковое пространство	64 Тб для формата VDHX, 2040 Гб для VHD	62 Тб	62 Тб	62 Тб
	К-во дисков	256	60	60	60
Кластер	Макс. Узлов	64	-	64	64
Кластер	Макс. ВМ	8000	-	8000	8000

Как видите, по масштабируемости представленные системы виртуализации очень похожи. Free-версия, конечно, немного урезана — она не поддерживает кластеры и виртуальная машина может содержать только 8 виртуальных процессоров. Но не это самое главное. Помимо «технических характеристик» нужно рассмотреть еще и функционал гипервизоров.

Основной недостаток Hyper-V не увидеть в таблице 1. К сожалению, данный гипервизор до сих пор не поддерживает технологию USB Redirection, которая используется для проброса аппаратных USB-портов, что позволяет подключать аппаратные USB-ключи к виртуальным машинам. Вместо нее пытаются «сосватать» технологию Discrete Device Assigment, но это несколько не то. К тому же Hyper-V пока не умеет «на лету» добавлять CPU, что делает его не лучшим выбором для некоторых компаний. Зато Hyper-V позволяет уменьшать размер диска, а не только увеличивать, как VMware. Сравнительный обзор функционала приведен в таблице 2.

Таблица 2. Сравнение гипервизоров по функционалу

Функция MS Hyper-V Free Hypervisor Essential Plus Enterprise Plus

VM host live migration	+	-	+	+
VM storage live migration	+	-	-	+
QoS для хранилища/сети	+	-	-	+
Проброс оборудования	Discrete Device Assigntment	PCI VMDirectPath/ USB redirection	PCI VMDirectPath/ USB redirection	PCI VMDirectPath/ USB redirection
Горячее добавление	Диски/vNIC/ОЗУ	Диски/vNIC/USB	Диски/vNIC/USB	Диски/vNIC/USB/ CPU/ОЗУ
Горячее удаление	Диски/vNIC/ОЗУ	Диски/vNIC/USB	Диски/vNIC/USB	Диски/vNIC/USB/ CPU
Изменение размера диска	Уменьшение и увеличение	Увеличение	Увеличение	Увеличение
Шифрование ВМ	+	-	-	+

Функционал говорит за себя. Если нужен проброс USB-портов в виртуальную машину, то лучшим гипервизором будет VMware, даже бесплатный. С другой стороны, если необходимо шифрование виртуальной машины, то, возможно, дешевле будет использовать Hyper-V.

Кроме функционала самого гипервизора, нужно оценить еще и средства управления. У каждого вендора есть свое решение для управления гипервизорами. Virtual Machine Manager (VMM) позволяет управлять серверами Hyper-V, а именно: создавать, клонировать, развертывать виртуальные машины и многое-многое другое.

У VMware средство управления называется vSphere. vSphere подразумевает использование ESXi хостов и vCenter Server для их централизованного управления.

Какое средство управления более удобное — судить сложно. Все индивидуально, кто к чему привык. Однако нужно понимать, что в случае с VMware требуется обязательное наличие VMware vCenter, если вам нужен, например, кластер. А вот Virtual Machine Manager (VMM) является опциональным компонентом, который очень полезен, но совсем не обязательный.

Какой из гипервизоров лучше, Hyper-V или Vmware, сказать нельзя. Все зависит от того, что нужно вам. В некоторых случаях, например, если нужен проброс USB, лучшим выбором будет VMware — даже бесплатное решение поддерживает эту технологию. Но не все готовы мириться с ограничением в 8 виртуальных процессоров. Для них лучший гипервизор — Hyper-V, который можно использовать бесплатно (а в случае с Linux даже не придется покупать лицензии).

В любом случае, даже если вы почти определились с выбором, нельзя забывать о полностью бесплатном KVM.

KVM — решение с открытым исходным кодом

KVM (Kernel-based Virtual Machine) — полное решение виртуализации для платформ Linux/x86, поддерживающее аппаратные расширения (Intel VT и AMD-V).

Изначально KVM поддерживал только процессоры x86, но современные версии KVM поддерживают самые различные процессоры и гостевые ОС, в том числе Linux, BSD, Solaris, Windows и др.

KVM — простой в использовании, легкий, нетребовательный к ресурсам и довольно функциональный гипервизор. KVM позволяет в минимальные сроки развернуть площадку виртуализации. Все Wiki-ресурсы (MediaWiki, Wikimedia Foundation, Wikipedia, Wikivoyage, Wikidata, Wikiversity) используют именно это решение виртуализации.

Поскольку гостевые операционные системы взаимодействуют с гипервизором, который интегрирован в ядро Linux, у них есть возможность обращаться напрямую к оборудованию без нужды изменения гостевой ОС. Благодаря этому KVM считается довольно быстрым решением.

Конечно, KVM — не идеален, и у него есть тоже свои недостатки, и их надо учесть, прежде чем выбрать именно его. Начнем с того, что нет мощных средств для управления виртуальными машинами и сервером KVM. Средства, конечно, есть, но они не соответствуют по функционалу аналогичным средствам для других систем. Одно из лучших решений — SolusVM — универсальная панель управления виртуальными серверами KVM, Xen и OpenVZ.

Также часто отмечают не лучшую стабильность KVM при выполнении разнообразных задач с интенсивным вводом-выводом. Именно поэтому некоторые эксперты в сфере виртуализации при обзорах и сравнении гипервизоров называют KVM сырым решением, которое больше подходит для экспериментов, чем для корпоративного применения.

Если спросить у профессионалов о том, какой выбрать гипервизор, то все они посоветуют Hyper-V. Он более стабилен, специальные средства миграции виртуальной машины в нем надежнее, эффективнее применяется оборудование, нежели в Linux-KVM. Платформа Microsoft Azure построена на Hyper-V и это говорит о многом.

Информация к размышлению

Вместо скучной таблички с итогами (при желании вы сами можете составить такую) приведем несколько дополнительных тезисов, которые помогут вам определиться с тем, какой гипервизор выбрать. Так сказать, пища для ума или информация к размышлению:

VMware — самое дорогое решение, Hyper-V — дешевле (или при использовании Hyper-V Server и виртуальных машин с Linux — вообще бесплатное), KVM — изначально бесплатное.
Подсчитывая стоимость системы виртуализации, нужно учитывать еще и стоимость лицензий программного обеспечения, которое будет установлено в виртуальных машинах. Именно поэтому Hyper-V значительно дешевле VMware — при использовании VMware вам все равно придется покупать лицензии на гостевые ОС.
Hyper-V значительно дешевле и производительнее в гиперконвергентных решениях.
Таблица 1 — сугубо информативная, большинство пользователей не столкнется с этими ограничениями и ее не нужно учитывать, выбирая лучший гипервизор. Самое жесткое ограничение — у свободной версии ESXi.
У VMware есть Fault Tolerance, у Microsoft — пока нет. Если это для вас важно, задумайтесь над VMware.
У VMware лучше VDI, но у Microsoft организация VDI будет дешевле.
Hyper-V менее требовательный к «железу».
Хранилище для Hyper-V дешевле, поскольку VMware тесно связан по рукам и ногам HCL, а Hyper-V может использовать любой SMB 3.0 ресурс для хранения.
Hyper-V Server — это программное решение Hyper-V, поставляемое с Core-версией Windows без графического интерфейса. Ограничений в нем никаких нет (в отличие от бесплатной версии VMware), вы можете включить его в домен, управлять ею с помощью System Center, бэкапить и т. д. (в отличие от бесплатной vSphere).
В Hyper-V нет средств вроде Distributed Resource Scheduler или же Storage DRS, которые в VMware используются для балансировки нагрузок между ресурсами хостов
SCVMM в Hyper-V открывает возможности, выходящие за рамки простой серверной виртуализации. Вы можете создавать частные облака.
KVM — самое неприхотливое к ресурсам программное обеспечение. Это нужно учитывать при разработке бюджетных решений виртуализацией.
Для KVM можно также использовать интерфейс управления Virsh и GUI-интерфейс virtmanager.
Службы поддержки у KVM нет. Если что-то не получается, вы можете рассчитывать только на сообщество. Впрочем, поддержки нет и у бесплатного Hyper-V Server.
Существует коммерческий вариант KVM — RHEV (Red Hat Enterprise Virtualization).

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

www.xelent.ru

Гипервизор — Национальная библиотека им. Н. Э. Баумана

Материал из Национальной библиотеки им. Н. Э. БауманаПоследнее изменение этой страницы: 10:06, 27 июня 2016.

Определение

Гипервизор (англ. Hypervisor) или Монитор виртуальных машин (в компьютерах) — программа или аппаратная схема, обеспечивающая или позволяющая одновременное, параллельное выполнение нескольких операционных систем на одном и том же хост-компьютере. Гипервизор также обеспечивает изоляцию операционных систем друг от друга, защиту и безопасность, разделение ресурсов между различными запущенными ОС и управление ресурсами. Гипервизор также может (но не обязан) предоставлять работающим под его управлением на одном хост-компьютере ОС средства связи и взаимодействия между собой (например, через обмен файлами или сетевые соединения) так, как если бы эти ОС выполнялись на разных физических компьютерах. Гипервизор сам по себе в некотором роде является минимальной операционной системой (микроядром или наноядром). Он предоставляет запущенным под его управлением операционным системам сервис виртуальной машины, виртуализируя или эмулируя реальное (физическое) аппаратное обеспечение конкретной машины. И управляет этими виртуальными машинами, выделением и освобождением ресурсов для них. Гипервизор позволяет независимое «включение», перезагрузку, «выключение» любой из виртуальных машин с той или иной ОС. При этом операционная система, работающая в виртуальной машине под управлением гипервизора, может, но не обязана «знать», что она выполняется в виртуальной машине, а не на реальном аппаратном обеспечении.

Термин

Термин гипервизор (hypervisor) зачастую используется в двух понятиях, которые следует различать. Первое, более широкое, включает все виды технологий поддержки исполнения виртуальных машин (ВМ). Более узкое один из вариантов таких решений, основанный на отсутствии хостовой ОС. Гипервизор создает абстракцию нижележащей аппаратной платформы, таким образом, чтобы она могла использоваться одной или несколькими виртуальными машинами (ВМ), при этом ВМ не знают, что совместно используют одну и ту же платформу. В данном контексте виртуальная машина – это просто контейнер для операционной системы и приложений. Интересное преимущество данного подхода состоит в том, что виртуальная машина изолируется от других виртуальных машин, запущенных на этом же гипервизоре, что позволяет иметь несколько операционных систем или несколько конфигураций одной операционной системы.

Обязанности

В обязанности гипервизора входит: изоляция операционных систем друг от друга, разделение ресурсов между операционными системами, управление ресурсами, обеспечение защиты и безопасности операционных систем. Гипервизор – предоставляет операционным системам, работающим под его управлением виртуализацию и эмуляцию реального аппаратного обеспечения, управляет этими виртуальным операционными системами и выделяет и освобождает ресурсы для них, так же предоставляет возможности независимого запуска, перезагрузки и останова каждой из них. Работа для операционной системы под управлением гипервизора ничем не отличается от работы на реальном аппаратном обеспечении.

Типы

Все гипервизоры, обеспечивающие работу виртуальных машин и приложений, делятся на два типа. Большинство современных гипервизоров относятся к Type 2, что подразумевает установку гипервизора в основную клиентскую операционную систему. Гипервизоры, которые относятся к Type 1, интегрируются с аппаратной составляющей ВС, а клиентская операционная система работает поверх этой аппаратуры и гипервизора. По мнению Тима Джонса в реализации технологий ВМ выделяются три основных подхода (рис. 1).

Гипервизор первого типа (автономный, тонкий, исполняемый на “голом железе” — Type 1, native, bare-metal) — программа, исполняемая непосредственно на аппаратном уровне компьютера и выполняющая функции эмуляции физического аппаратного обеспечения и управления аппаратными средствами и гостевыми ОС. То есть такой гипервизор сам по себе в некотором роде является минимальной операционной системой.
Гипервизор второго типа (хостовый, монитор виртуальных машин — hosted, Type-2, V) — специальный дополнительный программный слой, расположенный поверх основной хостовой ОС, который в основном выполняет функции управления гостевыми ОС, а эмуляцию и управление аппаратурой берет на себя хостовая ОС.
Гипервизор гибридный (Hybrid, Type-1+) — объединенный вариант первых двух, в котором функции управления аппаратными средствами выполняются тонким гипервизором и специальной депривилегированной сервисной ОС, работающей под управлением тонкого гипервизора. Обычно гипервизор управляет напрямую процессором и памятью компьютера, а через сервисную ОС гостевые ОС работают с остальными аппаратными компонентами.

автономный гипервизор (Тип 1) имеет свои встроенные драйверы устройств, модели драйверов и планировщик и поэтому не зависит от базовой ОС. Так как автономный гипервизор работает непосредственно в окружении усечённого ядра, то он более производителен, но проигрывает в производительности виртуализации на уровне ОС и паравиртуализации. Примерами таких технологий выступают: VMware ESX , Citrix, XenServer. Гипервизор на основе базовой ОС (Тип 2, V) представляет собой компонент, работающий в одном кольце с ядром основной ОС (кольцо 0). Гостевой код может выполняться прямо на физическом процессоре, но доступ к устройствам ввода-вывода компьютера из гостевой ОС осуществляется через второй компонент, обычный процесс основной ОС — монитор уровня пользователя. Примерами таких гипервизоров выступают: VirtualBox, VMware Workstation, QEMU, Parallels. Гибридный гипервизор (Тип 1+) состоит из двух частей: из тонкого гипервизора, контролирующего процессор и память, а также работающей под его управлением специальной сервисной ОС в кольце пониженного уровня. Через сервисную ОС гостевые ОС получают доступ к физическому оборудованию. Примерами данного вида гипервизоров выступают: Sun Logical Domains, Xen, Citrix XenServer, Microsoft Hyper- V.

Типы архитекруры на реальных примерах

VMware vSphere Hypervisor

Классический вариант полностью автономного гипервизора, который относится к категории архитектуры монолитного ядра. Он содержит всё необходимое для работы ВМ и по сути является автономной ОС, включающей в том числе и драйверы для работы с оборудованием. Именно на эти моменты как на архитектурные преимущества делает акцент VMware, подчеркивая, что такой подход обеспечивает наиболее полную изоляцию ВМ, а следовательно, и более высокую надежность системы в целом. В целом ее ESX Server состоит из собственно гипервизора, среды исполнения (ESXi) и сервисной консоли на базе ядра Linux, при этом ESXi может использоваться автономно, но в этом случае у него ограничены возможности управления системой. Критики данного варианта указывают на сложность решения задачи реализации собственной модели драйверов, доводка которой до нужного уровня является многолетней задачей. Отмечается также, что вся архитектура ESX - закрытая, проприетарная (на это делает акцент даже Microsoft).

Microsoft Hyper-V

Придерживается иного подхода, который называют архитектурой микроядра, т.е. разделения функций по разным модулям и уровням. В сущности данный подход вариант гипервизора смешанного типа (Тип 1+), когда сам гипервизор выполняет только функции управления памятью и процессором, а для взаимодействия с внешними устройствами и управления служит привилегированная родительская ВМ на базе ядра Windows (в случае Citrix — Linux).

По мнению разработчиков Microsoft, такой подход более эффективен при высокой вычислительной нагрузке, когда используется только “тонкий” гипервизор, который в случае Microsoft занимает всего порядка 100 Кб оперативной памяти.

Для ускорения же работы на уровне драйверов Microsoft использует два механизма взаимодействия прикладных BM с родительской. В одном случае применяется специальный внутренний интерфейс VMBus, который позволяет общаться ВМ между собой напрямую. Он доступен для ВМ, реализованных на базе Windows, а также Xen, но только для тех разработчиков, с кем у Microsoft есть соответствующий уровень сотрудничества. Для всех остальных ОС используется второй вариант полной эмуляции драйверов. Как свое преимущество Microsoft также подчеркивает наличие в ее Hyper-V проверенной модели драйверов, которая развивается в рамках Windows Server в целом на протяжении ряда лет.

Citrix XenServer

KVM

Qemu-KVM

Архитектура Hyper-V: Глубокое погружение / Хабр

Всем занять свои места! Задраить люки! Приготовиться к погружению! В этой статье я попытаюсь рассказать об архитектуре Hyper-V еще подробнее, чем я сделал это ранее.

Что же такое – Hyper-V?

Hyper-V – это одна из технологий виртуализации серверов, позволяющая запускать на одном физическом сервере множество виртуальных ОС. Эти ОС именуются «гостевыми», а ОС, установленная на физическом сервере – «хостовой». Каждая гостевая операционная система запускается в своем изолированном окружении, и «думает», что работает на отдельном компьютере. О существовании других гостевых ОС и хостовой ОС они «не знают». Эти изолированные окружения именуются «виртуальными машинами» (или сокращенно — ВМ). Виртуальные машины реализуются программно, и предоставляют гостевой ОС и приложениям доступ к аппаратным ресурсам сервера посредством гипервизора и виртуальных устройств. Как уже было сказано, гостевая ОС ведет себя так, как будто полностью контролирует физический сервер, и не имеет представления о существовании других виртуальных машин. Так же эти виртуальные окружения могут именоваться «партициями» (не путать с разделами на жестких дисках). Впервые появившись в составе Windows Server 2008, ныне Hyper-V существует в виде самостоятельного продукта Hyper-V Server (де-факто являющегося сильно урезанной Windows Server 2008), и в новой версии – R2 – вышедшего на рынок систем виртуализации Enterprise-класса. Версия R2 поддерживает некоторые новые функции, и речь в статье пойдет именно об этой версии.

Гипервизор

Термин «гипервизор» уходит корнями в 1972 год, когда компания IBM реализовала виртуализацию в своих мэйнфреймах System/370. Это стало прорывом в ИТ, поскольку позволило обойти архитектурные ограничения и высокую цену использования мэйнфреймов. Гипервизор – это платформа виртуализации, позволяющая запускать на одном физическом компьютере несколько операционных систем. Именно гипервизор предоставляет изолированное окружение для каждой виртуальной машины, и именно он предоставляет гостевым ОС доступ к аппаратному обеспечению компьютера. Гипервизоры можно разделить на два типа по способу запуска (на «голом железе» или внутри ОС) и на два типа по архитектуре (монолитная и микроядерная).

Гипервизор 1 рода

Гипервизор 1 типа запускается непосредственно на физическом «железе» и управляет им самостоятельно. Гостевые ОС, запущенные внутри виртуальных машин, располагаются уровнем выше, как показано на рис.1.

Рис.1 Гипервизор 1 рода запускается на «голом железе».

Работа гипервизоров 1 рода непосредственно с оборудованием позволяет достичь большей производительности, надежности и безопасности. Гипервизоры 1 рода используются во многих решениях Enterprise-класса:

Microsoft Hyper-V
VMware ESX Server
Citrix XenServer

Гипервизор 2 рода

В отличие от 1 рода, гипервизор 2 рода запускается внутри хостовой ОС (см. рис.2).

Рис.2 Гипервизор 2 рода запускается внутри гостевых ОС

Виртуальные машины при этом запускаются в пользовательском пространстве хостовой ОС, что не самым лучшим образом сказывается на производительности. Примерами гипервизоров 2 рода служат MS Virtual Server и VMware Server, а так же продукты десктопной виртуализации – MS VirtualPC и VMware Workstation.

Монолитный гипервизор

Гипервизоры монолитной архитектуры включают драйверы аппаратных устройств в свой код (см. рис. 3).

Рис. 3. Монолитная архитектура

Монолитная архитектура имеет свои достоинства и недостатки. Среди достоинств можно отметить:

Более высокую (теоретически) производительность из-за нахождения драйверов в пространстве гипервизора
Более высокую надежность, так как сбои в работе управляющей ОС (в терминах VMware – «Service Console») не приведет к сбою всех запущенных виртуальных машин.

Недостатки же у монолитной архитектуры следующие:

Поддерживается только то оборудование, драйверы на которое имеются в гипервизоре. Из-за этого вендор гипервизора должен тесно сотрудничать с вендорами оборудования, чтобы драйвера для работы всего нового оборудования с гипервизором вовремя писались и добавлялись в код гипервизора. По той же причине при переходе на новую аппаратную платформу может понадобиться переход на другую версию гипервизора, и наоборот – при переходе на новую версию гипервизора может понадобиться смена аппаратной платформы, поскольку старое оборудование уже не поддерживается.
Потенциально более низкая безопасность – из-за включения в гипервизор стороннего кода в виде драйверов устройств. Поскольку код драйверов выполняется в пространстве гипервизора, существует теоретическая возможность воспользоваться уязвимостью в коде и получить контроль как над хостовой ОС, так и над всеми гостевыми.

Самым распространенным примером монолитной архитектуры является VMware ESX.

Микроядерная архитектура

При микроядерной архитектуре драйверы устройств работают внутри хостовой ОС. Хостовая ОС в этом случае запускается в таком же виртуальном окружении, как и все ВМ, и именуется «родительской партицией». Все остальные окружения, соответственно – «дочерние». Единственная разница между родительской и дочерними партициями состоит в том, что только родительская партиция имеет непосредственный доступ к оборудованию сервера. Выделением памяти же и планировкой процессорного времени занимается сам гипервизор.

Рис. 4. Микроядерная архитектура

Достоинства у такой архитектуры следующие:

Не требуются драйвера, «заточенные» под гипервизор. Гипервизор микроядерной архитектуры совместим с любым оборудованием, имеющим драйверы для ОС родительской партиции.
Поскольку драйверы выполняются внутри родительской партиции – у гипервизора остается больше времени на более важные задачи – управление памятью и работу планировщика.
Более высокая безопасность. Гипервизор не содержит постороннего кода, соответственно и возможностей для атаки на него становится меньше.

Самым ярким примером микроядерной архитектуры является, собственно, сам Hyper-V.

Архитектура Hyper-V

На рис.5 показаны основные элементы архитектуры Hyper-V.

Рис.5 Архитектура Hyper-V

Как видно из рисунка, гипервизор работает на следующем уровне после железа – что характерно для гипервизоров 1 рода. Уровнем выше гипервизора работают родительская и дочерние партиции. Партиции в данном случае – это области изоляции, внутри которых работают операционные системы. Не нужно путать их, к примеру, с разделами на жестком диске. В родительской партиции запускается хостовая ОС (Windows Server 2008 R2) и стек виртуализации. Так же именно из родительской партиции происходит управление внешними устройствами, а так же дочерними партициями. Дочерние же партиции, как легко догадаться – создаются из родительской партиции и предназначены для запуска гостевых ОС. Все партиции связаны с гипервизором через интерфейс гипервызовов, предоставляющий операционным системам специальный API. Если кого-то из разработчиков интересуют подробности API гипервызовов — информация имеется в MSDN.

Родительская партиция

Родительская партиция создается сразу же при установке системной роли Hyper-V. Компоненты родительской партиции показаны на рис. 6. Назначение родительской партиции следующее:

Создание, удаление и управление дочерними партициями, в том числе и удаленное, посредством WMI-провайдера.
Управление доступом к аппаратным устройствам, за исключением выделения процессорного времени и памяти – этим занимается гипервизор.
Управление питанием и обработка аппаратных ошибок, если таковые возникают.

Рис.6 Компоненты родительской партиции Hyper-V

Стек виртуализации Следующие компоненты, работающие в родительской партиции, в совокупности называют стеком виртуализации:

Служба управления виртуальными машинами (VMMS)
Рабочие процессы виртуальных машин (VMWP)
Виртуальные устройства
Драйвер виртуальной инфраструктуры (VID)
Библиотека интерфейсов гипервизора

Помимо этого, в родительской партиции работают еще два компонента. Это провайдеры служб виртуализации (VSP) и шина виртуальных машин (VMBus). Служба управления виртуальными машинами В задачи службы управления виртуальными машинами (VMMS) входит:

Управление состоянием виртуальных машин (включено/выключено)
Добавление/удаление виртуальных устройств
Управление моментальными снимками

При запуске виртуальной машины VMMS создает новый рабочий процесс виртуальной машины. Подробнее о рабочих процессах будет рассказано далее. Так же именно VMMS определяет, какие операции разрешено выполнять с виртуальной машиной в настоящий момент: к примеру, если происходит удаление снапшота, то применить снапшот в течение операции удаления она не даст. Подробнее о работе с моментальными снимками (снапшотами) виртуальных машин можно почитать в соответствующей моей статье. Если говорить более детально – то VMMS управляет следующими состояниями виртуальных машин:

Starting
Active
Not Active
Taking Snapshot
Applying Snapshot
Deleting Snapshot
Merging Disk

Другие задачи управления – Pause, Save и Power Off – выполняются не службой VMMS, а непосредственно рабочим процессом соответствующей виртуальной машины. Служба VMMS работает как на уровне пользователя, так и на уровне ядра как системная служба (VMMS.exe) и зависит от служб Remote Procedure Call (RPC) и Windows Management Instrumentation (WMI). Служба VMMS включает в себя множество компонент, среди которых имеется и WMI-провайдер, предоставляющий интерфейс для управления виртуальными машинами. Благодаря этому можно управлять виртуальными машинами из командной строки и с помощью скриптов VBScript и PowerShell. System Center Virtual Machine Manager так же использует этот интерфейс для управления виртуальными машинами.Рабочий процесс виртуальной машины (VMWP) Для управления виртуальной машиной из родительской партиции запускается особый процесс – рабочий процесс виртуальной машины (VMWP). Процесс этот работает на уровне пользователя. Для каждой запущенной виртуальной машины служба VMMS запускает отдельный рабочий процесс. Это позволяет изолировать виртуальные машины друг от друга. Для повышения безопасности, рабочие процессы запускаются под встроенным пользовательским аккаунтом Network Service. Процесс VMWP используется для управления соответствующей виртуальной машиной. В его задачи входит: Создание, конфигурация и запуск виртуальной машины Пауза и продолжение работы (Pause/Resume) Сохранение и восстановление состояния (Save/Restore State) Создание моментальных снимков (снапшотов) Кроме того, именно рабочий процесс эмулирует виртуальную материнскую плату (VMB), которая используется для предоставления памяти гостевой ОС, управления прерываниями и виртуальными устройствами.Виртуальные устройства Виртуальные устройства (VDevs) – это программные модули, реализующие конфигурацию и управление устройствами для виртуальных машин. VMB включает в себя базовый набор виртуальных устройств, включающий в себя шину PCI и системные устройства, идентичные чипсету Intel 440BX. Есть два типа виртуальных устройств:

Эмулируемые устройства – эмулируют определенные аппаратные устройства, такие, к примеру, как видеоадаптер VESA. Эмулируемых устройств достаточно много, к примеру: BIOS, DMA, APIC, шины ISA и PCI, контроллеры прерываний, таймеры, управление питанием, контроллеры последовательных портов, системный динамик, контроллер PS/2 клавиатуры и мыши, эмулируемый (Legacy) Ethernet-адаптер (DEC/Intel 21140), FDD, IDE-контроллер и видеоадаптер VESA/VGA. Именно поэтому для загрузки гостевой ОС может использоваться только виртуальный IDE-контроллер, а не SCSI, который является синтетическим устройством.
Синтетические устройства – не эмулируют реально существующие в природе железки. Примерами служат синтетический видеоадаптер, устройства взаимодействия с человеком (HID), сетевой адаптер, SCSI-контроллер, синтетический контроллер прерывания и контроллер памяти. Синтетические устройства могут использоваться только при условии установки компонент интеграции в гостевой ОС. Синтетические устройства обращаются к аппаратным устройствам сервера посредством провайдеров служб виртуализации, работающих в родительской партиции. Обращение идет через виртуальную шину VMBus, что намного быстрее, чем эмуляция физических устройств.

Драйвер виртуальной инфраструктуры (VID) Драйвер виртуальной инфраструктуры (vid.sys) работает на уровне ядра и осуществляет управление партициями, виртуальными процессорами и памятью. Так же этот драйвер является промежуточным звеном между гипервизором и компонентами стека виртуализации уровня пользователя.Библиотека интерфейса гипервизора Библиотека интерфейса гипервизора (WinHv.sys) – это DLL уровня ядра, которая загружается как в хостовой, так и в гостевых ОС, при условии установки компонент интеграции. Эта библиотека предоставляет интерфейс гипервызовов, использующийся для взаимодействия ОС и гипервизора.Провайдеры служб виртуализации (VSP) Провайдеры служб виртуализации работают в родительской партиции и предоставляют гостевым ОС доступ к аппаратным устройствам через клиент служб виртуализации (VSC). Связь между VSP и VSC осуществляется через виртуальную шину VMBus.Шина виртуальных машин (VMBus) Назначение VMBus состоит в предоставлении высокоскоростного доступа между родительской и дочерними партициями, в то время как остальные способы доступа значительно медленнее из-за высоких накладных расходах при эмуляции устройств. Если гостевая ОС не поддерживает работу интеграционных компонент – приходится использовать эмуляцию устройств. Это означает, что гипервизору приходится перехватывать вызовы гостевых ОС и перенаправлять их к эмулируемым устройствам, которые, напоминаю, эмулируются рабочим процессом виртуальной машины. Поскольку рабочий процесс запускается в пространстве пользователя, использование эмулируемых устройств приводит к значительному снижению производительности по сравнению с использованием VMBus. Именно поэтому рекомендуется устанавливать компоненты интеграции сразу же после установки гостевой ОС. Как уже было сказано, при использовании VMBus взаимодействие между хостовой и гостевой ОС происходит по клиент-серверной модели. В родительской партиции запущены провайдеры служб виртуализации (VSP), которые являются серверной частью, а в дочерних партициях – клиентская часть – VSC. VSC перенаправляет запросы гостевой ОС через VMBus к VSP в родительской партиции, а сам VSP переадресовывает запрос драйверу устройства. Этот процесс взаимодействия абсолютно прозрачен для гостевой ОС.

Дочерние партиции

Вернемся к нашему рисунку с архитектурой Hyper-V, только немного сократим его, поскольку нас интересуют лишь дочерние партиции.

Рис. 7 Дочерние партиции

Итак, в дочерних партициях могут быть установлены:

ОС Windows, с установленными компонентами интеграции (в нашем случае – Windows 7)
ОС не из семейства Windows, но поддерживающая компоненты интеграции (Red Hat Enterprise Linux в нашем случае)
ОС, не поддерживающие компоненты интеграции (например, FreeBSD).

Во всех трех случаях набор компонент в дочерних партициях будет немного различаться.ОС Windows с установленными компонентами интеграции Операционные системы Microsoft Windows, начиная с Windows 2000 поддерживают установку компонент интеграции. После установки Hyper-V Integration Services в гостевой ОС запускаются следуюшие компоненты:

Клиенты служб виртуализации. VSC представляют собой синтетические устройства, позволяющие осуществлять доступ к физическим устройствам посредством VMBus через VSP. VSC появляются в системе только после установки компонент интеграции, и позволяют использовать синтетические устройства. Без установки интеграционных компонент гостевая ОС может использовать только эмулируемые устройства. ОС Windows 7 и Windows Server 2008 R2 включает в себя компоненты интеграции, так что их не нужно устанавливать дополнительно.
Улучшения. Под этим имеются в виду модификации в коде ОС чтобы обеспечить работу ОС с гипервизором и тем самым повысить эффективность ее работы в виртуальной среде. Эти модификации касаются дисковой, сетевой, графической подсистем и подсистемы ввода-вывода. Windows Server 2008 R2 и Windows 7 уже содержат в себе необходимые модификации, на другие поддерживаемые ОС для этого необходимо установить компоненты интеграции.

Так же, компоненты интеграции предоставляют следующий функционал:

Heartbeat – помогает определить, отвечает ли дочерняя партиция на запросы из родительской.
Обмен ключами реестра – позволяет обмениваться ключами реестра между дочерней и родительской партицией.
Синхронизация времени между хостовой и гостевой ОС
Завершение работы гостевой ОС
Служба теневого копирования томов (VSS), позволяющая получать консистентные резервные копии.

ОС не из семейства Windows, но поддерживающая компоненты интеграции Существуют так же ОС, не относящиеся к семейству Windows, но поддерживающие компоненты интеграции.На данный момент – это только SUSE Linux Enterprise Server и Red Hat Enterprise Linux. Такие ОС при установке компонент интеграции используют VSC сторонних разработчиков для взаимодействия с VSC по VMBus и доступа к оборудованию. Компоненты интеграции для Linux разработаны компанией Microsoft совместно с Citrix и доступны для загрузки в Microsoft Download Center. Поскольку компоненты интеграции для Linux были выпущены под лицензией GPL v2, ведутся работы по интеграции их в ядро Linux через Linux Driver Project, что позволит значительно расширить список поддерживаемых гостевых ОС.

Вместо заключения

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

Выражаю огромную благодарность Mitch Tulloch и Microsoft Virtualization Team. На основе их книги Understanding Microsoft Virtualization Solutions и была подготовлена статья.

habr.com

Отличия гипервизора на монолитной и микроядерной архитектуре

Добрый день уважаемые читатели блога и подписчики youtube канала, сегодня я хочу с вами поговорить на тему какие отличия гипервизора на монолитной и микроядерной архитектуре, я думаю не все знают о том, что архитектур две. Мы с вами узнаем, у кого какие плюсы и минусы, так сказать продолжим холивары между Vmware и Microsoft, уверен вам это будет очень интересно и вы сможете, что-то переосмыслить.

Игроки на рынке виртуализации

И так. я вам давно уже рассказывал, что такое виртуализация и рассказывал ее принципы на примере Vmware ESXI. Сегодня я хочу вам рассказать как работает Hyper-V и чем же отличаются два подхода в плане архитектуры процесса гипервизора. Как вы знаете на рынке сейчас два крупных игрока, первый и лидирующий это Vmware и догоняющий его с каждым годом Microsoft Hyper-V. Напомню, что каждое из данных решений, позволяет вам на одном физическом сервере запускать множество виртуальных машин с любой операционной системой. Такие ос, называются гостевыми, а основная называется хостовой. Все гостевые ОС работают в своем изолированном окружении, и самое забавное, что каждая думает, что она работает на отдельном сервере.

Работать так по хитрому, помогает программная реализация, гипервизор, дающая им доступ к физическим ресурсам сервера. В терминологии Microsoft данные виртуальные машины еще именуются как партиции.

Что такое гипервизор

Я думаю если спросить большинство инженеров по виртуализации, то они не смогут вам сказать происхождение слова гипервизор. Данное понятие, появилось кажется в 1972 году, в компании IBM. В те далекие времена перед IBM стояла задача виртуализации на своих мэйнфреймах System/370. Это стало просто мега открытием, с дало возможность обходить архитектурные ограничения и как следствие хорошую экономию по деньгам, так как мэйнфреймы стояли дорого, а они научились их использовать более рационально и полностью утилизировать их ресурсы.

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

Архитектуры гипервизоров

Существует две различные архитектуры:

монолитная
микроядерная

По мимо архитектур, у гипервизоров, еще и два типа

1 Тип гипервизора

К первому типу гипервизора относится вот такой принцип. Он запускается именно на на физическом железе и сам принимает решения по его управлению. А вот гостевые ос, работающие на нем лежат на уровень выше, и работают через него, некое такое посредничество. За счет чего, данный тип имеет максимальную производительность в сравнении со вторым типом.

К данному типу относятся вот такие игроки:

VMware ESXI
Hyper-V
Citrix XenServer

2 Тип гипервизора

Ко второму типу гипервизора относятся продукты которые позволяю виртуализовывать операционные системы, работая как программы на хостовой операционной системе.

Очень простой пример, у вас есть установленная Windows 8.1, внутри нее вы устанавливаете гипервизор второго типа, у нас это будет VMware Workstation или Virtual Box. Как вы можете понять, в данном типе производительность ниже, чем у первого, так как есть излишняя и толстая прослойка в виде хостовой ос.

Монолитный гипервизор

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

Достоинства и недостатки монолитной архитектуры

Более высокая производительность, так как драйвера находятся внутри гипервизора.
Повышенная надежность, если у вас будет сбой управляющей ОС, например в Vmware ESXI это Service Console, то это никак не повлияет на запущенные виртуальные машины.

Что плохого:

Логично, что поддерживаются устройства, драйвера, которых у вас установлены в гипервизоре. Если вы попытаетесь например добавить сетевую карту или fc карту в сервер на котором установлена Vmware ESXi версия, то если драйвера не будет, у вас карточка не появится среди доступных. В следствии чего, вендор гипервизора, должен плотно общаться и взаимодействовать с производителями железа, просить у них писать драйвера на их устройства для себя, тестировать это все дело. По той же причине при переходе на новую аппаратную платформу может понадобиться переход на другую версию гипервизора, и наоборот – при переходе на новую версию гипервизора может понадобиться смена аппаратной платформы, поскольку старое оборудование уже не поддерживается.
Меньшая безопасность, так как приходится в гипервизор добавлять лишний код, это те драйвера, что вы устанавливаете. Так как драйвер работает в пространстве гипервизора, то можно теоретически воспользоваться уязвимостью кода, тем самым попытаться получить контрольный доступ над хостовой ос, а если он получен то и над гостевыми операционными системами.

Самый известный монолитный гипервизор, это конечно VMware ESXI.

Микроядерный гипевизор

Все с монолитной плитой мы разобрались. теперь на очереди понять принцип работы микроядерной архитектуры. Главное отличие в том, что драйвера на устройства устанавливаются внутри родительской ОС (хостовой)

По сути хоставая операционная система (Parent Partition), запускается как виртуальная машины, в том же окружении, где и все виртуалки, все остальные дочерние теперь. Разница между ними лишь в том, что родительская виртуалка, единственная имеет непосредственный доступ к оборудованию сервера. А выделением всевозможных ресурсов, различными планировщиками и оптимизацией мощностей занимается гипервизор.

Достоинства и недостатки микроядерной архитектуры

Что хорошего:

Как вы уже наверно догадались, не требуются драйвера заточенные под гипервизор, а уж под Windows найти драйвера не проблема. Гипервизор микроядерной архитектуры, имеет совместимость почти с любым оборудованием, и имеет в 99 процентов случаев драйвера для parent partition.
Если дальше развить мысль, то мы видим, что гипервизор разгрузили по задачам, так как драйвера обрабатывает родительская виртуальная машина, значит у него есть больше времени и ресурсов для более важных задач, например за управлением работы памяти, планировщика и т.д.
Более безопасен, так как левого кода не крутится в нем.

Ну и и из самых таких крутых представителей это архитектуры, это конечно Microsoft Hyper-V.

Принцип работы windows server hyper-v

Про, то как работает архитектура Vmware ESXi я уже писал и в этом нет нужды, сейчас хочу рассмотреть гипервизор windows server hyper-v, чтобы вы более точно поняли отличия монолитной и микроядерной систем. Ниже я вам привел схему работы Hyper-V, давайте ее более подробно рассмотрим.

Напоминаю это гипервизор первого типа. Поверх него работают parent partition (родительская партиция) и дочерние, их может быть много все зависит от мощностей сервера. В такой реализации, дочерние партиции, это некая такая область изоляции, в которой операционные системы, думают, что они работают одни и на отдельном железе.В такой конструкции, все управление железом, лежит полностью на родительской виртуальной машине, и плюс управляет еще и дочерними партициями.Через интерфейс гипервызовов, все партиции связаны с гипервизором, который предоставляется через некий API.

Родительская партиция Hyper-V

parent partition появляется в момент установки роли Hyper-V. Ниже представлена схема компонентов родительской партиции и для чего она нужна.

Логично, что нам нужно создавать, удалять и управлять дочерними виртуалками, плюс можно использовать WMI-провайдера
Осуществлять доступ управления к аппаратным устройствам, за исключением выделения процессорного времени и памяти – этим занимается гипервизор.
Контролировать управлением питания и обработкой различных аппаратных ошибок

Принцип работы стека виртуализации

Тут я хочу более подробно рассмотреть, какие именно компоненты, работают в parent partition Hyper-V, все вместе они называются стек, и это не только у Microsoft, это во всех средах так называется некий набор компонентов, простой пример стек TCP/IP, который состоит из тьмы протоколов.

Служба VMMS (Virtual Machine Management service), отвечает за управление виртуалками
Служба VMWP, управляет рабочими процессами виртуалок.
Virtual Device или виртуальные устройства
Драйвер VID
Библиотека интерфейсов гипервизора

Забыл сказать, что в архитектуре Hyper-V есть еще два рабочих компонента. Это VSP или провайдер служб виртуализации, а так же VMBus или если угодно шина виртуальных машин.

Компоненты VMMS

И так давайте смотреть, что входит в состав службы управления виртуальными машинами.

Она обязана управлять состояниями виртуалок, включена или выключена
С помощью нее вы добавляете или на оборот удаляете виртуальные устройства
Ну и конечно работа со снапшотами или как их еще называют моментальные снимки.

Как это работает, вы запускаете виртуальную машину, служба VMMS это видит и сразу под нее делает новеньких рабочий процесс. VMMS смотрит, что можно из операций делать с виртуальной машиной на текущий момент. Приведу пример допустим вы снимаете или удаляете снапшот, логично, что в этот момент она не даст вам применить какой либо другой снапшот.

За что отвечает VMMS:

Запуск (Starting)
Активность (Active)
Не активность (Простой) (Not Active)
Снятие снапшота (Taking Snapshot)
Применение снапшота (Applying Snapshot)
Удаление снапшота (Deleting Snapshot)
Объединение дисков (Merging Disk)

Если вы вспомните про такие команды как пауза (Pause), Сохранить (Save ) или Завершить (Power Off), то ими не управляет VMMS, они то как раз работают в рабочем процессе соответствующей виртуальной машины. VMMS функционирует на двух уровнях, на уровне ядра как системная служба (VMMS.exe) и на уровне пользователя, она так же зависит от служб Remote Procedure Call (RPC) и Windows Management Instrumentation (WMI). Интерфейс для манипулированием виртуалок, ей предоставляет WMI-провайдер, входящий в VMMS как компонент. Из чего следует, что есть возможность работы с машинками из командной строки, а так же с помощью таких вещей как PowerShell или VBScript скрипты. Если вы знакомы с таким комплексом как System Center Virtual Machine Manager, то наверняка знаете. что он для управления виртуальными мишинками, тоже дергает этот интерфейс.

Теперь давайте разбираться в рабочем процессе виртуальной машины VMWP. Чтобы управлять виртуальной машиной за счет parent partition, используется специальный процесс VMWP. Он на пользовательском уровне запускается для каждой виртуальной машины, за счет службы VMMS. Благодаря этому, достигается изолированность виртуальных машин друг от друга. Работают эти рабочие процессы из под локальной учетной записи Network Service, чтобы сделать весь процесс более безопасным.

Задачи VMWP:

Благодаря ему вы можете создавать, конфигурировать и запускать виртуальные машины
Выполнять команды продолжение работы или пауза
Делать снимки за счет команд Сохранить или восстановить состояние.
Эмулирует в виртуальной машине материнскую плату VMB, ее используют виртуальные устройства, управление прерываниями и выделение памяти для гостевой операционной системы.

Виртуальные устройства Hyper-V

Давайте разбираться, что же такое эти виртуальные девайсы или в терминологии Hyper-V их называют VDevs - все очень просто это программы, с помощью которых реализовывается конфигурация и управление устройствами в виртуалках. Какие именно компоненты входят в VMB, по сути это шина PCI и куча системных устройств, идентичные чипсету Intel 440BX. VMB бывают двух видов:

Синтетические устройства - это устройства, которых в природе и не существует, у Vmware это могут быть примеры сетевых карточек VMXNET3, которых в жизни не существует. Примерами служат синтетический видеоадаптер, устройства взаимодействия с человеком (HID), сетевой адаптер, SCSI-контроллер, синтетический контроллер прерывания и контроллер памяти. Синтетические устройства могут использоваться только при условии установки компонент интеграции в гостевой ОС. Синтетические устройства обращаются к аппаратным устройствам сервера посредством провайдеров служб виртуализации, работающих в родительской партиции. Обращение идет через виртуальную шину VMBus, что намного быстрее, чем эмуляция физических устройств.

Эмулируемые устройства – эмулируют настоящие аппаратные устройства, которые можно найти в виде реальных деталей, такие, к примеру, как видеоадаптер VESA. Эмулируемых устройств достаточно много, к примеру: BIOS, DMA, APIC, шины ISA и PCI, контроллеры прерываний, таймеры, управление питанием, контроллеры последовательных портов, системный динамик, контроллер PS/2 клавиатуры и мыши, эмулируемый (Legacy) Ethernet-адаптер (DEC/Intel 21140), FDD, IDE-контроллер и видеоадаптер VESA/VGA. Именно поэтому для загрузки гостевой ОС может использоваться только виртуальный IDE-контроллер, а не SCSI, который является синтетическим устройством.

VSP провайдеры служб виртуализации

VSP это службы, а точнее провайдеры виртуализации, работающие в parent partition и дающие для гостевых операционных систем доступ к аппаратным устройствам, как раз за счет VSC или клиента служб виртуализации. Их связь поддерживает VMBus шина.

Библиотека интерфейса гипервизора

Смысл данной библиотеки WinHv.sys – это DLL на уровне ядра, которая загружается как в хостовой, так и в гостевых ОС, при условии установки компонент интеграции. Эта библиотека предоставляет интерфейс гипервызовов, использующийся для взаимодействия ОС и гипервизора.

VID драйвер виртуальной инфраструктуры

VID драйвер vid.sys функционирует на уровне ядра и выполняет управление партициями, виртуальными процессорами и памятью. Так же этот драйвер является промежуточным звеном между гипервизором и компонентами стека виртуализации уровня пользователя.

VMBus шина виртуальных машин

VMBus делает следующее, ей нужно предоставить высокоскоростной доступ между дочерними ос и родительской ос, это самый быстрый вид доступа, так как у остальных больше накладные расходы при эмуляции устройств. Если у вас в операционной системе не установлены компоненты интеграции, то гипервизор вынужден производить перехват вызовов от гостевой ос и перенаправлять их на эмулированные устройства, которые, напоминаю, эмулируются рабочим процессом виртуальной машины.Поскольку рабочий процесс запускается в пространстве пользователя, использование эмулируемых устройств приводит к значительному снижению производительности по сравнению с использованием VMBus. Именно поэтому рекомендуется устанавливать компоненты интеграции сразу же после установки гостевой ОС.

Как уже было сказано, при использовании VMBus взаимодействие между хостовой и гостевой ОС происходит по клиент-серверной модели. В родительской партиции запущены провайдеры служб виртуализации (VSP), которые являются серверной частью, а в дочерних партициях – клиентская часть – VSC. VSC перенаправляет запросы гостевой ОС через VMBus к VSP в родительской партиции, а сам VSP переадресовывает запрос драйверу устройства. Этот процесс взаимодействия абсолютно прозрачен для гостевой ОС.

Что можно поставить в дочерних партициях

ОС Windows, с установленными компонентами интеграции (в нашем случае – Windows 10)
ОС не из семейства Windows, но поддерживающая компоненты интеграции (Red Hat Enterprise Linux в нашем случае)
ОС, не поддерживающие компоненты интеграции (например, FreeBSD).

Во всех трех случаях набор компонент в дочерних партициях будет немного различаться.

Компоненты интеграции для семейства Windows поддерживаются начиная с 2000 версии. Как только вы установите в операционную систему Hyper-V Integration Services, у вас начнут работать вот такие компоненты:

VSC или клиент служб виртуализации, по сути это синтетические устройства, которые через VMBus > VSP получают доступ к физическим устройствам. VSC работает, только после установки Hyper-V Integration Services и уже после этого синтетические устройства вам доступны, все как и в Vmware. Еще начиная с Windows 7 и Windows Server 2008 R2, они под капотом имеют Hyper-V Integration Services, инсталлировать их дополнительно не нужно. Еще одно из назначение компонентов интеграции, это обеспечить более быструю работу гостевой ОС и гипервизора. Данный код относится к дисковой, графической и сетевой подсистеме, навенро сразу замечали, что как только их поставишь, система сразу в консоли перестает тормозить.

Так же, компоненты интеграции предоставляют следующий функционал:

Heartbeat (или серцебиения)– помогает определить, отвечает ли дочерняя партиция на запросы из родительской.
Обмен ключами реестра – позволяет обмениваться ключами реестра между дочерней и родительской партицией.
Синхронизация времени между хостовой и гостевой ОС, но лучше синхронизироваться, все же с контроллером домена.
Завершение работы гостевой ОС
Служба теневого копирования томов (VSS), позволяющая получать консистентные резервные копии.

Какие ос еще поддерживают компоненты интеграции

SUSE Linux Enterprise Server
Red Hat Enterprise Linux

У них правда свой VSC от сторонних производителей. Компоненты интеграции для Linux разработаны компанией Microsoft совместно с Citrix и доступны для загрузки в Microsoft Download Center.

Поскольку компоненты интеграции для Linux были выпущены под лицензией GPL v2, ведутся работы по интеграции их в ядро Linux через Linux Driver Project, что позволит значительно расширить список поддерживаемых гостевых ОС. Надеюсь вы теперь поняли разницу между монолитной и микроядерной архитектурой.

pyatilistnik.org

Гипервизор — WiKi

Гиперви́зор (англ. Hypervisor; от др.-греч. ὑπέρ «над, выше, сверх» + лат. vīsio «зрение; видение») или монито́р виртуа́льных маши́н (в компьютерах) — программа или аппаратная схема, обеспечивающая или позволяющая одновременное, параллельное выполнение нескольких операционных систем на одном и том же хост-компьютере. Гипервизор также обеспечивает изоляцию операционных систем друг от друга, защиту и безопасность, разделение ресурсов между различными запущенными ОС и управление ресурсами.

Гипервизор также может (и обязан) предоставлять работающим под его управлением на одном хост-компьютере ОС средства связи и взаимодействия между собой (например, через обмен файлами или сетевые соединения) так, как если бы эти ОС выполнялись на разных физических компьютерах.

Гипервизор сам по себе в некотором роде является минимальной операционной системой (микроядром или наноядром). Он предоставляет запущенным под его управлением операционным системам службу виртуальной машины, виртуализируя или эмулируя реальное (физическое) аппаратное обеспечение конкретной машины. И управляет этими виртуальными машинами, выделением и освобождением ресурсов для них. Гипервизор позволяет независимое «включение», перезагрузку, «выключение» любой из виртуальных машин с той или иной ОС. При этом операционная система, работающая в виртуальной машине под управлением гипервизора, может, но не обязана «знать», что она выполняется в виртуальной машине, а не на реальном аппаратном обеспечении.

Автономный гипервизор (Тип 1, X)

Имеет свои встроенные драйверы устройств, модели драйверов и планировщик и поэтому не зависит от базовой ОС. Так как автономный гипервизор работает непосредственно в окружении усечённого ядра, то он более производителен, но проигрывает в производительности виртуализации на уровне ОС и паравиртуализации. Например, кроссплатформенный гипервизор Xen может запускать виртуальные машины в паравиртуальном режиме (зависит от ОС).

Примеры: VMware ESX, Citrix XenServer.

На основе базовой ОС (Тип 2, V)

Это компонент, работающий в одном кольце с ядром основной ОС (кольцо 0). Гостевой код может выполняться прямо на физическом процессоре, но доступ к устройствам ввода-вывода компьютера из гостевой ОС осуществляется через второй компонент, обычный процесс основной ОС — монитор уровня пользователя.

Примеры: Microsoft Virtual PC, VMware Workstation, QEMU, Parallels, VirtualBox.

Гибридный (Тип 1+)

Гибридный гипервизор состоит из двух частей: из тонкого гипервизора, контролирующего процессор и память, а также специальной служебной ОС, работающей под его управлением в кольце пониженного уровня. Через служебную ОС гостевые ОС получают доступ к физическому оборудованию.

Примеры: Microsoft Virtual Server, Sun Logical Domains, Xen, Citrix XenServer, Microsoft Hyper-V.

ru-wiki.org

Национальная библиотека им. Н. Э. Баумана Bauman National Library. К какой категории гипервизоров принадлежит microsoft virtual pc

О гипервизорах, виртуализации систем и о том, как это работает в облачной среде

Серия контента:

Этот контент является частью # из серии # статей: Гипервизоры, виртуализация и облако

Этот контент является частью серии:Гипервизоры, виртуализация и облако

Об этом цикле статей

Рисунок 1. Виртуализация, переход от физического подхода к логическому

Общие сведения о гипервизорах

Рисунок 2. Различия между гипервизорами типа 1 и типа 2

Правильный выбор гипервизора

Производительность виртуальной машины

Управление памятью

Высокая готовность

Динамическая миграция

Сети, системы хранения данных и безопасность

Функции управления

Несколько советов...

Заключение

Ресурсы для скачивания

Похожие темы

Гипервизоры. Что же это и как работает виртуальный сервер? / Блог компании VPS.house / Хабр

Что такое гипервизор?

История гипервизоров

Преимущества гипервизоров

Контейнеры против гипервизоров

Проблемы безопасности гипервизоров

Расширение возможностей гипервизора

Сравнение гипервизоров: Hyper-V или Vmware

Типы гипервизоров

Битва гигантов: Hyper-V или VMware?

KVM — решение с открытым исходным кодом

Информация к размышлению

Гипервизор — Национальная библиотека им. Н. Э. Баумана

Определение

Термин

Обязанности

Типы

Типы архитекруры на реальных примерах

VMware vSphere Hypervisor

Microsoft Hyper-V

Citrix XenServer

KVM

Qemu-KVM

Популярные на рынке (2015)

Архитектура Hyper-V: Глубокое погружение / Хабр

Что же такое – Hyper-V?

Гипервизор

Гипервизор 1 рода

Гипервизор 2 рода

Монолитный гипервизор

Микроядерная архитектура

Архитектура Hyper-V

Родительская партиция

Дочерние партиции

Вместо заключения

Отличия гипервизора на монолитной и микроядерной архитектуре

Игроки на рынке виртуализации

Что такое гипервизор

Архитектуры гипервизоров

1 Тип гипервизора

2 Тип гипервизора

Монолитный гипервизор

Достоинства и недостатки монолитной архитектуры

Микроядерный гипевизор

Достоинства и недостатки микроядерной архитектуры

Принцип работы windows server hyper-v

Родительская партиция Hyper-V

Принцип работы стека виртуализации

Компоненты VMMS

Виртуальные устройства Hyper-V

Гипервизор — WiKi

Автономный гипервизор (Тип 1, X)

На основе базовой ОС (Тип 2, V)

Гибридный (Тип 1+)