Nested paging virtualbox что это

Влияние настроек на производительность ВМ?

Влияют ли настройки “Nested VT-x/AMD-V” “PAE/NX” “Nested Paging” на производительность гостевой ОС семейства Linux? Если да, то в каком сочетании достигается оптимальная производительность? (Внутри ВМ другие ВМ не запускаются)


Спасибо.

• Вопрос задан более трёх лет назад
• 125 просмотров

Комментировать

Решения вопроса 0

Ответы на вопрос 1

Зависит от разрядности ОС . Для 32 битных систем сильного значения не имеет , а для 64 битных стоит также включить интерфейс паравиртуплизации.

Ответ написан более трёх лет назад

Комментировать

Нравится Комментировать

Ваш ответ на вопрос

Войдите, чтобы написать ответ

• VPN
• +4 ещё

Могу ли я поставить whonix в виртуальной машине на дистрибутив tails (live usb с зашифрованным разделом)? VPN + TOR?

• 1 подписчик
• вчера
• 43 просмотра

Как включить вложенную виртуализацию Nested VT-x/AMD-v в VirtualBox

Вложенная виртуализация – это функция, которая позволяет запускать виртуальные машины внутри виртуальных машин. Например, допустим, есть необходимость в запуске виртуальной машины с операционной системой CentOS с использованием Oracle VirtualBox в вашей виртуальной системе Ubuntu Linux. Если в Ubuntu включена функция вложенной виртуализации – Nested VT-x/AMD-v, вы можете установить Virtualbox или KVM на виртуальной машине CentOS и запустить другие виртуальные машины внутри нее. Таким образом, в основном это метод запуска среды виртуализации в другой среде виртуализации.

Начиная с версии 6.1, Oracle VM VirtualBox поддерживает функцию вложенной виртуализации на хост-системах с процессорами AMD и Intel. Поэтому убедитесь, что у вас установлена последняя версия Virtualbox.

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

Как включить вложенную виртуализацию Nested VT-x VirtualBox в системах в Microsoft Windows

Вложенная виртуализация включается отдельно для каждой виртуальной системы.

Открываем Командую строку (cmd.exe) от имени Администратора и выполняем следующие команды.

Переходим в директорию установленной программы в Program Files:

cd C:\Program Files\Oracle\VirtualBox

Выводим список виртуальных систем с помощью команды:

VBoxManage.exe list vms

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

VBoxManage.exe modifyvm "название виртуальной системы" --nested-hw-virt on

В данном случае вложенная виртуализация была подключена для виртуальной системы Ubuntu 20.04.

Проверим включение вложенной виртуализации в графическом интерфейсе VirtualBox. Откройте VirtualBox, выберите виртуальную машину и перейдите в меню Настроить > Система > Процессор.

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

Как включить вложенную виртуализацию Nested VT-x/AMD-v в VirtualBox в системах GNU/Linux

Открываем Терминал и выполняем следующие команды.

Для отображения списка виртуальных систем:

vboxmanage list vms

Для включения вложенной виртуализации:

VBoxManage modifyvm "название виртуальной системы" --nested-hw-virt on

Теперь в виртуальной системе вы можете установить VirtualBox и в нем установить еще одну виртуальную машину.

Nested paging virtualbox что это

Содержание этой главы не содержит информации о использования 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 создает

1. папку $HOME/VirtualBox VMs/Example VM/ и, в этой папке,
2. файла настроек Example VM.vbox и
3. виртуальный образ диска 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, так как образы дисков в настоящее время находятся в папке каждой машины.)

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

1. Было очень трудно перемещать виртуальные машины с одного хоста на другой, потому что файлы, не находятся в одной папке. Кроме того, виртуальные носители всех машин были зарегистрированы в глобальном реестре VirtualBox в основном файле настроек ( $HOME/. VirtualBox/VirtualBox.xml ). Для перемещения машины на другой хост, было не достаточно переместить XML файл настроек, а образы дисков (которые были в разных местах), но правильно скопированы записи из глобальных реестр, а также, было почти невозможно, если машина имела снимки и файлы разностных образов.
2. Хранение виртуальных образов диска, которые могли становиться очень большим, в скрытым каталоге . 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 и запуске ВМ, то выполняются как минимум три процесса:

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

Примечание

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

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

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

