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

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

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

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

Внутренне, VirtualBox состоит из множества более или менее обособленных компонент. Вы можете столкнуться с ними при просмотре сообщений об ошибках VirtualBox и в лог-файлах. К ним относятся:

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

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

Даже при том, что VirtualBox не всегда требует аппаратной виртуализации, но она необходима в следующих случаях:

Реализация виртуализации на 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:

Unfortunately this only works to a degree. Among others, the following situations require special handling:

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 режима в 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.

В дополнение к "простой" аппаратной виртуализации, процессор может также поддерживать дополнительные технологии: ^{[ 41 ]}