Virtualize intel vt x ept or amd v rvi что это

Виртуализация²

В предыдущей статье я рассказал об Intel VT-x и расширениях данной технологии для увеличения эффективности виртуализации. В этой статье я расскажу о том, что предлагается тем, кому готов сделать ещё один шаг: запускать ВМ внутри ВМ — вложенная виртуализация.

Источник изображения

Итак, ещё раз о том, чего хочется добиться и что стоит на пути к счастью.

Зачем

Теоретическая возможность виртуализации как имитации работы одного компьютера на другом была показана ещё отцами вычислительной техники. Достаточные условия для эффективной, т.е. быстрой виртуализации также были теоретически обоснованы. Практическая их реализация состояла в добавлении специальных режимов работы процессора. Монитор виртуальных машин (назовём его L0) может использовать их для минимизации накладных расходов по управлению гостевыми системами.
Однако, если посмотреть на свойства виртуального процессора, видимого внутри гостевой системы, то они будут отличаться от тех, что имел настоящий, физический: аппаратной поддержки виртуализации в нём не будет! И второй монитор (назовём его L1), запущенный на нём, будет вынужден программно моделировать всю ту функциональность, которую L0 имел напрямую из аппаратуры, значительно теряя при этом в производительности.

Nested virtualization

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

В этом случае на L0 возлагается задача управления гостями как L1, так и L2. Для последних приходится модифицировать контрольные структуры, управляющие переходами между режимами root и non-root, чтобы выход происходил именно в L0. Это не совсем соответствует представлениям L1 о том, что происходит в системе. С другой стороны, как будет показано уже в следующем параграфе статьи, L1 всё равно не имеет прямого контроля над переходами между режимами, и поэтому при правильной реализации плоской структуры никто из гостей не сможет заметить подмены.

Теневые структуры

Нет, это не что-то из области криминала и теории заговора. Прилагательное «теневой» (англ. shadow) для элементов архитектурного состояния постоянно используется во всевозможной литературе и документации по виртуализации. Идея тут в следующем. Обыкновенный GPR (англ. general purpose register) регистр, модифицируемый гостевым окружением, не может повлиять на корректность работы монитора. Поэтому все инструкции, которые работают только с GPR, могут исполняться гостем напрямую. Какое бы значение в нём не сохранилось бы после выхода из гостя, монитор при необходимости всегда может загрузить в регистр новое значение пост-фактум. С другой стороны, системный регистр CR0 определяет в том числе как будут отображаться виртуальные адреса для всех доступов в память. Если бы гость мог записывать в него произвольные значения, то монитор не смог бы работать нормально. По этой причине создаётся тень — копия критичного для работы регистра, хранимая в памяти. Все попытки доступа гостя к оригинальному ресурсу перехватываются монитором и эмулируются, используя значения из теневой копии.
Необходимость программного моделирования работы с теневыми структурами является одним из источников потери производительности работы гостя. Поэтому некоторые элементы архитектурного состояния получают аппаратную поддержку тени: в режиме non-root обращения к такому регистру сразу перенаправляются в его теневую копию.
В случае Intel VT-x [1] как минимум следующие структуры процессора получают тень: CR0, CR4, CR8/TPR (англ. task priority register), GSBASE.

Shadow VMCS

Итак, реализация теневой структуры для некоторого архитектурного состояния в L0 может быть чисто программная. Однако ценой этому будет необходимость постоянного перехвата обращений к нему. Так, в [2] упоминается, что один выход из «non-root» L2 в L1 на вызывает около 40-50 настоящих переходов из L1 в L0. Значительная часть этих переходов вызвана всего двумя инструкциями — VMREAD и VMWRITE [5].

Эти инструкции работают над структурой VMCS (англ. virtual machine control structure), контролирующей переходы между режимами виртуализации. Поскольку напрямую монитору L1 нельзя разрешать её изменять, монитор L0 создаёт теневую копию, а затем эмулирует работу с ней, перехватывая эти две инструкции. В результате время обработки каждого выхода из L2 возрастает значительно.
Поэтому в последующих версиях Intel VT-x VMCS обзавелась теневой копией — shadow VMCS. Эта структура хранится в памяти, имеет аналогичное обычной VMCS содержание и может быть прочитана/изменена с помощью инструкций VMREAD/VMWRITE, в том числе из режима non-root без генерации VM-exit. В результате значительная часть переходов L1 → L0 устраняется. Однако, shadow VMCS не может быть использована для входа/выхода в non-root и root режимы — для этого всё так же используется оригинальная VMCS, управляемая L0.

Shadow EPT

Отмечу, что Intel EPT (англ. Extended Page Table), упомянутая в первой части — это также техника аппаратного ускорения работы с другой теневой структурой, используемой для трансляции адресов. Вместо того, чтобы следить за всем деревом таблиц трансляций гостя (начиная со значения привилегированного регистра CR3) и перехватывать попытки его чтения/модификации, для него создаётся своя собственная «песочница». Настоящие физические адреса получаются после трансляции гостевых физических адресов, что также делается аппаратурой.

В случае вложенной виртуализации, как и в случае с VMCS, мы приходим к той же самой проблеме: теперь уровней трансляции стало три (L2 → L1, L1 → L0 и L0 → физический адрес), но аппаратура поддерживает только два. Это означает, что один из уровней трансляции придётся моделировать программно.

Если моделировать L2 → L1, то, как и следовало ожидать, это приведёт к существенному замедлению работы. Эффект будет даже более значительный, чем в случае одного уровня: каждое исключение #PF (англ. page fault) и запись CR3 внутри L2 будет приводить к выходу в L0, а не в L1. Однако, если заметить [6], что гостевые окружения L1 создаются гораздо реже, чем процессы в L2, то можно сделать программной (т.е. медленной) именно трансляцию L1 → L0, а для L2 → L1 задействовать освободившийся аппаратный (быстрый) EPT. Это напоминает мне идею из области компиляторных оптимизаций: следует оптимизировать самый вложенный цикл кода. В случае виртуализации — это самый вложенный гость.

Виртуализация³: что дальше?

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

А в будущем создателям мониторов ВМ захочется нырнуть ещё глубже — довести рекурсивную виртуализацию до третьего, четвёртого и более глубоких уровней вложенности. Описанные выше приёмы поддержки двух уровней вложенности становятся очень непривлекательными. Я не очень уверен, что те же самые трюки удастся повторить для эффективной виртуализации даже третьего уровня. Вся беда в том, что режим гостя не поддерживает повторного входа в самого себя.
История вычислительной техники напоминает о похожих проблемах и подсказывает решение. Ранний Fortran не поддерживал рекурсивный вызов процедур, потому что состояние локальных переменных (activation record) хранилось в статически выделяемой памяти. Повторный вызов уже исполняющейся процедуры затёр бы эту область, отрезав исполнению выход из процедуры. Решение, реализованное в современных языках программирования, состояло в поддержке стека из записей, хранящих данные вызванных процедур, а также адреса возврата.
Похожую ситуацию мы видим для VMCS — для этой структуры используется абсолютный адрес, данные в ней принадлежат монитору L0. Гость не может использовать эту же VMCS, иначе он рисковал бы затереть состояние хозяина. Если бы у нас был стек или скорее даже двусвязнный список VMCS, каждая последующая запись в котором принадлежала бы текущему монитору (а также всем вышестоящим над ним), то не приходилось бы прибегать к описанным выше ухищрениям по передаче L2 под командование L0. Выход из гостя передавал бы управление его монитору с одновременным переключением на предыдущую VMCS, а вход в режим гостя активировал бы следующую по списку.

Вторая особенность, ограничивающая производительность вложенной виртуализации — это нерациональная обработка синхронных исключений [7]. При возникновении исключительной ситуации внутри вложенного гостя LN управление всегда передаётся в L0, даже если единственная его задача после этого — это «спустить» обработку ситуации в ближайший к LN монитор L(N-1). Спуск сопровождается лавиной переключений состояний всех промежуточных мониторов.

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

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

Тема оптимизаций в виртуализации (да и вообще любых оптимизаций) неисчерпаема — всегда найдётся ещё один последний рубеж на пути к достижению максимальной скорости. В своих трёх заметках я рассказал лишь о некоторых расширениях Intel VT-x и приёмах вложенной виртуализации и полностью проигнорировал остальные. К счастью, исследователи, работающие над открытыми и коммерческими решениями виртуализации, довольно охотно публикуют результаты своей работы. Материалы ежегодной конференции проекта KVM, а также whitepaper’ы компании Vmware — хороший источник информации о последних достижениях. Например, вопрос уменьшения числа VM-exit, вызванных асинхронными прерываниями от устройств, подробно разбирается в [8].

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

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

Печать

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

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

Устройства USB

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

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

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

Отдельного внимания заслуживает опция Show all USB input devices, которая позволяет подключать к виртуальной машине любые USB-устройства ввода, которые по умолчанию скрыты. Это может потребоваться при необходимости работы в гостевой ОС с оборудованием, которое устанавливается в систему как USB устройство ввода, например, сканеры ШК или считыватели магнитных карт.

Дисковые устройства

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

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

Режимы подключения влияют на совместимость диска с различными типами гостевых ОС, по умолчанию рекомендуется IDE режим, который совместим со всеми типами гостевых ОС. SCSI режим совместим также со всеми гостевыми ОС имеющими драйвер LSI Logic или BusLogic SCSI контроллера. SATА режим поддерживается не всеми гостевыми ОС, в ряде случаев загрузка с такого диска будет невозможна.

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

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

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

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

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

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

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

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

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

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

Работа с COM- и LPT-портами

В отличие от устаревшего LPT, COM-интерфейс (RS-232) продолжает широко использоваться в современной технике, сегодня его применение стало стандартом де-факто для различного промышленного и торгового оборудования, встраиваемых систем, систем безопасности т.п. При этом физически устройства могут подключаться к ПК и с помощью иных интерфейсов, например, USB или Bluetоoth, программно эмулируя COM-порт.

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

Наконец третья опция доступна только для COM-портов и позволяет направить их вывод в именованный канал.

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

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

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

Ниже показана успешная эмуляция сканера штрих-кода для 1С:Предприятия

Моментальные снимки (снапшоты)

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

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

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

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

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

Виртуалка в виртуалке

На первый взгляд запуск внутри виртуальной машины еще одного гипервизора лишен особого смысла, в производственной среде это так, но в настольных системах такая потребность возникает весьма часто. Например, нужно смоделировать и протестировать создание отказоустойчивого кластера Hyper-V, не будете же вы выделять под это дело три сервера, когда есть VMWare Workstation?

Наиболее просто запустить в виртуальной среде родной гипервизор VMware ESXi, для этого достаточно при создании новой виртуальной машины выбрать соответствующий тип гостевой системы.

Для других гипервизоров придется повозиться, но ничего сложного нет. Перейдем в настройки виртуального процессора и выберем режим виртуализации Intel-VT/EPT или AMD-V/RVI, а затем разрешим виртуализацию этих инструкций (галочка ниже).

А затем откроем конфигурационный VMX-файл виртуальной машины и добавим туда строку:

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

Ниже показана запущенная в среде Hyper-V гостевая система с Ubuntu Server, которые работают внутри VMWare Workstation.

UEFI вместо BIOS

Начиная с версии 10 виртуального железа VMWare полноценно поддерживает UEFI, однако никаких графических настроек, позволяющих включить этот режим нет. Для того чтобы использовать UEFI вместо BIOS добавьте (или измените) в VMX-файл опцию:

Запускаем виртуальную машину и убеждаемся, что вместо BIOS используется UEFI.

Теперь можем устанавливать поддерживающие эту технологию гостевые ОС, следует также отметить, что в данной версии VMWare Workstation технология Secure Boot не поддерживается.

Источник