1. VirtualBox , использующий Qt интерфейс для управления виртуальными машинами;
2. VBoxManage , менее удобный интерфейс, но более мощная альтернатива, описан в главе 8, VBoxManage .
3. VBoxSDL , простой графический интерфейс на основе библиотеки SDL, см. раздел «VBoxSDL, the simplified VM displayer”. .
4. VBoxHeadless , интерфейс, который непосредственно не предоставляет никакого интерфейса вывода/вывода видео, клавиатуры и мыши, но реализует перенаправление запросов с помощью расширения VirtualBox Remote Desktop, см. раздел «VBoxHeadless, сервер удаленного рабочего стола» .
5. vboxwebsrv , служба веб-процесса VirtualBox, которая позволяет удаленно управлять хостом VirtualBox . Более подробное описание в VirtualBox Software Development Kit (SDK), см. главу 11, интерфейсы программирования VirtualBox.
6. 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 не всегда требует аппаратной виртуализации, но она необходима в следующих случаях:

• Некоторые редкие гостевые ОС, такие как 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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

Гипервизор против руткитов: как это работает

В последнее время наша компания разрабатывала детектор руткитов на базе аппаратной виртуализации. Проект задумывался с целью разобраться, как можно использовать новые возможности процессоров Intel и AMD для информационной безопасности. После нескольких итераций мы остановились на вполне работоспособном методе детектирования руткитов. О нем и пойдет речь.

Метод основан на технологии аппаратной виртуализации памяти (англ. nested paging или hardware assisted paging, общепринятого русскоязычного термина нет). Эта технология появилась в последних моделях процессоров Intel и AMD. Версия Intel называется Intel Extended Page Table (EPT) и поддерживается процессорами начиная с семейства Nehalem (Intel Core i3, i5, i7). Аналог AMD называется AMD Rapid Virtualization Indexing (RVI) и присутствует на процессорах, начиная с поколения AMD K10. Технологии схожи, поэтому все, что описывается далее об Intel EPT, применимо и к AMD RVI.

Теория

Итак, у нас есть гипервизор и работающая под его контролем гостевая операционная система (гость).

Переход управления из гипервизора в гостевую ОС называется VM Entry, обратный переход – VM Exit. Вся работа – это последовательность VM Entry и VM Exit, сменяющих друг друга. Гипервизор работает в изолированном адресном пространстве и «невидим» со стороны гостевой ОС. При этом он может изменять состояние гостевой ОС (виртуальный процессор, память, виртуальное аппаратное обеспечение и т.д.).

Читателю есть смысл ознакомиться с нашей предыдущей статьей, где речь шла о методе, основанном на теневой таблице страниц (shadow paging). Описываемый здесь метод – дальнейшее логическое его развитие.

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

При обычной работе процессора любое обращение к физическому адресу немедленно ведет к его выставлению на адресной шине процессора (кроме таких случаев, как обращение к APIC, но мы их опустим для простоты изложения). В случае с nested paging любое обращение гостя к физическому адресу (он получает название «гостевой физический адрес») сперва транслируется через специальную таблицу страниц. Физический адрес, полученный из гостевого физического адреса, выставляется на адресной шине, после чего происходит обращение к памяти.

Преобразование гостевых физических адресов для Intel EPT аналогично обычному страничному преобразованию:

Таблица страниц четырехуровневая и напоминает таблицу страниц для преобразования виртуальных адресов в 64-битном режиме Intel 64. Основное отличие – строение записей таблицы. На рисунке приведено строение записи для нижнего уровня таблицы (PTE):

Нас интересуют три младших бита записей, которые определяют доступ к физической памяти. Если сброшены биты R, W, X (биты 0. 2), то доступ к описываемой PTE памяти соответственно на чтение, запись и исполнение вызывает выход в гипервизор (EPT Violation по терминологии Intel).

Это дает возможность контролировать исполнение кода на процессоре и записи в память c кодом.

Суть метода

Полная виртуализация не является в нашем случае целью. Для контроля над выполнением и модификацией кода нам достаточно виртуализировать память и процессор.

Для виртуализации памяти нам нужно построить таблицу страниц EPT с отображением гостевых физических адресов в реальные физические адреса «один в один» (identity mapping). При этом в записях на нижнем уровне таблицы (PTE) мы сбрасываем биты W и X. Каждая такая запись описывает доступ к странице памяти размером 4 КБ.

Далее возможны два варианта выхода в гипервизор (VM Exit) с EPT Violation:

1. Доступ к странице памяти на запись. При этом происходит выход в гипервизор, после чего он разрешает запись в страницу (устанавливает бит W), но запрещает выполнение (сбрасывает бит X).
2. Доступ к странице памяти на выполнение. При этом гипервизор разрешает выполнение на странице (устанавливает X), но запрещает запись в нее (сбрасывает W).

