Меню

Где находится диск виртуальной машины

Где находится диск виртуальной машины

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

Где VirtualBox хранит свои файлы

Виртуальная машина и ее настройки описываются файлом настроек в формате XML. Кроме этого, большинство виртуальных машин имеют один или несколько виртуальных жестких дисков, которые обычно представлены образом диска (например, в формате VDI). Место, где все эти файлы хранятся зависит от версии VirtualBox в которой создали машину.

Машины, созданные VirtualBox версии 4.0 или более поздней

Начиная с версии 4.0, каждая виртуальная машина имеет одну директорию на хосте, где хранятся все файлы этой машины — файл XML настроек (с расширение файла .vbox ) и образов дисков.

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

В Windows, это %HOMEDRIVE%%HOMEPATH% ; обычно что-то типа C:\Documents and Settings\Username\ .

В Mac OS X, это /Users/username .

В Linux и Solaris, это /home/username .

Для простоты, мы будем далее упоминать этот каталога как $HOME . По этому соглашению, общей папкой для всех виртуальных машин будет $HOME/VirtualBox VMs .

Например, при создании виртуальной машины под названием «Example VM», VirtualBox создает

папку $HOME/VirtualBox VMs/Example VM/ и, в этой папке,

файла настроек Example VM.vbox и

виртуальный образ диска Example VM.vdi .

Данная схема применяется по умолчанию, при использовании мастера создания виртуальных машин, который описывался в разделе «Создание вашей первой виртуальной машины» . Как только вы начинаете работать с ВМ, будут созданы дополнительные файлы : вы найдете файлы журналов в подкаталоге Logs , а при создании снимков состояний, они будут сохраняться в вложенную папку Snapshots . Для каждой виртуальной машины, вы можете изменить в настройках расположение папки снимков.

Вы можете изменить папку для машин по умолчанию, выбрав «Настройки» в меню «Файл» в основного окна VirtualBox . Затем, в появившемся окне, выберете вкладку «Общие». Так же вы можете использовать VBoxManage setproperty machinefolder , см. раздел «VBoxManage setproperty» .

Машины, созданные до версии VirtualBox 4.0

Если вы перешли на VirtualBox 4.0 c более ранней версии, то параметры ваших файлов и дисков в расположены в других местах файловой системы.

До версии 4.0, VirtualBox файл с настройками ВМ размещался отделено от виртуальных образов диска. Файлы настроек машины с расширением .xml файл располагался в папке под названием «Machines» в общем каталоге конфигурации VirtualBox (см. следующий раздел). Так, например, на Linux, это был скрытый каталог $HOME/. VirtualBox/Machines . По умолчанию папка с жесткими диска называлась «HardDisks» и находилась также в . VirtualBox . Оба эти папки могут быть изменены пользователем в глобальной настройках. (Концепция «default hard disk folder» был устранена в VirtualBox 4.0, так как образы дисков в настоящее время находятся в папке каждой машины.)

Старая схема имела несколько серьезных недостатков.

Было очень трудно перемещать виртуальные машины с одного хоста на другой, потому что файлы, не находятся в одной папке. Кроме того, виртуальные носители всех машин были зарегистрированы в глобальном реестре VirtualBox в основном файле настроек ( $HOME/. VirtualBox/VirtualBox.xml ).

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

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

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

Глобальные данные конфигурации

Кроме файлов настроек виртуальных машин имеется файл конфигурации глобальных данных . В Windows, Linux и Solaris, он находится в $HOME/. VirtualBox (что делает его скрытым на Linux и Solaris), а на Mac в $HOME/Library/VirtualBox .

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

Самое главное, в этом каталоге, VirtualBox хранит свои глобальный конфигурационный файл, и другой XML-файл с именем VirtualBox.xml . Он включает в себя глобальные параметры конфигурации и список зарегистрированных виртуальных машин с указателями на их XML файлы настроек. (Ни расположение этого файла, ни его папка была изменены в VirtualBox 4.0.)

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

Также до VirtualBox 4.0, по умолчанию папки «Machines» и «HardDisks» находились в каталоге конфигурации VirtualBox (например, $HOME/. VirtualBox/Machines на Linux). При обновлении версии 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.xml .

Все VirtualBox XML файлы помчаются номером версии. При создании нового файла настройки создается (например, при создании новой виртуальная машина), VirtualBox автоматически использует настройки схемы текущей версии VirtualBox. Эти файлы могут не читаться, если вы откатитесь на более раннюю версию VirtualBox. Однако, когда VirtualBox читает файл настроек более ранней версии (например, после обновления VirtualBox), то он попытается считать настройки с максимальной возможностью сохранения данных. Если текущие настройки не могут сохраниться в старом формате,например потому что вы включили функционал который не был представлен в более ранней версии VirtualBox, то произойдет обновление схемы хранения настроек. [40] В таких случаях, VirtualBox создает резервную копию старого файла настройки в каталоге настроек виртуальной машины. Если вам нужно вернуться к более ранней версии VirtualBox, то вам нужно будет вручную скопировать эти резервные файлы обратно.

Мы намеренно не документируем спецификации XML файлов VirtualBox , так как мы оставляем за собой право вносить изменения в них в будущем. Поэтому мы настоятельно рекомендуем вам не редактировать эти файлы вручную. VirtualBox предоставляет полный доступ к данным настроек через утилиту командной строки VBoxManage (см. Глава 8, VBoxManage reference ) и собственный API (см. Глава 10, VirtualBox programming interfaces ).

Исполняемые файлы и компоненты VirtualBox

VirtualBox был разработан, с целю быть модульным и гибким. При открытие графического интерфейса пользователя (GUI) VirtualBox и запуске ВМ, то выполняются как минимум три процесса:

Читайте также:  16 клапанный двигатель калина замена масла

VBoxSVC , служба, которая всегда работает в фоновом режиме. Этот процесс запускается автоматически одним из клиентским процессов VirtualBox (GUI, VBoxManage , VBoxHeadless , веб-служб и других) и завершается через некоторое время после завершения последнего клиентом его использующего. Служба отвечает за учет и обслуживание всех виртуальных машин, а также обеспеченивает связь между компонентами VirtualBox. Эта связь осуществляется через COM / XPCOM.

Примечание

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

Процесс GUI, VirtualBox , клиентское приложение на основе кросс-платформенной библиотеки Qt. При запуске без параметра —startvm ,это приложение работает как VirtualBox manager, отображая список виртуальных машин и их настройки. Взаимодействуя с VBoxSVC , а также с другими процессами, например, VBoxManage он отслеживает настройки и изменения состояний ВМ.

Если VirtualBox запускается с параметром —startvm , он загружает VMM библиотеку, которая включает в себя гипервизор, а затем запускает виртуальную машину и обеспечивает ввод и вывод гостевой системы.

Любой клиент VirtualBox будет общаться с процессом обслуживания и может управлять и отображать текущие изменениями состояний. Например, окно ВМ или VBoxManage можно использовать для приостановки выполнения ВМ, а другие компоненты, всегда будет получать его изменившиеся состояние.

The VirtualBox GUI application is only one of several available front ends (clients). Полный список поставляемых с VirtualBox клиентов:

VirtualBox , использующий Qt интерфейс для управления виртуальными машинами;

VBoxManage , менее удобный интерфейс, но более мощная альтернатива, описан в главе 8, VBoxManage .

VBoxSDL , простой графический интерфейс на основе библиотеки SDL, см. раздел «VBoxSDL, the simplified VM displayer”. .

VBoxHeadless , интерфейс, который непосредственно не предоставляет никакого интерфейса вывода/вывода видео, клавиатуры и мыши, но реализует перенаправление запросов с помощью расширения VirtualBox Remote Desktop, см. раздел «VBoxHeadless, сервер удаленного рабочего стола» .

vboxwebsrv , служба веб-процесса VirtualBox, которая позволяет удаленно управлять хостом VirtualBox . Более подробное описание в VirtualBox Software Development Kit (SDK), см. главу 11, интерфейсы программирования 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.

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

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

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

Аппаратная виртуализации против программной

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

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

С 2006 года Intel и AMD процессоры имеют поддержку так называемой «аппаратной виртуализации». Это означает, что эти процессоры могут помочь VirtualBox перехватывать потенциально опасные операций, которые гостевая операционная система может пытаться выполнить, а также упрощает предоставление виртуального оборудование в виртуальную машину.

Эти аппаратные функции имеют отличия в процессорах Intel и AMD . Intel назвала свою технологию VT-X, AMD называет ее AMD-V. Технология виртуализации Intel и AMD сильнр отличается в деталях реализации, но не очень сильно отличается в принципе.

Примечание

На многих системах, функцию аппаратной виртуализации необходимо включить в 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 процессорах без поддержки аппаратной виртуализации является чрезвычайно сложной задачей, потому что архитектура этих процессоов не предназначена для для виртуализации. Эту проблему можно решенить, но ценой снижения производительности. Таким образом, происходит постоянное столкновение между производительностью виртуализальной среды и точности ее работы.

Набор инструкций x86 был первоначально разработан в 1970-х и затем получил значительные изменения с выходом 286 процессора, в который появился защищенный режима в 1980-х , а затем в Intel 386 с его 32-битной архитектурой. 386 процессор имел ограниченную поддержку виртуализации для реального режима работы (режим V86, используемый «DOS Box» в Windows 3.x и OS / 2 2.x), но никакой поддержки виртуализации всей архитектуры не было предусмотрено.

В теории, программная виртуализации не очень сложна. В дополнение к четырем аппаратным уровням привилегий («кольца»,»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, который может использоваться для полной программной эмуляции, но он активируется только в особых случаях, описанных ниже.)

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

VirtualBox chooses a different approach. When starting a virtual machine, through its ring-0 support kernel driver, VirtualBox has set up the host system so that it can run most of the guest code natively, but it has inserted itself at the «bottom» of the picture. It can then assume control when needed — if a privileged instruction is executed, the guest traps (in particular because an I/O register was accessed and a device needs to be virtualized) or external interrupts occur. VirtualBox may then handle this and either route a request to a virtual device or possibly delegate handling such things to the guest or host OS. In guest context, VirtualBox can therefore be in one of three states:

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.

On AMD processors, nested paging has been available starting with the Barcelona (K10) architecture — they call it now «rapid virtualization indexing» (RVI). Intel added support for nested paging, which they call «extended page tables» (EPT), with their Core i7 (Nehalem) processors.

If nested paging is enabled, the VirtualBox hypervisor can also use large pages to reduce TLB usage and overhead. This can yield a performance improvement of up to 5%. Чтобы включить эту функцию для виртуальной машины, вам нужно использовать команду VBoxManage modifyvm —largepages , см. раздел «VBoxManage modifyvm» .

На процессорах Intel, функция под названием «Virtual Processor Identifiers» (VPIDs) может значительно ускорить переключение контекста за счет снижения потребности в дорогостоящей операции Translation Lookaside Buffers (TLBs).

Чтобы включить эти функции для виртуальной машины, вам нужно использовать команду VBoxManage modifyvm —vtxvpid и —largepages , см. раздел «VBoxManage modifyvm» .

[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.

Adblock
detector