Изменение XML-описания виртуальной машины
XML-описание передаётся libvirt при создании и редактировании виртуальной машины. На последнем этапе перед передачей XML в libvirt выполняется обработчик editxml. Добавив плагин на данный обработчик, можно изменять XML-описание виртуальной машины. В VMmanager внесённые изменения учитываются.
Входные параметры обработчика:
XML для libvirt находится в теге «/doc/outxml». VMmanager также считает XML из тега «/doc/outxml».
Пример обработчика
Задача
Необходимо добавить в XML тэги «pm» (Power Management).
Также необходимо для шаблона ОС с именем «SlitazOs» найти все виртуальные диски типа «block» и изменить тип кэширования на «writeback».
Решение
Нужно создать файл описания обработчика и сохранить его в директорию /usr/local/mgr5/etc/xml.
Файл /usr/local/mgr5/etc/xml/vmmgr_mod_pm.xml:
Нужен скрипт editxml_pm.py, который должен находиться в /usr/local/mgr5/addon.
Файл /usr/local/mgr5/addon/editxml_pm.py:
Для файла /usr/local/mgr5/addon/editxml_pm.py установите права на запуск:
После этого перезапустите VMmanager:
При запуске VMmanager в логе vmmgr.log должна появиться строка:
Наличие данной строки означает, что плагин готов к обработке. Теперь при любом редактировании виртуальной машины плагин отработает и изменит соответствующим образом XML-описание виртуальной машины.
Перегенерирование XML-описания виртуальной машины, без редактирования в панели управления, выполняется с помощью команды:
Где находится xml файл виртуальной машины
OracleВ® VM VirtualBox
Administrator’s Guide for Release 6.0
3.1.В Where Oracle VM VirtualBox Stores its Files
In Oracle VM VirtualBox, a virtual machine and its settings are described in a virtual machine settings file in XML format. In addition, most virtual machines have one or more virtual hard disks. These are typically represented by disk images, such as those in VDI format. The location of these files may vary, depending on the host operating system. See Section 3.1.1, “The Machine Folder”.
Global configuration data for Oracle VM VirtualBox is maintained in another location on the host. See Section 3.1.2, “Global Settings”.
3.1.1.В The Machine Folder
As an example, when you create a virtual machine called «Example VM», Oracle VM VirtualBox creates the following:
In the machine folder, a settings file: Example VM.vbox
You can change the default machine folder by selecting Preferences from the File menu in the Oracle VM VirtualBox main window. Then, in the displayed window, click on the General tab. Alternatively, use the VBoxManage setproperty machinefolder command. See VBoxManage setproperty.
3.1.2.В Global Settings
In addition to the files for the virtual machines, Oracle VM VirtualBox maintains global configuration data in the following directory:
Oracle VM VirtualBox creates this configuration directory automatically, if necessary. You can specify an alternate configuration directory by either setting the VBOX_USER_HOME environment variable, or on Linux or Oracle Solaris by using the standard XDG_CONFIG_HOME variable. Since the global VirtualBox.xml settings file points to all other configuration files, this enables switching between several Oracle VM VirtualBox configurations.
3.1.3.В Summary of Configuration Data Locations
The following table gives a brief overview of the configuration data locations on an Oracle VM VirtualBox host.
TableВ 3.1В Configuration File Locations
Setting
Location
Default machines folder
Default disk image location
In each machine’s folder
Machine settings file extension
Each machine settings file
Media registration is done automatically when a storage medium is attached to a VM
3.1.4.В Oracle VM VirtualBox XML Files
All Oracle VM VirtualBox XML files are versioned. When a new settings file is created, for example because a new virtual machine is created, Oracle VM VirtualBox automatically uses the settings format of the current Oracle VM VirtualBox version. These files may not be readable if you downgrade to an earlier version of Oracle VM VirtualBox. However, when Oracle VM VirtualBox encounters a settings file from an earlier version, such as after upgrading Oracle VM VirtualBox, it attempts to preserve the settings format as much as possible. It will only silently upgrade the settings format if the current settings cannot be expressed in the old format, for example because you enabled a feature that was not present in an earlier version of Oracle VM VirtualBox.
In such cases, Oracle VM VirtualBox backs up the old settings file in the virtual machine’s configuration directory. If you need to go back to the earlier version of Oracle VM VirtualBox, then you will need to manually copy these backup files back.
We intentionally do not document the specifications of the Oracle VM VirtualBox XML files, as we must reserve the right to modify them in the future. We therefore strongly suggest that you do not edit these files manually. Oracle VM VirtualBox provides complete access to its configuration data through its the VBoxManage command line tool, see VBoxManage and its API, see ChapterВ 4, Oracle VM VirtualBox Programming Interfaces.
Copyright В© 2004, 2020 Oracle and/or its affiliates. All rights reserved. Legal Notices
Каталог хранилища файлов виртуальных машин KVM
Способ 1: Virt-Manager GUI
Клик правой клавишей мыши на соединении, выбираем » Детали » («Свойства соединения»)
Переходим на вкладку » Хранилище «, где в левой части «окна» выбираем » default «, а в нижней части «окна» жмём » Остановить пул » и потом » Удалить пул » (не переживайте, после удаления пула файлы образов останутся на своём месте 🙂
Нажимаем » Добавить пул » с параметрами » Название » = » default » и » Тип » = » dir: Каталог файловой системы «
На следующем шаге изменяем » Путь к приёмнику: » и нажимаем » Завершить «
Способ 2: Программа коммандной строки Virsh
Теперь откроем файл в любом удобном для нас редакторе и изменим путь в элементе
на тот, который нам нужен:
Удалим текущий пул с именем default:
Создадим новый изуже обновлённого дампа pool.xml:
Рекомендуемый контент
А тут же ж мог быть рекомендуемый контент от гугла 🙂 Для отображения рекомендуемого контента необходимо в браузере разрешить выполнение JavaScript скриптов, включая скрипты с доменов googlesyndication.com и doubleclick.net
Вы не любите рекламу!? Напрасно!:) На нашем сайте она вовсе ненавязчивая, а потому для нашего сайта можете полностью отключить AdBlock (uBlock/uBlock Origin/NoScript) и прочие блокировщики рекламы! AdBlock/uBlock может препятствовать нормальной работе системы поиска по сайту, отображению рекомендуемого контента и прочих сервисов Google. Рекомендуем полностью отключить блокировщик рекламы и скриптов, а также разрешить фреймы (aka iframe).
Управление виртуальными машинами KVM из консоли
В предыдущей статье мы рассмотрели установку гипервизора KVM и создание виртуальной машины. В рамках одной статьи, мы не смогли охватить все нюансы управления виртуальными машинами, а затронули лишь их часть. Сегодня, мы постараемся рассказать все об управлении виртуальными машинами из консоли сервера: как изменить параметры ВМ, добавить дополнительные устройства и рассмотрим основные команды, которые используются для администрирования виртуальных машин KVM.
Virsh: команды управления виртуальной машиной KVM
Первый вопрос, который возникает у начинающего администратора KVM: как увидеть созданные виртуальные машины, как остановить, запустить и удалить их. Для управления ВМ в KVM из консоли можно использовать утилиту virsh (использует libvirt API). С помощью утилиты virsh можно выполнить практически все операции с виртуальными машинами KVM.
# virsh list – показать список запущенных ВМ
Как видно из скриншота, в первом случае отключенная ВМ не была отображена.
# virsh shutdown — выключить виртуальную машину
# virsh start — запустить виртуальную машину
# virsh suspend — приостановить виртуальную машину
# virsh resume — запустить приостановленную виртуальную машину
# virsh reboot — перезапустить виртуальную машину
# virsh destroy — уничтожить виртуальную машину
# virsh undefine — удалить машину из списка и удалить все файлы, принадлежащие ей (обычно применяется после выполнения команды virsh destroy).
# virsh vcpuinfo — информация о процессоре на виртуальной машине (информацию о железе физического Linux сервера можно получить так)
Еще несколько команд по получению различной информации о виртуальной машине:
# virsh domid — получить идентификатор виртуальной машины
# virsh domuuid — получить UUID виртуальной машины
# virsh dominfo — получить сведения о виртуальной машине
# virsh domstate — просмотр состояния виртуальной машины
# virsh dumpxml — вывести файл конфигурации указанной виртуальной машины в XML формате
Добавление памяти и vCPU виртуальной машине KVM
В консоли KVM вы можете добавить или уменьшить ресурсы процессора и памяти, выделенные для ВМ двумя способами:
Если виртуальная машина запущена, ее нужно остановить:
# virsh shutdown test-centos
Теперь с помощью virsh изменим количество виртуальных процессоров до 6 (vCPU):
— количество ядер процессора
Но при применении этой команды, у меня сразу же появилась ошибка:
Мы не можем установить количество ядер процессора, больше, чем максимальное количество. Чтобы увеличить максимальное количество ядер ВМ, выполните команду:
Повторите первую команду и запустите виртуальную машину:
Проверим количество процессоров в настройках ВМ: овленное количество процессоров:
# virsh dumpxml test-centos
Аналогичным образом добавим память виртуальной машине:
Все по той же причине, сразу же вышла ошибка:
Увеличим максимальное значение памяти::
Теперь можно увеличить память ВМ.
Перед всеми изменениями не забывайте останавливать ВМ, а после запускать ее.
Также вы можете изменить ресурсы ВМ KVM через ее конфигурационный XML файл. Можно изменить файл в режиме онлайн или же сделав бэкап XML файла ВМ, изменить его и применить к виртуальной машине.
Отредактируем XML файл ВМ в онлайн режиме:
В открывшемся редакторе vi внесите изменения, нажав кнопку “Insert”.
Например, зададим для ВМ 2 ядра и 1Гб памяти:
Сохраните изменения в файле и перезапустите ВМ:
Проверьте настройки ВМ:
Тоже самое можно сделать, сделав бэкап XML файла:
# virsh dumpxml > /root/test.xml
# vi /root/test.xml
Измените нужные вам параметры, сохраните файл и примените к виртуальной машине:
# virsh shutdown test-centos
# virsh define /root/test.xml
# virsh start test-centos
KVM: добавление диска в виртуальную машину
В одной из наших статей, мы описывали процесс расширения и уменьшения дисков виртуальных машин в KVM. Но мы не описывали вариант по добавлению дополнительного диска.
Сначала нужно создать дополнительный файл диска для виртуальной машины:
Вместо qcow2 вы можете указать нужный формат диска, так же нужно указать путь до файла. У меня хранилище для дисков /vz/disk/.
После этого, можно добавить устройство виртуального диска к самой ВМ:
Остановите и запустите ВМ, проверьте что получилось:
# virsh shutdown test-centos
# virsh start test-centos
# virsh dumpxml test-centos
Как видим, диск добавлен. После данных манипуляций, на виртуальной машине нужно разметить этот диск под ваши нужды.
KVM: добавление сетевой карты для виртуальной машины
Попрьуем добавить дополнительный сетевой интерфейс для ВМ. Сначала проверим, какие сетевые интерфейсы созданы на хосте:
У меня на KVM сервере создана одна виртуальная машина, с одним сетевым интерфейсом. К br0 нам нужно прикрепить еще один виртуальный сетевой интерфейс. Выполните команды:
Проверьте, что у ВМ появился дополнительный сетевой интерфейс:
Также вы можете изменить сетевые настройки виртуальной машины напрямую через XML файл: # virsh edit test-centos
После первого сетевого интерфейса добавьте следующие строки:
Сохраните файл и запустите ВМ. Остальную конфигурацию, KVM добавит сам (mac address и тд).
В данной статье мы затронули основные моменты, которые могут вам понадобиться при управлении виртуальными машинами KVM из консоли Linux сервера. В следующей статье мы рассмотрим управление виртуальными машинами через графический менеджер virt-manager.
Где находится xml файл виртуальной машины
Где VirtualBox хранит свои файлы
Виртуальная машина и ее настройки описываются файлом настроек в формате XML. Кроме этого, большинство виртуальных машин имеют один или несколько виртуальных жестких дисков, которые обычно представлены образом диска (например, в формате VDI). Место, где все эти файлы хранятся зависит от версии VirtualBox в которой создали машину.
Машины, созданные VirtualBox версии 4.0 или более поздней
По умолчанию, это «машинная папка» помещается в общую директорию под названием «VirtualBox VMs», которую VirtualBox создает в домашнем каталоге текущего пользователя системы. Расположение этого домашнего каталога зависит от настроек операционной системы хоста:
Например, при создании виртуальной машины под названием «Example VM», VirtualBox создает
файла настроек Example VM.vbox и
Машины, созданные до версии VirtualBox 4.0
Если вы перешли на VirtualBox 4.0 c более ранней версии, то параметры ваших файлов и дисков в расположены в других местах файловой системы.
Старая схема имела несколько серьезных недостатков.
Для перемещения машины на другой хост, было не достаточно переместить XML файл настроек, а образы дисков (которые были в разных местах), но правильно скопированы записи из глобальных реестр, а также, было почти невозможно, если машина имела снимки и файлы разностных образов.
Новые виртуальные машины, созданные в VirtualBox 4.0 или более поздней будет соответствовать новый схеме, а для максимальной совместимости, старые виртуальные машины не преобразуются в новую схему. В противном случае настройки машины будут безвозвратно потеряны, если пользователь с версии старше 4.0 перейти к более ранней версии VirtualBox.
Глобальные данные конфигурации
До версии VirtualBox 4.0, все виртуальные устройства хранения (файлы образов диска) также были включены в глобальный реестр этого файла настройки. Для совместимости, этот реестр устройств хранения(носителей) все еще существует в обновленных версиях VirtualBox, где есть носители из машин, которые были созданы до версии 4.0. Если у вас нет таких машин, то файл глобального реестра не создается; с VirtualBox 4.0, каждый файл настроек машины имеет свой собственный реестр носителей.
Обзор изменения в конфигурации 4.0
Таблица 10.1. ignoreme
| До 4.0 | 4.0 или выше | |
| Папка машин по умолчанию | $HOME/.VirtualBox/Machines | $HOME/VirtualBox VMs |
| Расположение образа диска | $HOME/.VirtualBox/HardDisks | В папке каждой машины |
| Расширение файла настроек машины | .xml | .vbox |
| Реестра носителей | Глобальный VirtualBox.xml файл | Каждый файл настройки машины |
| Media registration | Требуется явнре открытие / закрытие | Автоматическое подключение |
XML файлы VirtualBox
Все VirtualBox XML файлы помчаются номером версии. При создании нового файла настройки создается (например, при создании новой виртуальная машина), VirtualBox автоматически использует настройки схемы текущей версии VirtualBox. Эти файлы могут не читаться, если вы откатитесь на более раннюю версию VirtualBox. Однако, когда VirtualBox читает файл настроек более ранней версии (например, после обновления VirtualBox), то он попытается считать настройки с максимальной возможностью сохранения данных. Если текущие настройки не могут сохраниться в старом формате,например потому что вы включили функционал который не был представлен в более ранней версии VirtualBox, то произойдет обновление схемы хранения настроек. [40] В таких случаях, VirtualBox создает резервную копию старого файла настройки в каталоге настроек виртуальной машины. Если вам нужно вернуться к более ранней версии VirtualBox, то вам нужно будет вручную скопировать эти резервные файлы обратно.
Исполняемые файлы и компоненты VirtualBox
VirtualBox был разработан, с целю быть модульным и гибким. При открытие графического интерфейса пользователя (GUI) VirtualBox и запуске ВМ, то выполняются как минимум три процесса:
Примечание
Любой клиент VirtualBox будет общаться с процессом обслуживания и может управлять и отображать текущие изменениями состояний. Например, окно ВМ или VBoxManage можно использовать для приостановки выполнения ВМ, а другие компоненты, всегда будет получать его изменившиеся состояние.
The VirtualBox GUI application is only one of several available front ends (clients). Полный список поставляемых с VirtualBox клиентов:
VirtualBox Python shell, Python альтернатива VBoxManage. Описано так же в SDK.
Внутренне, VirtualBox состоит из множества более или менее обособленных компонент. Вы можете столкнуться с ними при просмотре сообщений об ошибках VirtualBox и в лог-файлах. К ним относятся:
IPRT, кросс-платформенная runtime библиотека, которая предоставляет интерфейс доступа к файлам, потокам, обработке строк и т.д. Всякий раз, когда VirtualBox обращается к функционалу хоста, он делает это через эту библиотеку. что позволяет ему работать на различных ОС.
VMM (Virtual Machine Monitor), «сердце» гипервизора.
EM (Execution Manager), контролирует исполнение кода гостя.
REM (Recompiled Execution Monitor), обеспечивает программную эмуляцию инструкций процессора.
TRPM (Trap Manager), перехватывает и обрабатывает гостя Trap(ловушки) и исключения.
HWACCM (Hardware Acceleration Manager), обеспечивает поддержку VT-X и AMD-V.
PDM (Pluggable Device Manager), абстрактный интерфейс между VMM и эмулируемым устройством, которое отделяет реализацию устройства от VMM системы и позволяет легко добавлять новые эмулируемые устройства. Через PDM, сторонние разработчики могут добавлять новые виртуальные устройства для VirtualBox без необходимости изменения самого VirtualBox.
PGM (Page Manager), компонент управления памятью.
PATM(Patch Manager), модуль модификации кода гостя для улучшения и ускорения виртуализации.
TM (Time Manager), обработчики таймеров и все связаное с работой с временем в гостях.
CFGM (Configuration Manager), предоставляет древовидную структуру которая содержит параметры конфигурации виртуальной машины и все эмулируемые устройства.
SSM (Saved State Manager), сохраняет и загружает состояние ВМ.
VUSB (Virtual USB), слой, который отделяет эмулируемые USB контроллеры от контроллеров USB устройств на хосте и который также предоставляет интерфейс удаленных устройств USB.
DBGF (Debug Facility), встроенный отладчик VM.
Специальный компонент «Main» : он связывает все перечисленные выше элементы вместе и реализует единственный общедоступный API. Все клиенты перечисленных выше систем используют только этот API и никогда не получают прямой доступ к компонентам гипервизора. В результате, сторонние приложения, использующие VirtualBox Main API могут рассчитывать на то, что данный интерфейс хорошо проверен и, что им будут доступны все возможности VirtualBox. Именно этот API, упомянутый выше, описан в VirtualBox SDK(опять же, см. главу 11, Программный интерфейс VirtualBox ).
Аппаратная виртуализации против программной
К сожалению, платформы x86, никогда не была расчитана на виртуализацию. Обнаружение ситуаций, в которых VirtualBox необходимо брать контроль над гостевым кодом, является трудной задачей. Существует два способа, чтобы достигнуть этого:
С 2006 года Intel и AMD процессоры имеют поддержку так называемой «аппаратной виртуализации». Это означает, что эти процессоры могут помочь VirtualBox перехватывать потенциально опасные операций, которые гостевая операционная система может пытаться выполнить, а также упрощает предоставление виртуального оборудование в виртуальную машину.
Примечание
На многих системах, функцию аппаратной виртуализации необходимо включить в BIOS перед началом использования ее в VirtualBox.
В отличие от других систем виртуализации, в большинстве случаев, VirtualBox не требует аппаратной виртуализации. Посредством сложных методов, виртуализации многих гостевых операционных систем полностью обеспечивается программном способом. Это означает, что вы можете запускать виртуальные машины даже на старых процессорах, которые не поддерживают аппаратную виртуализацию.
Даже при том, что VirtualBox не всегда требует аппаратной виртуализации, но она необходима в следующих случаях:
Некоторые редкие гостевые ОС, такие как OS / 2, используют скрытые инструкций процессора, которые не поддерживаются нашим программным обеспечением. Для виртуальных машин, которые настроены для использования подобной операционной системы, аппаратная виртуализация включается автоматически.
64-битные гостевые (добавлено в версии 2.0) и многопроцессорные системы (SMP, добавлена с версии 3.0) требуют аппаратной виртуализации. (Это не так много критично, так как подавляющее большинство сегодняшних 64-битных и многоядерных процессоровы имеют аппаратную виртуализацию; исключением из этого правила являются, например, старые Intel Celeron и процессоры AMD Opteron.)
Предупреждение
Не запускайте других гипервизоров (с открытым исходным кодом или коммерческих продуктов ) вместе с VirtualBox! Хотя несколько гипервизоров обычно могут быть установлены параллельно, не пытайтесь запускать несколько виртуальных машин в конкурирующих гипервизорах в одно и то же время. VirtualBox не может отслеживать работу другого гипервизор на том же хосте, и особенно, если несколько продуктов используют функции аппаратной виртуализацию, например, таких как VT-х, это может привести к краху хоста. Кроме того, в VirtualBox, вы можете смешать программную и аппаратную виртуализацию при запуске нескольких виртуальных машин. В некоторых случаях наблюдается небольшое снижение производительности при одновременном использовании VT-х и программной виртуализации. Мы рекомендуем не смешиваясь режимы виртуализации, когда требуется максимальная производительность и низкие накладные расходы являются. Однако, это не относится к AMD-V.
Подробнее о программной виртуализации
Реализация виртуализации на x86 процессорах без поддержки аппаратной виртуализации является чрезвычайно сложной задачей, потому что архитектура этих процессоов не предназначена для для виртуализации. Эту проблему можно решенить, но ценой снижения производительности. Таким образом, происходит постоянное столкновение между производительностью виртуализальной среды и точности ее работы.
В теории, программная виртуализации не очень сложна. В дополнение к четырем аппаратным уровням привилегий («кольца»,»rings») (из которых обычно используются только два : кольцо 0 для режима ядра и кольца 3 для пользовательского режима), необходимо выделить «контекст хоста» и «контекст гостя».
In «host context», everything is as if no hypervisor was active. This might be the active mode if another application on your host has been scheduled CPU time; in that case, there is a host ring 3 mode and a host ring 0 mode. The hypervisor is not involved.
В «гостевом контексте» выполняются виртуальные машины. Пока код гостя выполняется в кольце 3, это не такая уж большая проблема, так как гипервизор может установить правильны таблицы страниц и выполнять этот код на физическом процессоре. Проблемы появляются когда нужно перехватить работу кода на уровне ядра гостя.
Есть несколько возможных решений этих проблем. Одним из подходов является полная программная эмуляция, как правило, с помощью перекомпиляции. То есть, весь машинный код гостя анализируется, преобразуется в форму, которая позволят скрыть от гостя и не позволяет изменить ему состояние процессора, и только затем этот измененный код выполняется. Данный метод весьма сложный и дорогостоящий с точки зрения производительности. (В состав VirtualBox входит такой перекомпилятор на основе QEMU, который может использоваться для полной программной эмуляции, но он активируется только в особых случаях, описанных ниже.)
Guest ring 3 code is run unmodified, at full speed, as much as possible. The number of faults will generally be low (unless the guest allows port I/O from ring 3, something we cannot do as we don’t want the guest to be able to access real ports). This is also referred to as «raw mode», as the guest ring-3 code runs unmodified.
For guest code in ring 0, VirtualBox employs a nasty trick: it actually reconfigures the guest so that its ring-0 code is run in ring 1 instead (which is normally not used in x86 operating systems). As a result, when guest ring-0 code (actually running in ring 1) such as a guest device driver attempts to write to an I/O register or execute a privileged instruction, the VirtualBox hypervisor in «real» ring 0 can take over.
The hypervisor (VMM) can be active. Every time a fault occurs, VirtualBox looks at the offending instruction and can relegate it to a virtual device or the host OS or the guest OS or run it in the recompiler.
In particular, the recompiler is used when guest code disables interrupts and VirtualBox cannot figure out when they will be switched back on (in these situations, VirtualBox actually analyzes the guest code using its own disassembler). Also, certain privileged instructions such as LIDT need to be handled specially. Finally, any real-mode or protected-mode code (e.g. BIOS code, a DOS guest, or any operating system startup) is run in the recompiler entirely.
Unfortunately this only works to a degree. Among others, the following situations require special handling:
Running ring 0 code in ring 1 causes a lot of additional instruction faults, as ring 1 is not allowed to execute any privileged instructions (of which guest’s ring-0 contains plenty). With each of these faults, the VMM must step in and emulate the code to achieve the desired behavior. While this works, emulating thousands of these faults is very expensive and severely hurts the performance of the virtualized guest.
There are certain flaws in the implementation of ring 1 in the x86 architecture that were never fixed. Certain instructions that should trap in ring 1 don’t. This affect for example the LGDT/SGDT, LIDT/SIDT, or POPF/PUSHF instruction pairs. Whereas the «load» operation is privileged and can therefore be trapped, the «store» instruction always succeed. If the guest is allowed to execute these, it will see the true state of the CPU, not the virtualized state. The CPUID instruction also has the same problem.
A hypervisor typically needs to reserve some portion of the guest’s address space (both linear address space and selectors) for its own use. This is not entirely transparent to the guest OS and may cause clashes.
The SYSENTER instruction (used for system calls) executed by an application running in a guest OS always transitions to ring 0. But that is where the hypervisor runs, not the guest OS. In this case, the hypervisor must trap and emulate the instruction even when it is not desirable.
The CPU segment registers contain a «hidden» descriptor cache which is not software-accessible. The hypervisor cannot read, save, or restore this state, but the guest OS may use it.
Some resources must (and can) be trapped by the hypervisor, but the access is so frequent that this creates a significant performance overhead. An example is the TPR (Task Priority) register in 32-bit mode. Accesses to this register must be trapped by the hypervisor, but certain guest operating systems (notably Windows and Solaris) write this register very often, which adversely affects virtualization performance.
To fix these performance and security issues, VirtualBox contains a Code Scanning and Analysis Manager (CSAM), which disassembles guest code, and the Patch Manager (PATM), which can replace it at runtime.
Before executing ring 0 code, CSAM scans it recursively to discover problematic instructions. PATM then performs in-situ patching, i.e. it replaces the instruction with a jump to hypervisor memory where an integrated code generator has placed a more suitable implementation. In reality, this is a very complex task as there are lots of odd situations to be discovered and handled correctly. So, with its current complexity, one could argue that PATM is an advanced in-situ recompiler.
In addition, every time a fault occurs, VirtualBox analyzes the offending code to determine if it is possible to patch it in order to prevent it from causing more faults in the future. This approach works well in practice and dramatically improves software virtualization performance.
Подробнее об аппаратной виртуализации
В Intel VT-х существуют два различных режима работы CPU: VMX root(обычный) режиме и non-root(виртуализированный) режиме.
В root режиме процессор работает так же, как старшие поколения процессоров без VT-X поддержки. В нем существуют четыре уровня привилегий («колец») и поддерживается тот же набор инструкций процессора, с добавлением нескольких инструкций виртуализации. Root mode is what a host operating system without virtualization uses, and it is also used by a hypervisor when virtualization is active.
В non-root режиме, процессорные операции значительно отличаются. Имеются те же четыре кольца привилегий и тот же набор инструкций, но появляется новая структура под названием VMCS (Virtual Machine Control Structure) контролирущая работу CPU. В Non-root режиме выполняется гостевая ОС.
Операция переключение из root режима в non-root режим называется «VM вход», обратная операция «VM выход». VMCS хранит состояния гостевой системы и хоста, которые сохраняются при сменах режима. Самое главное здесь, что структуры VMCS хранит информацию о том какие гостевые операции вызовет событие VM выход.
VMCS предоставляет достаточно полный контроль за тем, что могут и не могут делать гостевые системы. Например, гипервизор может разрешить гостевой писать данные в одни регистры управления, а другие нет. Это обеспечивает эффективную виртуализацию, когда гости могут изменять регистры состояние системы, не нарушая работу гипервизора и предотвращая их от изменения регистров состояния системы над которыми гипервизора должен сохранить полный контроль. VMCS также обеспечивает контроль за прерываниями и исключениями.
Всякий раз, когда выполняется команда или событие, которое приводит к VM выходу, VMCS содержит информацию о причине выхода. Например, если запись в регистре CR0 вызывает выход, то регистрируется инструкция «нарушитель», а также информация о источнике и целевом регистре и т.п.. Таким образом, гипервизор может эффективно обрабатывать состояние системы без использования технологий CSAM и PATM описаных выше.
VT-X изначально избегает несколько проблем, с которыми сталкивается программная виртуализация. Гость имеет свое совершенно отдельное адресное пространство не используеемое совместно с гипервизором, что устраняет возможные конфликты. Additionally, guest OS kernel code runs at privilege ring 0 in VMX non-root mode, obviating the problems by running ring 0 code at less privileged levels. For example the SYSENTER instruction can transition to ring 0 without causing problems. Naturally, even at ring 0 in VMX non-root mode, any I/O access by guest code still causes a VM exit, allowing for device emulation.
Основное отличие VT-X и AMD-V в том, что AMD-V обеспечивает более полную виртуализацию среды. VT-x requires the VMX non-root code to run with paging enabled, which precludes hardware virtualization of real-mode code and non-paged protected-mode software. This typically only includes firmware and OS loaders, but nevertheless complicates VT-x hypervisor implementation. AMD-V does not have this restriction.
Конечно аппаратная виртуализация не является совершенной. По сравнению с программной виртуализацией, накладные расходы на обработку VM выходов относительно высоки. Это создает проблемы для эмуляции устройств, которая требует создания большого количества обработчиков. One example is the VGA device in 16-color modes, where not only every I/O port access but also every access to the framebuffer memory must be trapped.
Nested paging and VPIDs
В дополнение к «простой» аппаратной виртуализации, процессор может также поддерживать дополнительные технологии: [ 41 ]
Новая функцию под названием «nested paging» реализует управления памятью на аппаратном уровне, которая может значительно ускорить аппаратную виртуализацию, так как эту задачу больше не нужно выполнять программе виртуализации.
With nested paging, the hardware provides another level of indirection when translating linear to physical addresses. Page tables function as before, but linear addresses are now translated to «guest physical» addresses first and not physical addresses directly. A new set of paging registers now exists under the traditional paging mechanism and translates from guest physical addresses to host physical addresses, which are used to access memory.
Nested paging eliminates the overhead caused by VM exits and page table accesses. In essence, with nested page tables the guest can handle paging without intervention from the hypervisor. Nested paging thus significantly improves virtualization performance.
На процессорах Intel, функция под названием «Virtual Processor Identifiers» (VPIDs) может значительно ускорить переключение контекста за счет снижения потребности в дорогостоящей операции Translation Lookaside Buffers (TLBs).
[40] As an example, before VirtualBox 3.1, it was only possible to enable or disable a single DVD drive in a virtual machine. If it was enabled, then it would always be visible as the secondary master of the IDE controller. With VirtualBox 3.1, DVD drives can be attached to arbitrary slots of arbitrary controllers, so they could be the secondary slave of an IDE controller or in a SATA slot. If you have a machine settings file from an earlier version and upgrade VirtualBox to 3.1 and then move the DVD drive from its default position, this cannot be expressed in the old settings format; the XML machine file would get written in the new format, and a backup file of the old format would be kept.
[41] VirtualBox 2.0 added support for AMD’s nested paging; support for Intel’s EPT and VPIDs was added with version 2.1.