Таким образом, страница памяти может быть либо только исполняемой, либо только записываемой. Запись и исполнение соответственно влекут выход в гипервизор (VM Exit) и переводят страницу из одного состояния в другое.

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

Практическая реализация

Мы реализовали детектор руткитов Hypersight Rootkit Detector, использующий вышеописанный метод. Он спроектирован так, чтобы его можно было загружать и выгружать по запросу пользователя. Это позволяет использовать его совместно с программами виртуализации, такими как VMware и VirtualBox.

• Попытки перехода в режим гипервизора.
• Модификации управляющих регистров кодом вне ядра и HAL.
• Модификации невыгружаемого кода ядра, HAL и драйверов в памяти, модификации SSDT. В том числе модификации путем отображения виртуальной памяти.
• Выполнение кода за пределами исполняемых секций драйверов, ядра и HAL. Так называемый «скрытый код», козырная карта руткитов, теперь легко обнаруживается.

Дальнейшая работа

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

Заключение

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

Nested paging virtualbox что это

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

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

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

• Новые процессоры Intel and AMD имеют поддержку так называемой «аппаратной виртуализации» . Она помогает программному обеспечению виртуализации, такому как VirtualBox, в прерывании потенциально опасных операций , которых операционная система гостя может пытаться выполнить. Реализация этих функций различны в Intel и AMD. Intel назвала свою технологии VT-x , а AMD как AMD-V .

Примечание

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

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

Включение апаратной вертуализации необходимо только в двух случаях:

• для некоторых редких гостевых ОС, например OS/2 , которые используют специфические команды процессора и которые не реализованы в VirtualBox
• если вы хотите работать с 64 битовыми гостевыми ОС (начиная с VirtualBox версии 2.0), большинство 64 битных CPU поддерживают аппаратную виртуализацию — исключая старшие линейки процессоров Intel Celeron и AMD Opteron .

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

Предупреждение

Не работайте одновременно с другими гипервизорами (программами исполнения виртуальных машин) (open-source or commercial virtualization products) с VirtualBox! Несколько гипервизоров могут обычно устанавливаться параллельно на одной системе, но не пытайтесь выполнить несколько виртуальных машин на различных гипервизоров в одно и то же время. VirtualBox не может проследить за тем, что другой гипервизор пытается сделать на том же самой системе, и особенно если они одновременно пытаются использовать возможности аппаратной виртуализации, такие как VT-X, что может превести к краху всей системы.

Кроме «базовой» аппаратной виртуализации, ваш процессор может поддерживать дополнительные технологии: [1]

• Наиболее новая технология «nested paging» позволяет управлять памятью хоста, что позволяет усилить производительность , т.к. не требуется программное управление памятью. На AMD процессорах, nested paging стала доступна начиная с архитектуры Barcelona (K10) ; Intel добавила поддержку nested paging, которую она назвала «extended page tables» (EPT), в свих процессорах Core i7 (Nehalem). Технология Nested paging не устанавливается по умолчанию, но она может быть установлена отдельно для каждой ВМ. Если ваш компьютер поддерживает nested paging (AMD-V) or EPT (VT-x), то вы можете получить значительный прирост производительности используя эту технологию.
• Другая аппаратная возможность называется «Virtual Processor Identifiers» (VPIDs) позволяет значительно ускорить переключение контекста Translation Lookaside Buffers (TLBs) процессора, уменьшая количество операции записей на диск . Чтобы использовать эту возможность вы должны использовать командную строку; см Section 8.5, “VBoxManage modifyvm”.

[1] Поддержка AMD nested paging добавлена в VirtualBox 2.0 ; поддержка Intel EPT и VPIDs добавлена в версии 2.1.

Как включить вложенную виртуализацию Nested VT-x/AMD-v в VirtualBox

Вложенная виртуализация – это функция, которая позволяет запускать виртуальные машины внутри виртуальных машин. Например, допустим, есть необходимость в запуске виртуальной машины с операционной системой CentOS с использованием Oracle VirtualBox в вашей виртуальной системе Ubuntu Linux. Если в Ubuntu включена функция вложенной виртуализации – Nested VT-x/AMD-v, вы можете установить Virtualbox или KVM на виртуальной машине CentOS и запустить другие виртуальные машины внутри нее. Таким образом, в основном это метод запуска среды виртуализации в другой среде виртуализации.

Начиная с версии 6.1, Oracle VM VirtualBox поддерживает функцию вложенной виртуализации на хост-системах с процессорами AMD и Intel. Поэтому убедитесь, что у вас установлена последняя версия Virtualbox.

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

Как включить вложенную виртуализацию Nested VT-x VirtualBox в системах в Microsoft Windows

Вложенная виртуализация включается отдельно для каждой виртуальной системы.

Открываем Командую строку (cmd.exe) от имени Администратора и выполняем следующие команды.

Переходим в директорию установленной программы в Program Files:

cd C:\Program Files\Oracle\VirtualBox

Выводим список виртуальных систем с помощью команды:

VBoxManage.exe list vms

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

VBoxManage.exe modifyvm "название виртуальной системы" --nested-hw-virt on

В данном случае вложенная виртуализация была подключена для виртуальной системы Ubuntu 20.04.

Проверим включение вложенной виртуализации в графическом интерфейсе VirtualBox. Откройте VirtualBox, выберите виртуальную машину и перейдите в меню Настроить > Система > Процессор.

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

Как включить вложенную виртуализацию Nested VT-x/AMD-v в VirtualBox в системах GNU/Linux

Открываем Терминал и выполняем следующие команды.

Для отображения списка виртуальных систем:

vboxmanage list vms

Для включения вложенной виртуализации:

VBoxManage modifyvm "название виртуальной системы" --nested-hw-virt on

Теперь в виртуальной системе вы можете установить VirtualBox и в нем установить еще одну виртуальную машину.

Влияние настроек на производительность ВМ?

Влияют ли настройки “Nested VT-x/AMD-V” “PAE/NX” “Nested Paging” на производительность гостевой ОС семейства Linux? Если да, то в каком сочетании достигается оптимальная производительность? (Внутри ВМ другие ВМ не запускаются)


Спасибо.

• Вопрос задан более трёх лет назад
• 125 просмотров

Комментировать

Решения вопроса 0

Ответы на вопрос 1

Зависит от разрядности ОС . Для 32 битных систем сильного значения не имеет , а для 64 битных стоит также включить интерфейс паравиртуплизации.

Ответ написан более трёх лет назад

Комментировать

Нравится Комментировать

Ваш ответ на вопрос

Войдите, чтобы написать ответ

• VPN
• +4 ещё

Могу ли я поставить whonix в виртуальной машине на дистрибутив tails (live usb с зашифрованным разделом)? VPN + TOR?

• 1 подписчик
• вчера
• 43 просмотра

Nested paging virtualbox что это

Содержание этой главы не содержит информации о использования 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 создает

1. папку $HOME/VirtualBox VMs/Example VM/ и, в этой папке,
2. файла настроек Example VM.vbox и
3. виртуальный образ диска 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, так как образы дисков в настоящее время находятся в папке каждой машины.)

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

1. Было очень трудно перемещать виртуальные машины с одного хоста на другой, потому что файлы, не находятся в одной папке. Кроме того, виртуальные носители всех машин были зарегистрированы в глобальном реестре VirtualBox в основном файле настроек ( $HOME/. VirtualBox/VirtualBox.xml ). Для перемещения машины на другой хост, было не достаточно переместить XML файл настроек, а образы дисков (которые были в разных местах), но правильно скопированы записи из глобальных реестр, а также, было почти невозможно, если машина имела снимки и файлы разностных образов.
2. Хранение виртуальных образов диска, которые могли становиться очень большим, в скрытым каталоге . 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 и запуске ВМ, то выполняются как минимум три процесса:

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

Примечание

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

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

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

1. VirtualBox , использующий Qt интерфейс для управления виртуальными машинами;
2. VBoxManage , менее удобный интерфейс, но более мощная альтернатива, описан в главе 8, VBoxManage .
3. VBoxSDL , простой графический интерфейс на основе библиотеки SDL, см. раздел «VBoxSDL, the simplified VM displayer”. .
4. VBoxHeadless , интерфейс, который непосредственно не предоставляет никакого интерфейса вывода/вывода видео, клавиатуры и мыши, но реализует перенаправление запросов с помощью расширения VirtualBox Remote Desktop, см. раздел «VBoxHeadless, сервер удаленного рабочего стола» .
5. vboxwebsrv , служба веб-процесса VirtualBox, которая позволяет удаленно управлять хостом VirtualBox . Более подробное описание в VirtualBox Software Development Kit (SDK), см. главу 11, интерфейсы программирования VirtualBox.
6. 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 не всегда требует аппаратной виртуализации, но она необходима в следующих случаях:

• Некоторые редкие гостевые ОС, такие как 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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.