Какое количество виртуальных машин можно создать на одном физическом устройстве компьютере
Сегодня я хотел бы подробнее остановиться на одной из новых возможностей Hyper-V в Windows Server 2012 R2, упомянутой мною в обзорном посте, а именно, обсудить второе поколение виртуальных машин (ВМ). Тема становится особенно актуальной с доступностью RTM Windows Server 2012 R2 для подписчиков TechNet и MSDN и скорым выпуском финальной версии System Center 2012 R2
С выходом Windows Server 2012 R2 в Hyper-V появилось возможность создавать ВМ двух разных типов или двух разных поколений (Generation 1 и Generation 2). ВМ первого поколения представляют собой виртуальные машины, хорошо известные по предыдущим версиям Hyper-V. Все, что вы привыкли видеть в настройках ВМ, плюс ряд новых настроек, вы увидите в машинах первого поколения. Они никуда не делись, вы можете и дальше спокойно их использовать.
Но помимо этого вы можете теперь создавать ВМ второго поколения. Это поколение отражает изменения, которые произошли и продолжают происходить как в архитектуре ОС, так и в аппаратном обеспечении современных компьютеров. На рубеже Windows 2000, Windows XP, Windows Server 2003 операционные системы проектировались без учета технологий виртуализации, тогда еще только набиравших обороты. Чтобы нормально запустить такие ОС внутри виртуальной машины необходимо было создать для них иллюзию запуска на физическом компьютере. Как следствие, приходилось эмулировать различное оборудование, как то: BIOS, контроллер прерываний, IDE-контроллер, стандартные порты ввода-вывода и пр. Вы легко увидите перечень эмулируемых устройств, если загляните в Device Manager на ВМ первого поколения.
Эмуляция, с одной стороны, приводит к дополнительным накладным расходам, прежде всего, к лишним тактам процессора, с другой стороны, каждое эмулируемой устройство – дополнительный довольно сложный код, потенциально расширяющий поверхность для атак.
С течением времени ОС стали проектироваться с учетом того, что система может, или даже скорее всего будет работать в виртуальной среде. Такая ОС «знает», что запускается внутри ВМ и, как на этапе загрузки, так и в ходе своей работы, опирается на ресурсы, предоставляемые родительским разделом (хостовой ОС). Иными словами, ОС уже при старте общается с гипервизором через шину VMBus, а не рассчитывает обнаружить контроллер прерываний или чипсет определенного типа. Следовательно, для таких ОС можно отказаться от унаследованных эмулируемых устройств и повысить производительность ВМ. Действительно, в Deviсe Manager ВМ второго поколения картина будет иной.
Отказ от эмуляции устаревших устройств изменяет «начинку» ВМ второго поколения. В свойствах таких ВМ вы увидите примерно следующее:
- Безопасная загрузка (Secure Boot) ВМ. Вместо стандартного BIOS используется firmware на основе спецификации UEFI и как часть этой спецификации поддерживается безопасная загрузка ВМ, что предотвращает возможность поражения ОС при запуске. Secure Boot может быть отключена.
- Загрузка с виртуального SCSI-диска или SCSI-DVD. Виртуальный IDE-контроллер вообще отсутствует в машинах второго поколения.
- «Горячее» изменение размера загрузочного раздела. «Горячее» добавление, а также изменение размера (в том числе, уменьшение) виртуальных SCSI-дисков возможно и для ВМ первого поколения. Но поскольку именно ВМ второго поколения умеют грузиться со SCSI, то для них вы можете изменить размер в том числе загрузочного раздела «на лету».
- Загрузка по сети с использованием синтетического сетевого адаптера проходит быстрее, чем при использовании Legacy Network Adapter в ВМ первого поколения.
В качестве иллюстрации я провел следующий эксперимент: создал две ВМ, первого и второго поколения соответственно, обеим ВМ выделил одинаковое количество оперативной памяти и виртуальных процессоров и одновременно запустил установку Windows Server 2012 R2 внутри созданных ВМ с одного и того же ISO-образа. Вот так выглядела картина в начальной фазе установки (ВМ второго поколения внизу):
И вот такую разницу можно было наблюдать позже:
Таким образом, при развертывании ВМ, а также при старте ВМ, что, например, особенно важно в сценариях VDI, разница в производительности ВМ второго поколения может достигать 50% и более.
Необходимо помнить несколько принципиальных моментов, относящихся к эксплуатации ВМ второго поколения.
- Windows Server 2012
- Windows Server 2012 R2
- 64-битная версия Windows 8
- 64-битная версия Windows 8.1
Вы можете создать ВМ второго поколения в консоли Hyper-V,
либо с помощью командлета PowerShell New-VM, указав ключ –Generation 2.
При этом надо иметь в виду, что поколение указывается только на этапе создания ВМ. В дальнейшем конвертировать ВМ из одного поколения в другое невозможно как раз в силу того, что в одном случае используется BIOS, в другом – UEFI.
Последний аспект, который хотелось бы отметить, связан с управлением. Управление хостами с Windows Server 2012 R2 возможно с помощью System Center 2012 R2 Virtual Machine Manager. В доступной сейчас preview-версии System Center 2012 R2 поддержка второго поколения ВМ отсутствует. Но в RTM-версии System Center 2012 R2 (а она уже не за горами) эта поддержка будет добавлена.
Итак, новое поколение ВМ в Windows Server 2012 R2 лишено устаревших эмулируемых устройств, поддерживает ряд новых возможностей и обеспечивает прирост производительности, особенно на этапах установки и загрузки гостевых ОС. Применение машин второго поколения сейчас сужает перечень поддерживаемых гостевых ОС, однако для остальных систем можно по-прежнему применять ВМ первого поколения, которые прекрасно сосуществуют с ВМ второго поколения на одном хосте виртуализации.
Дополнительную информацию о новых технологиях Windows Server 2012 R2 вы сможете найти на портале MVA в курсе “Jump Start: Все о Windows Server 2012 R2”.
Многие пользователи персональных компьютеров, не подозревают о возможности создания виртуальных машин на их компьютерах, не зная вообще о том, что для того, что бы установить Windows XP, не обязательно переустаналивать его вместо Windows 7, так как создание виртуальных машин, делает возможным запустить виртуальную Windows XP, если возникла потребность в использовании программы, которая не работает с операционными системами Windows версий, позднее версии XP.
Так же как и в Windows, в операционной системе Linux, можно создавать виртуальные среды, для работы с разными версиями ОС, что позволяет вести безопасную работу, во время использовании различных программ.
Уже прошли времена, когда один компьютер, во всей своей комплектации, мог работать только на одной версии, конкретной операционной системы, в одно и то же время.
Нынешние инновации в сфере информационных технологий, в частности, в сфере комплектаций программного обеспечения и комплектующего «железа» к персональному компьютеру, создали возможность собирать невероятно производительные пользовательские ПК.
Благодаря этому, много стало возможным, как к примеру создание нескольких виртуальных сред на одном компьютере.
Рекомендуем обязательному прочтению статьи —здесь
В понятии «виртуальная среда» можно легко спутать виртуальные машины с Windows Server Standart, которая так же является виртуальной машиной, но отличается тем, что позволяет создать не более двух виртуальных сред, для сторонних ОС, так как лицензия от автора, в данном случаи Windows, ограничивает использование и создание виртуальных машин, относительно лицензии, ограничение в размере максимум две виртуальные машины на одну лицензию.
Тогда как на других виртуальных машинах, вроде VirtualBOX, можно создавать от трех и более виртуальных машин.
В силу выше описанного и возникает вопрос о том, «сколько виртуальных машин можно запустить на одном компьютере?». Ответ прост. Одновременно можно запустить неограниченное количество виртуальных машин, но если физической операционной системой является Windows 7, то среди созданных виртуальных машин, только на одной можно установить еще не более одной ОС Windows, в рамках лицензии, а касательно гостевых ОС, ограничений нет.
Таким образом, виртуальная машина, это виртуальный компьютер, устанавливаемый на реальный компьютер. Виртуальная машина используется для работы с небезопасным ПО или с ПО, несовместимым с ОС, установленной на реальном компьютере.
Я много лет использую VMWare, работаю с десятками производственных серверов с очень небольшим количеством проблем. Но я никогда не пытался разместить более 20 виртуальных машин на одном физическом хосте. Вот идея:
Я хотел бы посмотреть, сможет ли кто-нибудь достичь такой масштабируемости с помощью VMWare? Я сделал несколько тестов и столкнулся со странной проблемой. Производительность виртуальной машины начинает резко снижаться после запуска 20 виртуальных машин. В то же время на хост-сервере отсутствуют узкие места в ресурсах (диски простаивают на 99%, загрузка ЦП не достигает 15%, и имеется много свободной оперативной памяти).
Буду признателен, если вы поделитесь своими историями успеха в масштабировании VMWare или любой другой технологии виртуализации!
У вас есть «это количество процессора» на вашем хостинг-сервере, и каждая виртуальная машина получит свою долю. Кроме того, у esxi будут накладные расходы: «переключаться на эту виртуальную машину, управлять ею, переключаться на следующую и т. Д.», Много раз в секунду. Это означает, что каждая виртуальная машина получит лишь небольшую часть от общего процессорного времени. Чем больше виртуальных машин, тем больше вы делите свой процессор (и тем больше накладных расходов вы также добавляете, что означает, что вместо того, чтобы иметь 100 виртуальных машин, у вас на самом деле будет немного больше).
Да, ты можешь. Даже для некоторых рабочих нагрузок Windows 2003 достаточно 384 МБ, поэтому 512 МБ - довольно хорошая оценка, пусть и немного высокая. ОЗУ не должно быть проблемой, как и ЦП.
100 виртуальных машин немного крутые, но это выполнимо, особенно если виртуальные машины не будут очень заняты. Мы легко запускаем 60 серверов (Windows 2003 и RHEL) на одном сервере ESX.
Предполагая, что вы говорите о VMware ESX, вы также должны знать, что может перегружать память. Виртуальные машины практически никогда не используют свой полностью выделенный объем памяти, поэтому ESX может выделять виртуальным машинам больше доступного объема оперативной памяти и запускать больше виртуальных машин, чем у него фактически «официально» есть.
Скорее всего, вашим узким местом будет не CPU или RAM, а IO. VMware может похвастаться огромным количеством операций ввода-вывода в секунду в своем маркетинге, но когда дело доходит до толчка, конфликты резервирования SCSI и ограниченная пропускная способность остановят вас на пути, прежде чем вы приблизитесь к хвастовству IOPS, которое VMware предлагает.
В любом случае, мы не испытываем снижения производительности на 20 ВМ. Какую версию ESX вы используете?
Спасибо Wzzrd! В настоящее время я использую VMWare Server 2.0, но планирую попробовать ESX очень скоро. Я очень внимательно наблюдал за вводом / выводом на всех хост-массивах, и единственный способ, с помощью которого я смог максимизировать его, - это перезагрузить несколько гостей одновременно. Когда гости выполняют легкую рабочую нагрузку или остаются бездействующими, диски хоста на 99% простаивают. Итак, я подозреваю, что что-то кроме CPU и IO вызывает замедление работы всех виртуальных машин. Кстати, они резко замедляются - требуется 20 секунд, чтобы открыть меню «Пуск», и если я запускаю диспетчер задач внутри виртуальной машины, диспетчер задач занимает 90% ЦП - странно!
Это потому, что вы используете VMware Server. VMware Server - это платформа виртуализации поверх другой платформы (чаще всего Linux), в то время как ESX - платформа виртуализации с нуля. Очень разные, как по концепции, так и по тому, как она работает.
К сожалению, когда наступит день патча с 100 виртуальными машинами, вы будете перезагружать большую часть мата в одно и то же время;) И патчить самому сложно. Остерегайтесь пакета обновления - вот когда начинается настоящая боль;)
Хватит дурачить себя, думая, что голый металл - это нечто особенное. ESXi - это просто урезанный Linux. Да, линукс
Одной из основных проблем такой большой среды является предотвращение стихийных бедствий и защита данных. Если сервер умирает, то вместе с ним умирает 100 виртуальных машин.
Вам необходимо спланировать отказоустойчивость виртуальных машин и запланировать управление дополнительными виртуальными машинами, которое защитит виртуальные машины в случае сбоя. Разумеется, такой вид избыточности означает увеличение затрат, и, вероятно, именно поэтому такие затраты часто не утверждаются до тех пор, пока их преимущества не будут видны на практике (из-за их отсутствия).
Помните также, что хост VM является лишь одной из нескольких точек отказа:
- Сеть - что делать, если сетевая карта хоста ВМ выходит из строя?
- Память - что, если часть памяти хоста ВМ испортится?
- CPU - если умирает ядро CPU, что происходит с виртуальными машинами?
- Питание - есть только один - или два - силовых кабеля?
- Порт управления - предположим, вы не можете получить доступ к управлению хостом виртуальной машины?
Это лишь некоторые из них: массивная инфраструктура виртуальных машин требует пристального внимания к предотвращению потери данных и предотвращению потери виртуальных машин.
Нет никаких заявлений о его жизнеспособности в производственном процессе, но есть очень интересная демонстрация NetApp, где они предоставляют рабочие столы 5440 XP на 32 хостах ESX (это 170 на хост) примерно за 30 минут, используя очень мало дискового пространства из-за дедупликации по отношению к обычной виртуальной машине. картинки
Я предполагаю, что ваши ограничения исходят от дисковой подсистемы. Вы, кажется, учли использование памяти и процессора соответственно.
Никогда не делал этого - но я обещаю, что вы потратите гораздо больше, чем на хранилище, чтобы получить достаточное количество IOP для поддержки столько виртуальных машин, сколько вы будете на серверном оборудовании. Вам потребуется много IOP, если все 100 из них активны одновременно. Не звучит негативно, но вы также подумали, что вы кладете много яиц в одну корзину (звучит так, как будто вы выбрали решение с одним сервером?)
Я бы определенно создал несколько «корзин» и настроил несколько автоматических резервных копий. В наши дни узкие места ввода-вывода можно легко устранить с помощью SSD-накопителей. Я использовал диски Intel MLC емкостью 160 ГБ, и они впечатляют. Обычно производительность случайного ввода-вывода в 5 раз выше, чем у лучших дисков SAS (в простых конфигурациях RAID).
Больше всего меня беспокоит конфликт ЦП с 100 ВМ на одном хосте. Вы должны помнить, что процессор НЕ виртуализирован, поэтому каждой машине придется ждать доступа к процессору. Вы можете начать видеть конкуренцию, посмотрев на ESXTOP. Мне сказали, что более 5 в поле% RDY очень плохо для инженеров VMWare.
По своему опыту я видел около 30-40 серверов, работающих на одном хосте (не слишком много).
У меня было 10 хостов на VMWare Server 1.0.6 (под Windows 2003), и он регулярно сталкивался с проблемами ввода-вывода (и если ночные сборки когда-либо перекрывались с чем-то другим, у них были бы проблемы). После обновления с Windows до ESXi U3 мы обнаружили, что наши проблемы с производительностью исчезли (ночные сборки больше не давали ошибок).
Также обратите внимание, что хотя SSD имеют гораздо более высокую скорость ввода-вывода, чем вращающиеся носители, в некоторых случаях это не поддерживается, например, определенные типы шаблонов записи (большое количество небольших записей, разбросанных по диску, снижает производительность, если контроллер не имеет интеллектуальный кэш буферизации записи, который хорошо работает при точечной записи).
Я бы порекомендовал исследовать / протестировать наличие SWAP-файлов на разных дисках, если у вас возникнут проблемы.
Если вы собираетесь это сделать, то настоятельно рекомендую вам использовать новые процессоры Intel Nehalem серии Xeon 55xx - они предназначены для работы виртуальных машин, и их дополнительная пропускная способность памяти также очень поможет. О, и если вы можете использовать больше, меньшие диски, чем несколько, большие, - это очень поможет. Если вы можете использовать ESX v4 более 3.5U4 тоже.
У меня есть 20 виртуальных машин XP с 512 МБ памяти на компьютере с 16 ГБ. Меньше, чем это, и они меняются на диск, и это дает узкое место. Это всегда активные виртуальные машины XP.
VMware и его функция OverCommit должны позволить вам увеличить скорость памяти на каждом компьютере с XP. Аналогичная машина будет использовать одни и те же страницы, что может сократить объем записи на диск. Это то, что я хотел бы изучить для нашей установки, чтобы попытаться добавить больше машин, поскольку наши виртуальные машины XP производят 10-20 мг непрерывного дискового трафика.
Мы не смогли набрать 100 счастливых гостей на сервере VMWare, но потом обнаружили, что ESXi работает намного лучше. Итак, похоже, что 100 XP vms не является проблемой, если вы используете ESXi и приличный сервер (несколько зеркал диска для распределения ввода / вывода, пара микросхем I7 и 64 ГБ ОЗУ). Для конечных пользователей нет видимой задержки, и ресурсы хоста не исчерпаны (самая горячая - это процессор, но обычно она простаивает как минимум на 70%).
PS. Этот вопрос был опубликован мной еще тогда, когда мы боролись с VMWare Server.
В прошлый раз, когда я проверял, VMware рекомендует использовать не более 4 виртуальных машин на каждое ядро обработки для ESX, при этом по одному виртуальному ЦПУ на виртуальную машину
Это предполагает, что накладные расходы менеджмента становятся фактором.
Это предварительная версия ESX 3.5U2 - в файле config для максимальных обновлений 2 указано значение 8, но для рабочих нагрузок VDI этот показатель увеличивается до 11. Я почти уверен, что увидел что-то, чего не могу найти, что увеличило эту рекомендацию VDI до 19 с обновлением 3 или 4. Для vSphere этот предел теперь составляет 20. Поиск максимальных значений конфигурации VMware ESX для официальных документов от VMware.
Мои виртуальные машины большую часть времени простаивают. Люди подключаются, возможно, несколько раз в день, чтобы запустить какое-то легкое программное обеспечение. Я подтвердил, что эти виртуальные машины создают очень небольшую нагрузку на процессор на хосте, когда они простаивают (20 виртуальных машин увеличивают загрузку процессора до 9% на основе двухъядерной системы). Сможете ли вы вспомнить, как оправдано ограничение в 4 ВМ на ЦП? Они думают о веб-серверах или настольных ОС?
Можно ли разделить одну огромную виртуальную машину на несколько физических обычных серверов?
Вот наш вариант использования:
- Нам нужно реализовать 32-процессорный сервер БД с 64 ГБ оперативной памяти.
- У нас нет физического сервера такой мощности
- У нас много серверов с меньшими ресурсами.
Есть ли технология или (лучше) продукт, который позволяет нам использовать эти серверы для создания виртуальной машины с необходимой мощностью? Скажем, можем ли мы объединить 8 физических 4-процессорных машин с 8 ГБ ОЗУ каждая в один 32-процессорный «логический блок» с 64 ГБ ОЗУ и настроить сервер Oracle, который использует всю эту емкость?
Перед публикацией этого вопроса мы читали похожие вопросы, но не нашли ответа.
Может быть, кто-то может дать нам подсказку сейчас?
Это не ответ на ваш вопрос, но странно, что никто не советует смотреть на ограничения программного обеспечения. Если ваша компания разрабатывает приложения для бизнеса среднего бизнеса, мне кажется очевидным, что проблема заключается в ограничениях программного обеспечения, вероятно, архитектор и разработчики программного обеспечения не думали о базе данных с миллиардами записей или огромными временными таблицами или процедурами, подумайте об этом и создайте самотестирование и отчеты об ошибках для медленных запросов, потому что это способ решить проблему . подумайте о пределе 3,3 ГБ в x86
Существует коммерческий продукт от ScaleMP под названием vSMP. Это позволяет объединять несколько систем x86 в один виртуальный экземпляр. Я никогда лично не пробовал это раньше, но я прошел через презентацию от них. Если я правильно помню, существуют определенные требования, чтобы это работало, и вам нужно получить дополнительное оборудование (Infiniband для быстрых межсоединений с малой задержкой). Это может стоить довольно копейки тоже!
ScaleMP не эмулирует среду x86. Вы никогда не получите Windows или любую другую стандартную ОС x86 для работы в виртуальной среде. Вы. Поддерживаются только разные версии Linux, основанные на архитектуре типа SMP. И из этого типа архитектуры . есть несколько вкусов. Даже бесплатные.
ОП не был конкретным в отношении других требований. Я только ответил, что я мог собрать из его / ее поста.
Это выглядит чертовски круто. Я подозреваю, что 32-ядерный процессор (возможно с 2x 16-ядерными чипами AMD) может быть дешевле, чем кластер с Infiniband, но мы идем. Это решение дает больше прав на хвастовство.
Невозможно получить точно такую же функциональность, как один 32-процессорный компьютер . с несколькими отдельными серверами. Лучше всего взглянуть на кластеризацию или грид-компьютинг. Если все сделано правильно, вы можете получить сопоставимую производительность . и более высокий уровень доступности. Многое из вашего вопроса также зависит от вашего типа "дБ". Microsoft SQL Server работает значительно иначе, чем MySQL или Oracle . и масштабируемость также выполняется совершенно иначе.
В качестве альтернативы . вы можете подумать о том, чтобы позволить кому-то сделать базу данных для вас . например, использовать EC2 RDS .
К сожалению, нет никакого способа объединить несколько физических серверов вместе, надеть на них vmware и получить уникальный сверхмощный виртуальный сервер.
The Compomp, спасибо за ответ. Хорошо, если ответ зависит от моего типа базы данных, пусть это будет Oracle или Microsoft SQL Server. С этими исправлениями все еще невозможно? Да, мы знаем о EC2, но нам нужен именно Oracle или Microsoft SQL Server для тестирования проблем с программным продуктом, который мы поставляем для клиента .
Возможность обхода нескольких серверов - ОГРОМНЫЙ кошмар логистики . не говоря уже об отсутствии доступной пропускной способности между устройствами. Подумайте о том, насколько быстрым является процессор . тогда все, что вам нужно будет сделать, это замедлит процесс . то есть процессор -> шина -> PCI-мост -> сетевая карта -> кабель Ethernet -> сеть стек -> . даже до того, как он достиг другого сервера? Вы не хотели бы ждать 1 секунду, чтобы иметь возможность добавить 1 + 1. Кластеры, как правило, могут делать это, потому что задачи назначаются в «Заданиях», и задание выдается вычислительному узлу, который выполняет все задачи в этом задании .
. а затем отправляет ответы обратно на узел управления. Windows не делает. Не существует способа настроить виртуальную среду X86 (или X86_64), которая бы даже пыталась это сделать.
@ user54614 - Вы абсолютно не сможете повторить их сценарий, связав машины вместе. Я бы посоветовал поговорить с вашим клиентом и службой поддержки Oracle, чтобы точно определить и выявить проблемы.
«TheCompWiz» ответил на ваш вопрос с пользой.
Я все еще хотел бы сказать, что да, вы могли бы создать гипервизор, который позволял бы одной виртуальной машине охватывать несколько физических хостов, и она могла бы запускать эту виртуальную машину «правильно», где все функционировало.
Но даже с действительно хорошими высокоскоростными сетями между физическими хостами производительность такого устройства была бы по-настоящему ужасной, если бы она работала намного медленнее, чем небольшая виртуальная машина, которая вписывается в один из этих хостов. Вы должны были бы смоделировать свойства когерентности кэша отдельной виртуальной машины, перехватывая каждую операцию чтения или записи в память, которую выполняли гостевая ОС и приложение, что увеличило бы стоимость доступа к памяти на тысячи, если не на миллионы.
Таким образом, ни один коммерческий поставщик гипервизора не допускает такой возможности. Это было опробовано в лаборатории. Никто не удосужился сделать из него продукт.
Чтобы еще раз подчеркнуть суть, посмотрите на кластеризацию для решения.
Но что делать, если поставляемый нами программный продукт отлично работает для большинства клиентов, но не работает должным образом в среде огромного клиента, который запускает наше приложение на сервере Oracle с 32 процессорами и 64 ГБ ОЗУ. Мы хотим воспроизвести эту неудачу в нашей среде.
Я ничего не знаю о вашем программном обеспечении, но что происходит с 32 процессорами и 64 ГБ оперативной памяти, чего не происходит с 2 процессорами и 8 ГБ оперативной памяти? Если на этом уровне действительно что-то не так, то это проблема Oracle / OS / driver / IO / hardware.
Вы никогда не получите гипервизор для обхода физических машин. Они по-прежнему ограничены физическим ядром машины. При этом . Держу пари, вы могли бы построить архитектуру типа мэйнфреймов, похожую на архитектуру архаичных бегемотов давным-давно . но вы никогда бы не запустили на ней ничего x86.
Ваш огромный клиент должен иметь второй экземпляр QA этого сервера базы данных монстра. Если у них этого нет, то это действительно их проблема. За 15 лет работы в сфере ИТ я никогда не видел, чтобы кто-либо из производителей программного обеспечения дублировал свою инфраструктуру (если только это не является частью контракта на обслуживание, в котором конкретно указывается это, а клиент платит за него). Особенно, когда эта инфраструктура эзотерична (хотя 32-ядерный 64-ГБ сервер может стоить от Dell около 22 тыс. Долл.).
Добрый день! Цель сегодняшней статьи — рассказать о реализации вложенной виртуализации на платформе Hyper-V. Не секрет, что Hyper-V не поддерживал вложенную виртуализацию в отличие от других производителей. С выходом сборки Windows Server 2016 Technical Preview 4 (TP4), которая предназначена для желающих попробовать новый функционал, ситуация изменилась. Демонстрации вложенной виртуализации можно увидеть в записи доклада «Один доклад, один ноутбук, один датацентр» мероприятия Microsoft TechDay 2015.
Все демонстрации были проведены на HP Blade Gen 8, с базовым процессором Intel Xeon E5 2670 и объёмом оперативной памяти 32 GB.
Выбор этой системы был обусловлен желанием показать, насколько невысоким может быть порог вхождения в технологии виртуализации. В общем обычная система по сегодняшним меркам, когда у большинства дома стоят Intel Core i3 и выше, и объем оперативной памяти стартует от 8GB. Это значит, что Вы при необходимости сможете использовать вложенную виртуализацию.
Напомним классический вариант виртуализации. Если у нас есть физический хост с поддержкой технологии виртуализации на уровне чипсета и процессора и включенными в BIOS необходимыми опциями, то получаем следующую картину:
На нулевом уровне здесь физический хост, а на первом уровне — тонкий слой программного обеспечения, называемый гипервизором. Также на первом уровне находится раздел с корневой операционной системой и разделы для виртуальных машин. Проиллюстрируем с использованием утилиты CoreInfo от Марка Руссиновича поведение параметров процессора, связанных с виртуализацией. В таблице приведены первые несколько строк работы утилиты CoreInfo.
До включения роли Hyper-V в операционную систему передавался параметр процессора, связанный с виртуализацией. Это видно по двум строкам в левой части таблицы. Первый параметр — отсутствие гипервизора, второй – флаг, ответственный за виртуализацию. После включения роли гипервизора посмотрим снова на свойства процессора в корневом разделе и увидим следующее: гипервизор включен, и флаг, связанный с виртуализацией, не транслируется в раздел корневой операционной системы. Также обратим внимание на значение Microprocessor signature, которое в нашем случае 0000710 и связано с физическим процессором.
Перейдем ко вложенной виртуализации.
Из рисунка видно, что необходимо пробрасывать флаг, связанный с виртуализацией, в гостевую ОС. То есть, в общем случае, мы должны сообщить гипервизору на первом уровне, что необходимо включить поддержку виртуализации в разделяемом процессоре для виртуальной машины. Для этого необходимо запустить скрипт, который изменяет некоторые свойства виртуальной машины. Одно из основных свойств, которое изменяет скрипт, это поведение процессора виртуальной машины. // Set-VMProcessor -VMName $vmName -ExposeVirtualizationExtensions $true //. Про остальные параметры поговорим чуть позже. Проиллюстрируем поведение параметров процессора, связанных с виртуализацией, на виртуальной машине. В таблице выведены первые несколько строк работы утилиты CoreInfo.
Из таблицы видно, что виртуальная машина «понимает», что работает из-под гипервизора. Но до запуска скрипта флаг, связанный с виртуализацией, не передаётся. Далее отработал скрипт, который изменил свойства нашей виртуальной машины и ее процессора и флаг, связанный с виртуализацией, появился. Далее мы включили роль Hyper-V, после этого возник тонкий слой виртуализации и наша операционная система переместилась в свой корневой раздел, флаг виртуализации исчез. Также обратим внимание на значение Microprocessor signature, которое в нашем случае стало FFFFFFFF, что указывает на виртуализацию процессора. Далее мы создали виртуальную машину внутри виртуальной машины и для чистоты эксперимента запустили утилиту CoreInfo.
В общем-то, ожидаемый результат — присутствие гипервизора и отсутствие флага виртуализации на первом этапе и присутствие флага виртуализации на втором. В итоге имеем вот такое решение.
Спасибо за внимание,
Михаил Комаров
MVP — Cloud and Datacenter Management
Читайте также: