Вложенная виртуализация: заставить конкурирующий гипервизор работать в Hyper-V
С тех пор, как Microsoft начала поддерживать вложение виртуальных машин для Hyper-V, я время от времени получал сообщения по электронной почте от людей, спрашивающих, можно ли запустить VMware ESXi внутри виртуальной машины Hyper-V. Краткий ответ на этот вопрос, куда бы вы вложили конкурирующий гипервизор, заключается в том, что это можно сделать, но сделать это не так просто, как вы могли бы предположить. В таком случае я решил написать статью, объясняющую, как заставить VMware работать внутри виртуальной машины Hyper-V, но в конечном итоге отказался от этого, потому что на различных веб-сайтах уже есть подробные сообщения в блогах с описанием процесса. Я подумал, что может быть более полезным использовать более общий подход к вложенной виртуализации и рассказать о некоторых вещах, на которые следует обратить внимание, когда вы вкладываете один гипервизор в другой.
Подумайте, почему вы используете вложенную виртуализацию.
Первое, что вы должны сделать, прежде чем пытаться виртуализировать гипервизор, — это рассмотреть причину, по которой вы это делаете. Существует множество причин, по которым организация может захотеть запустить один гипервизор внутри другого. Проблема в том, что это обычно официально не поддерживается. Например, я серьезно сомневаюсь, что VMware или Microsoft официально поддержат запуск ESXi внутри виртуальной машины Hyper-V, даже если это можно сделать. На самом деле, Microsoft даже заявляет, что «приложения виртуализации, отличные от Hyper-V, не поддерживаются в виртуальных машинах Hyper-V и, скорее всего, не будут работать».
Таким образом, я бы не рекомендовал использовать такую вложенную архитектуру виртуализации в производственной среде. С другой стороны, если вы работаете в лабораторной среде и имеете ограниченные аппаратные ресурсы, то вложение гипервизоров разных производителей может оказаться жизнеспособным вариантом.
С другой стороны, Microsoft полностью поддерживает виртуализацию Hyper-V внутри виртуальной машины Hyper-V. На самом деле, я видел демонстрацию на Microsoft Ignite в прошлом году, в которой кто-то создал большую виртуальную машину в Azure, включил вложенную виртуализацию, а затем установил Hyper-V. Это позволило создать настоящие виртуальные машины Hyper-V внутри среды Azure.
Ознакомьтесь с требованиями базового гипервизора
Одна из самых важных вещей, которую вы можете сделать перед созданием вложенного гипервизора от нескольких поставщиков, — это потратить время на рассмотрение требований для вложения базового гипервизора. Если, например, вы собираетесь использовать Hyper-V в качестве базового гипервизора, то обязательно ознакомьтесь с требованиями для вложенного Hyper-V. Эти требования могут дать вам представление о проблемах, с которыми вы можете столкнуться при виртуализации гипервизора другого поставщика. Например, когда Hyper-V работает внутри виртуальной машины, виртуальные машины, работающие поверх виртуализированного гипервизора, теряют поддержку динамической памяти. Несмотря на то, что это ограничение Hyper-V, вы можете обнаружить, что проблема также влияет на другие гипервизоры, которые вы можете виртуализировать.
Подумайте о требованиях к водителю
Одна из самых больших проблем, которую вам обычно приходится решать при вложении гипервизоров от разных поставщиков, — это поддержка драйверов. Чтобы показать вам, что я имею в виду, давайте вернемся к примеру запуска VMware ESXi внутри виртуальной машины Hyper-V.
Hyper-V, как и другие гипервизоры, представляет виртуальные машины с абстрактным представлением аппаратного обеспечения системы. Например, в случае сетевого драйвера Hyper-V взаимодействует с физическим сетевым адаптером, используя обычный драйвер Windows для этой сетевой карты. Однако Hyper-V предоставляет сетевой адаптер виртуальным машинам как виртуальный сетевой адаптер, привязанный к виртуальному сетевому коммутатору Hyper-V. Это означает, что независимо от того, какой тип сетевого адаптера физически установлен на сервере Hyper-V, виртуальным машинам потребуется драйвер либо для сетевого адаптера Microsoft Hyper-V, либо для устаревшего сетевого адаптера Microsoft. Вы можете увидеть пример этого на рисунке ниже.
Проблема заключается в том, что гипервизоры типа 1 предназначены для работы на «голом железе» и поэтому обычно не включают в себя драйверы виртуальных сетевых адаптеров (кроме тех, которые необходимы для самовложения). Способ, которым эта проблема решалась в большинстве вложенных блогов по виртуализации, которые я читал, заключается в создании файла ISO, содержащего гипервизор, который необходимо виртуализировать, а затем вставки необходимых файлов драйвера в файл ISO.
Хотя технически это не является требованием, некоторые люди сообщают, что у них меньше проблем и более высокая производительность благодаря использованию дискретных назначений устройств. Дискретные назначения устройств были введены в Windows Server 2016 как способ включения передачи физического оборудования для конкретной виртуальной машины. Например, в случае вложенной виртуализации сетевой адаптер на основе PCIe можно сопоставить непосредственно с виртуальной машиной, на которой работает виртуализированный гипервизор. Преимущество использования дискретных назначений устройств для сетевых адаптеров заключается в том, что это может потенциально устранить необходимость в драйвере виртуального устройства. По словам Microsoft, «после того, как устройство смонтировано внутри гостевой системы, драйвер устройства производителя теперь может быть установлен как обычно внутри гостевой виртуальной машины».
Стоит отметить, что использование дискретных назначений устройств накладывает некоторые ограничения на виртуальную машину Hyper-V, которой назначено устройство. Такие виртуальные машины не поддерживают сохранение/восстановление, динамическую миграцию или использование динамической памяти. Кроме того, виртуальную машину нельзя добавить в отказоустойчивый кластер.
Методом проб и ошибок
Заставить конкурирующий гипервизор работать внутри виртуальной машины Hyper-V — нетривиальный процесс. Даже после установки виртуализированного гипервизора вы, вероятно, обнаружите, что для обеспечения надежной работы его виртуальных машин требуется значительное количество проб и ошибок.
При создании сред с вложенными гипервизорами от разных поставщиков некоторые люди обнаружили, что вложение должно быть включено для виртуальных машин, работающих поверх вложенного гипервизора. В этих конкретных случаях вложенный гипервизор работает без проблем, но виртуальные машины не запускались до тех пор, пока вложенность не была включена на уровне ВМ. Это происходит потому, что виртуальные машины работали на гипервизоре, работающем поверх другого гипервизора.