Где хранятся файлы виртуальной машины virtualbox
Где VirtualBox хранит свои файлы
Виртуальная машина и ее настройки описываются файлом настроек в формате XML. Кроме этого, большинство виртуальных машин имеют один или несколько виртуальных жестких дисков, которые обычно представлены образом диска (например, в формате VDI). Место, где все эти файлы хранятся зависит от версии VirtualBox в которой создали машину.
Машины, созданные VirtualBox версии 4.0 или более поздней
По умолчанию, это «машинная папка» помещается в общую директорию под названием «VirtualBox VMs», которую VirtualBox создает в домашнем каталоге текущего пользователя системы. Расположение этого домашнего каталога зависит от настроек операционной системы хоста:
Например, при создании виртуальной машины под названием «Example VM», VirtualBox создает
файла настроек Example VM.vbox и
Машины, созданные до версии VirtualBox 4.0
Если вы перешли на VirtualBox 4.0 c более ранней версии, то параметры ваших файлов и дисков в расположены в других местах файловой системы.
Старая схема имела несколько серьезных недостатков.
Для перемещения машины на другой хост, было не достаточно переместить XML файл настроек, а образы дисков (которые были в разных местах), но правильно скопированы записи из глобальных реестр, а также, было почти невозможно, если машина имела снимки и файлы разностных образов.
Новые виртуальные машины, созданные в VirtualBox 4.0 или более поздней будет соответствовать новый схеме, а для максимальной совместимости, старые виртуальные машины не преобразуются в новую схему. В противном случае настройки машины будут безвозвратно потеряны, если пользователь с версии старше 4.0 перейти к более ранней версии VirtualBox.
Глобальные данные конфигурации
До версии VirtualBox 4.0, все виртуальные устройства хранения (файлы образов диска) также были включены в глобальный реестр этого файла настройки. Для совместимости, этот реестр устройств хранения(носителей) все еще существует в обновленных версиях VirtualBox, где есть носители из машин, которые были созданы до версии 4.0. Если у вас нет таких машин, то файл глобального реестра не создается; с VirtualBox 4.0, каждый файл настроек машины имеет свой собственный реестр носителей.
Обзор изменения в конфигурации 4.0
Таблица 10.1. ignoreme
| До 4.0 | 4.0 или выше | |
| Папка машин по умолчанию | $HOME/.VirtualBox/Machines | $HOME/VirtualBox VMs |
| Расположение образа диска | $HOME/.VirtualBox/HardDisks | В папке каждой машины |
| Расширение файла настроек машины | .xml | .vbox |
| Реестра носителей | Глобальный VirtualBox.xml файл | Каждый файл настройки машины |
| Media registration | Требуется явнре открытие / закрытие | Автоматическое подключение |
XML файлы VirtualBox
Все VirtualBox XML файлы помчаются номером версии. При создании нового файла настройки создается (например, при создании новой виртуальная машина), VirtualBox автоматически использует настройки схемы текущей версии VirtualBox. Эти файлы могут не читаться, если вы откатитесь на более раннюю версию VirtualBox. Однако, когда VirtualBox читает файл настроек более ранней версии (например, после обновления VirtualBox), то он попытается считать настройки с максимальной возможностью сохранения данных. Если текущие настройки не могут сохраниться в старом формате,например потому что вы включили функционал который не был представлен в более ранней версии VirtualBox, то произойдет обновление схемы хранения настроек. [40] В таких случаях, VirtualBox создает резервную копию старого файла настройки в каталоге настроек виртуальной машины. Если вам нужно вернуться к более ранней версии VirtualBox, то вам нужно будет вручную скопировать эти резервные файлы обратно.
Исполняемые файлы и компоненты VirtualBox
VirtualBox был разработан, с целю быть модульным и гибким. При открытие графического интерфейса пользователя (GUI) VirtualBox и запуске ВМ, то выполняются как минимум три процесса:
Примечание
Любой клиент VirtualBox будет общаться с процессом обслуживания и может управлять и отображать текущие изменениями состояний. Например, окно ВМ или VBoxManage можно использовать для приостановки выполнения ВМ, а другие компоненты, всегда будет получать его изменившиеся состояние.
The VirtualBox GUI application is only one of several available front ends (clients). Полный список поставляемых с VirtualBox клиентов:
VirtualBox Python shell, Python альтернатива VBoxManage. Описано так же в SDK.
Внутренне, VirtualBox состоит из множества более или менее обособленных компонент. Вы можете столкнуться с ними при просмотре сообщений об ошибках VirtualBox и в лог-файлах. К ним относятся:
IPRT, кросс-платформенная runtime библиотека, которая предоставляет интерфейс доступа к файлам, потокам, обработке строк и т.д. Всякий раз, когда VirtualBox обращается к функционалу хоста, он делает это через эту библиотеку. что позволяет ему работать на различных ОС.
VMM (Virtual Machine Monitor), «сердце» гипервизора.
EM (Execution Manager), контролирует исполнение кода гостя.
REM (Recompiled Execution Monitor), обеспечивает программную эмуляцию инструкций процессора.
TRPM (Trap Manager), перехватывает и обрабатывает гостя Trap(ловушки) и исключения.
HWACCM (Hardware Acceleration Manager), обеспечивает поддержку VT-X и AMD-V.
PDM (Pluggable Device Manager), абстрактный интерфейс между VMM и эмулируемым устройством, которое отделяет реализацию устройства от VMM системы и позволяет легко добавлять новые эмулируемые устройства. Через PDM, сторонние разработчики могут добавлять новые виртуальные устройства для VirtualBox без необходимости изменения самого VirtualBox.
PGM (Page Manager), компонент управления памятью.
PATM(Patch Manager), модуль модификации кода гостя для улучшения и ускорения виртуализации.
TM (Time Manager), обработчики таймеров и все связаное с работой с временем в гостях.
CFGM (Configuration Manager), предоставляет древовидную структуру которая содержит параметры конфигурации виртуальной машины и все эмулируемые устройства.
SSM (Saved State Manager), сохраняет и загружает состояние ВМ.
VUSB (Virtual USB), слой, который отделяет эмулируемые USB контроллеры от контроллеров USB устройств на хосте и который также предоставляет интерфейс удаленных устройств USB.
DBGF (Debug Facility), встроенный отладчик VM.
Специальный компонент «Main» : он связывает все перечисленные выше элементы вместе и реализует единственный общедоступный API. Все клиенты перечисленных выше систем используют только этот API и никогда не получают прямой доступ к компонентам гипервизора. В результате, сторонние приложения, использующие VirtualBox Main API могут рассчитывать на то, что данный интерфейс хорошо проверен и, что им будут доступны все возможности VirtualBox. Именно этот API, упомянутый выше, описан в VirtualBox SDK(опять же, см. главу 11, Программный интерфейс VirtualBox ).
Аппаратная виртуализации против программной
К сожалению, платформы x86, никогда не была расчитана на виртуализацию. Обнаружение ситуаций, в которых VirtualBox необходимо брать контроль над гостевым кодом, является трудной задачей. Существует два способа, чтобы достигнуть этого:
С 2006 года Intel и AMD процессоры имеют поддержку так называемой «аппаратной виртуализации». Это означает, что эти процессоры могут помочь VirtualBox перехватывать потенциально опасные операций, которые гостевая операционная система может пытаться выполнить, а также упрощает предоставление виртуального оборудование в виртуальную машину.
Примечание
На многих системах, функцию аппаратной виртуализации необходимо включить в BIOS перед началом использования ее в VirtualBox.
В отличие от других систем виртуализации, в большинстве случаев, VirtualBox не требует аппаратной виртуализации. Посредством сложных методов, виртуализации многих гостевых операционных систем полностью обеспечивается программном способом. Это означает, что вы можете запускать виртуальные машины даже на старых процессорах, которые не поддерживают аппаратную виртуализацию.
Даже при том, что VirtualBox не всегда требует аппаратной виртуализации, но она необходима в следующих случаях:
Некоторые редкие гостевые ОС, такие как OS / 2, используют скрытые инструкций процессора, которые не поддерживаются нашим программным обеспечением. Для виртуальных машин, которые настроены для использования подобной операционной системы, аппаратная виртуализация включается автоматически.
64-битные гостевые (добавлено в версии 2.0) и многопроцессорные системы (SMP, добавлена с версии 3.0) требуют аппаратной виртуализации. (Это не так много критично, так как подавляющее большинство сегодняшних 64-битных и многоядерных процессоровы имеют аппаратную виртуализацию; исключением из этого правила являются, например, старые Intel Celeron и процессоры AMD Opteron.)
Предупреждение
Не запускайте других гипервизоров (с открытым исходным кодом или коммерческих продуктов ) вместе с VirtualBox! Хотя несколько гипервизоров обычно могут быть установлены параллельно, не пытайтесь запускать несколько виртуальных машин в конкурирующих гипервизорах в одно и то же время. VirtualBox не может отслеживать работу другого гипервизор на том же хосте, и особенно, если несколько продуктов используют функции аппаратной виртуализацию, например, таких как VT-х, это может привести к краху хоста. Кроме того, в VirtualBox, вы можете смешать программную и аппаратную виртуализацию при запуске нескольких виртуальных машин. В некоторых случаях наблюдается небольшое снижение производительности при одновременном использовании VT-х и программной виртуализации. Мы рекомендуем не смешиваясь режимы виртуализации, когда требуется максимальная производительность и низкие накладные расходы являются. Однако, это не относится к AMD-V.
Подробнее о программной виртуализации
Реализация виртуализации на x86 процессорах без поддержки аппаратной виртуализации является чрезвычайно сложной задачей, потому что архитектура этих процессоов не предназначена для для виртуализации. Эту проблему можно решенить, но ценой снижения производительности. Таким образом, происходит постоянное столкновение между производительностью виртуализальной среды и точности ее работы.
В теории, программная виртуализации не очень сложна. В дополнение к четырем аппаратным уровням привилегий («кольца»,»rings») (из которых обычно используются только два : кольцо 0 для режима ядра и кольца 3 для пользовательского режима), необходимо выделить «контекст хоста» и «контекст гостя».
In «host context», everything is as if no hypervisor was active. This might be the active mode if another application on your host has been scheduled CPU time; in that case, there is a host ring 3 mode and a host ring 0 mode. The hypervisor is not involved.
В «гостевом контексте» выполняются виртуальные машины. Пока код гостя выполняется в кольце 3, это не такая уж большая проблема, так как гипервизор может установить правильны таблицы страниц и выполнять этот код на физическом процессоре. Проблемы появляются когда нужно перехватить работу кода на уровне ядра гостя.
Есть несколько возможных решений этих проблем. Одним из подходов является полная программная эмуляция, как правило, с помощью перекомпиляции. То есть, весь машинный код гостя анализируется, преобразуется в форму, которая позволят скрыть от гостя и не позволяет изменить ему состояние процессора, и только затем этот измененный код выполняется. Данный метод весьма сложный и дорогостоящий с точки зрения производительности. (В состав VirtualBox входит такой перекомпилятор на основе QEMU, который может использоваться для полной программной эмуляции, но он активируется только в особых случаях, описанных ниже.)
Guest ring 3 code is run unmodified, at full speed, as much as possible. The number of faults will generally be low (unless the guest allows port I/O from ring 3, something we cannot do as we don’t want the guest to be able to access real ports). This is also referred to as «raw mode», as the guest ring-3 code runs unmodified.
For guest code in ring 0, VirtualBox employs a nasty trick: it actually reconfigures the guest so that its ring-0 code is run in ring 1 instead (which is normally not used in x86 operating systems). As a result, when guest ring-0 code (actually running in ring 1) such as a guest device driver attempts to write to an I/O register or execute a privileged instruction, the VirtualBox hypervisor in «real» ring 0 can take over.
The hypervisor (VMM) can be active. Every time a fault occurs, VirtualBox looks at the offending instruction and can relegate it to a virtual device or the host OS or the guest OS or run it in the recompiler.
In particular, the recompiler is used when guest code disables interrupts and VirtualBox cannot figure out when they will be switched back on (in these situations, VirtualBox actually analyzes the guest code using its own disassembler). Also, certain privileged instructions such as LIDT need to be handled specially. Finally, any real-mode or protected-mode code (e.g. BIOS code, a DOS guest, or any operating system startup) is run in the recompiler entirely.
Unfortunately this only works to a degree. Among others, the following situations require special handling:
Running ring 0 code in ring 1 causes a lot of additional instruction faults, as ring 1 is not allowed to execute any privileged instructions (of which guest’s ring-0 contains plenty). With each of these faults, the VMM must step in and emulate the code to achieve the desired behavior. While this works, emulating thousands of these faults is very expensive and severely hurts the performance of the virtualized guest.
There are certain flaws in the implementation of ring 1 in the x86 architecture that were never fixed. Certain instructions that should trap in ring 1 don’t. This affect for example the LGDT/SGDT, LIDT/SIDT, or POPF/PUSHF instruction pairs. Whereas the «load» operation is privileged and can therefore be trapped, the «store» instruction always succeed. If the guest is allowed to execute these, it will see the true state of the CPU, not the virtualized state. The CPUID instruction also has the same problem.
A hypervisor typically needs to reserve some portion of the guest’s address space (both linear address space and selectors) for its own use. This is not entirely transparent to the guest OS and may cause clashes.
The SYSENTER instruction (used for system calls) executed by an application running in a guest OS always transitions to ring 0. But that is where the hypervisor runs, not the guest OS. In this case, the hypervisor must trap and emulate the instruction even when it is not desirable.
The CPU segment registers contain a «hidden» descriptor cache which is not software-accessible. The hypervisor cannot read, save, or restore this state, but the guest OS may use it.
Some resources must (and can) be trapped by the hypervisor, but the access is so frequent that this creates a significant performance overhead. An example is the TPR (Task Priority) register in 32-bit mode. Accesses to this register must be trapped by the hypervisor, but certain guest operating systems (notably Windows and Solaris) write this register very often, which adversely affects virtualization performance.
To fix these performance and security issues, VirtualBox contains a Code Scanning and Analysis Manager (CSAM), which disassembles guest code, and the Patch Manager (PATM), which can replace it at runtime.
Before executing ring 0 code, CSAM scans it recursively to discover problematic instructions. PATM then performs in-situ patching, i.e. it replaces the instruction with a jump to hypervisor memory where an integrated code generator has placed a more suitable implementation. In reality, this is a very complex task as there are lots of odd situations to be discovered and handled correctly. So, with its current complexity, one could argue that PATM is an advanced in-situ recompiler.
In addition, every time a fault occurs, VirtualBox analyzes the offending code to determine if it is possible to patch it in order to prevent it from causing more faults in the future. This approach works well in practice and dramatically improves software virtualization performance.
Подробнее об аппаратной виртуализации
В Intel VT-х существуют два различных режима работы CPU: VMX root(обычный) режиме и non-root(виртуализированный) режиме.
В root режиме процессор работает так же, как старшие поколения процессоров без VT-X поддержки. В нем существуют четыре уровня привилегий («колец») и поддерживается тот же набор инструкций процессора, с добавлением нескольких инструкций виртуализации. Root mode is what a host operating system without virtualization uses, and it is also used by a hypervisor when virtualization is active.
В non-root режиме, процессорные операции значительно отличаются. Имеются те же четыре кольца привилегий и тот же набор инструкций, но появляется новая структура под названием VMCS (Virtual Machine Control Structure) контролирущая работу CPU. В Non-root режиме выполняется гостевая ОС.
Операция переключение из root режима в non-root режим называется «VM вход», обратная операция «VM выход». VMCS хранит состояния гостевой системы и хоста, которые сохраняются при сменах режима. Самое главное здесь, что структуры VMCS хранит информацию о том какие гостевые операции вызовет событие VM выход.
VMCS предоставляет достаточно полный контроль за тем, что могут и не могут делать гостевые системы. Например, гипервизор может разрешить гостевой писать данные в одни регистры управления, а другие нет. Это обеспечивает эффективную виртуализацию, когда гости могут изменять регистры состояние системы, не нарушая работу гипервизора и предотвращая их от изменения регистров состояния системы над которыми гипервизора должен сохранить полный контроль. VMCS также обеспечивает контроль за прерываниями и исключениями.
Всякий раз, когда выполняется команда или событие, которое приводит к VM выходу, VMCS содержит информацию о причине выхода. Например, если запись в регистре CR0 вызывает выход, то регистрируется инструкция «нарушитель», а также информация о источнике и целевом регистре и т.п.. Таким образом, гипервизор может эффективно обрабатывать состояние системы без использования технологий CSAM и PATM описаных выше.
VT-X изначально избегает несколько проблем, с которыми сталкивается программная виртуализация. Гость имеет свое совершенно отдельное адресное пространство не используеемое совместно с гипервизором, что устраняет возможные конфликты. Additionally, guest OS kernel code runs at privilege ring 0 in VMX non-root mode, obviating the problems by running ring 0 code at less privileged levels. For example the SYSENTER instruction can transition to ring 0 without causing problems. Naturally, even at ring 0 in VMX non-root mode, any I/O access by guest code still causes a VM exit, allowing for device emulation.
Основное отличие VT-X и AMD-V в том, что AMD-V обеспечивает более полную виртуализацию среды. VT-x requires the VMX non-root code to run with paging enabled, which precludes hardware virtualization of real-mode code and non-paged protected-mode software. This typically only includes firmware and OS loaders, but nevertheless complicates VT-x hypervisor implementation. AMD-V does not have this restriction.
Конечно аппаратная виртуализация не является совершенной. По сравнению с программной виртуализацией, накладные расходы на обработку VM выходов относительно высоки. Это создает проблемы для эмуляции устройств, которая требует создания большого количества обработчиков. One example is the VGA device in 16-color modes, where not only every I/O port access but also every access to the framebuffer memory must be trapped.
Nested paging and VPIDs
В дополнение к «простой» аппаратной виртуализации, процессор может также поддерживать дополнительные технологии: [ 41 ]
Новая функцию под названием «nested paging» реализует управления памятью на аппаратном уровне, которая может значительно ускорить аппаратную виртуализацию, так как эту задачу больше не нужно выполнять программе виртуализации.
With nested paging, the hardware provides another level of indirection when translating linear to physical addresses. Page tables function as before, but linear addresses are now translated to «guest physical» addresses first and not physical addresses directly. A new set of paging registers now exists under the traditional paging mechanism and translates from guest physical addresses to host physical addresses, which are used to access memory.
Nested paging eliminates the overhead caused by VM exits and page table accesses. In essence, with nested page tables the guest can handle paging without intervention from the hypervisor. Nested paging thus significantly improves virtualization performance.
На процессорах Intel, функция под названием «Virtual Processor Identifiers» (VPIDs) может значительно ускорить переключение контекста за счет снижения потребности в дорогостоящей операции Translation Lookaside Buffers (TLBs).
[40] As an example, before VirtualBox 3.1, it was only possible to enable or disable a single DVD drive in a virtual machine. If it was enabled, then it would always be visible as the secondary master of the IDE controller. With VirtualBox 3.1, DVD drives can be attached to arbitrary slots of arbitrary controllers, so they could be the secondary slave of an IDE controller or in a SATA slot. If you have a machine settings file from an earlier version and upgrade VirtualBox to 3.1 and then move the DVD drive from its default position, this cannot be expressed in the old settings format; the XML machine file would get written in the new format, and a backup file of the old format would be kept.
[41] VirtualBox 2.0 added support for AMD’s nested paging; support for Intel’s EPT and VPIDs was added with version 2.1.
Особенности работы с виртуальными дискaми VirtualBox
Статья рассматривает особенности использования виртуальных дисков в VirtualBox, применение разных режимов чтения-записи, принцип и организацию работы snapshot-ов, кэширование ввода/вывода данных, а также некоторые аспекты использования виртуальных дисков с точки зрения информационной безопасности. Для тех, кому интересен пример с безопасностью, можете сразу переходить по якорю к разделу об особых режимах записи.
Начнем с некоторых общих понятий. У VirtualBox существуют 3 основных метода предоставления гостевой операционной системе (ОС) доступа к данным. Сей текст концентрируется на использовании виртуальных дисков.
Виртуальные диски подключаются к виртуальной — гостевой ОС, методом эмуляции подключения через соответствующий контроллер, IDE, SATA (AHCI), SCSI, SAS.
Поведение контроллеров запрограммировано таким образом, чтобы имитировать физические прототипы, следовательно IDE контроллер будет работать медленнее SATA и потреблять больше ресурсов процессора, ОС без соответствующих драйверов и аппаратной поддержки не будут взаимодействовать с виртуальными дисками и т.д. Например, в семействе Windows до Windows Vista нет поддержки Advanced Host Controller Interface (AHCI), к которому относится SATA, поэтому в частности, виртуальная машина с ОС Windows XP с SATA работать не будет.
Файлы виртуальных дисков
VirtualBox позволяет работать с разными форматами файлов виртуальных дисков. Помимо собственного VDI, поддерживаются VMDK (VMware), VHD (Microsoft), Parallels version 2 HDD format (Parallels).
Каждому виртуальному диску присваивается уникальный идентификатор UUID, это помогает VirtualBox удостовериться, что каждый диск используется только один раз и не позволяет импортировать в гостевую ОС обычные копии дисков (для этого существует отдельная процедура клонирования).
Виртуальные диски могут быть, как фиксированного размера, так и динамически выделяемого, причем VirtualBox позволяет увеличить размер дискового пространства, независимо от объёма и формата диска и даже в том случае, если диск содержит данные. Ниже пример, как это сделать с помощью утилиты vboxmanage.
При выборе динамически выделяемого образа, файл контейнера будет «разрастаться» постепенно, по мере заполнения секторов данными, до тех пор, пока размер контейнера не достигнет указанного при создании виртуальной машины лимита.
Учитывая то, что в процессе регулярного увеличения размера контейнера задействуются дополнительные вычислительные ресурсы, скорость записи при использовании опции с фиксированным размером, как правило выше, в с равнении с динамическим диском. Тем не менее, если размер динамического диска в долгосрочной перспективе значительно не увеличивается, то разница в скорости записи практически нивелируется.
Управление виртуальными медиа (Virtual Media Manager)
VirtualBox ведет реестр всех виртуальных медиа носителей, которые используются всеми гостевыми ОС. Это так называемые ”known media”, доступ к списку (реестру) которых можно получить используя утилиту Virtual Media Manager (доступно из меню File). Эта утилита показывает детальную информацию о каждом виртуальном диске, включая полный путь к файлу, а также к какой именно виртуальной машине файл прикреплен. Информацию из реестра можно удалить используя встроенную функцию удаления “Remove”
Каждый отдельно взятый образ можно «открепить» от виртуальной машины за которой он закреплен, используя функцию ”Release”
Открепив образ, прикрепить его обратно нажатием одной кнопки не удастся, для этого необходимо будет добавить образ, как жесткий диск. Аналогичным способом «прикрепляются» и снэпшоты (снимки диска).
В очередной раз отмечу, что из-за наличия UUID, о которых говорилось выше, нельзя просто скопировать и прикрепить образ диска.
Snapshots (Снэпшоты)
Как известно snapshot в переводе с английского означает снимок. Принцип работы механизма прост. При создании снэпшота, VirtualBox переводит текущий образ (образы, если их несколько), прикрепленный к ВМ в режим только для чтения и создает отдельный виртуальный диск (диски) и все последующие процедуры записи производятся уже в новом виртуальном хранилище. Причем фиксируются только изменения в определенных секторах, проще говоря при создании снэпшота диска размером 10GB, новый снэпшот будет гораздо меньше, и будет увеличиваться в размере постепенно, как будут заполнятся сектора.
Логично предположить, что чем больше используется снэпшотов одной виртуальной машины, тем больше используется вычислительных ресурсов для выполнения операций чтения с диска. Действительно, если есть 2 снэпшота, то вначале VirtualBox смотрит есть ли нужный сектор в образе снэпшота2, если нет, то система обращается к снэпшоту1, если и там ничего не обнаружено, то тогда идет обращение к основному диску. Нагрузка все-же будет незначительной и мало заметной для конечного пользователя, т, к. вся таблица секторов постоянно присутствует в памяти.
Стоить помнить, что при удалении снэпшота, все изменения произведенные после его создания «сливаются» с ранее «замороженным» образом.
Кэширование ввода/вывода
Затронув тему производительности уместно будет упомянуть и о кэшировании. Изначально VirtualBox работает с файлами образов, как с обычными файлами, которые само-собой кэшируются хостовой ОС. Это сделано, как нистранно с целью увеличение скорости. Когда гостевая ОС производит операцию записи, то операция кэшируется хостовой ОС и сообщение об успешном завершении операции отправляется в гостевую ОС сразу-же, в то время как сама операция обрабатывается гостевой ОС асинхронно. Такой подход не всегда себя оправдывает, т.к. файлы образов диска имеют тенденцию увеличиваться в объеме и вся процедура начинает давать обратный эффект — происходит двойное кэширование на стороне гостевой и хостовой операционных систем и снижается скорость производимых операций.
Помимо расходa ресурсов еще одним недостатком кэширования является недостаточная надежность. Например, если внезапно случился перебой с электропитанием в момент, когда хоставая ОС уже сообщила гостевой об успешном выполнении записи, а сам процесс асинхронной записи еще не завершился. Такой сценарий безусловно приводит к потере данных.
Отключение кэширования выполняется следующим образом:
Bandwidth
VirtualBox позволяет ограничивать ширину пропускного канала для одного или нескольких виртуальных дисков.
Создаем группу “Limit” и устанавливаем лимит в 20 Mb/s
Добавляем нужные диски в группу.
Суммарный для обоих дисков bandwidth не будет превышать 20 MB/s. Этот лимит можно изменить в любой момент, не выключая виртуальной машины.
Особые режимы записи образов
Для каждого образа виртуального диска, поддерживаемого VirtualBox, не зависимо от формата, можно определить режим поведения при записи данных, будь это следствие операций внутри виртуальной машины или снимка дика (snapshot). Такие режимы называются «нестандартными», в то время, как по умолчанию все образы дисков функционируют в «нормальном» режиме. Для того, что бы перевести режим из «нормального» в «нестандартный» можно воспользоваться вышеупомянутым Virtual Media Manager или консольной утилитой vboxmanage
В «нормальном» режиме записи, гостевая ОС может осуществлять чтение и запись с физического диска без всяких ограничений a при создании снимков диска (snapshot), VirtualBox создает oтдельный файл в котором фиксируются все изменения.
В режиме «write through» функция снэпшотов работать не бует.
Режим работы «shareable» своего рода разновидность предыдущего. Тут тоже нет возможности работы со «снэпшотами», зато есть возможность использования несколькими одновременно работающими виртуальными машинами одного образа диска, сценарий кластеризации.
Схожий по названию, но отличающийся по принципам работы режим «multiattach», также позволяет использовать один образ диска для нескольких виртуальных машин, но в этом режиме каждая отдельная виртуальная машина использует свой независимый «снэпшот» и изменения произведенные в одной ВМ не доступны для других.
Режим «read only» используется в основном для работы с образами CD/DVD, т.к. предполагает только чтение.
Режим на который стоит обратить внимание называется «Immutable». Как следует из названия immutable образы не меняются с течением времени. Любые изменения в immutable диске актуальны ровно до тех пор, пока виртуальная машина работает. После отключения виртуальной машины все изменения пропадают. Прежде чем перевести диск в режим immutable стоит сначало создатъ «нормальный» диск, установить и настроить систему в оптимальное состояние, желательно не подключаясь к интеренету, и только после того, как гостевая система готова — «откреплять» диск и переводить его в режим immutable.
Одним из сценариев работы может быть схема при которой используются два диска – один в режиме immutable, на котором находится сама система, второй в нормальном или write-through режиме. На первый взгляд вполне безопасный и понятный сценарий работы — каждый раз загружается «свежая» система. Но не все так прозрачно и есть некоторые нюансы.
Во первых, для immutable дисков есть одно важное исключение. Они не “обнуляются” в случае, когда прикреплены к виртуальной машине, снимок диска которой был сделан пока та была запущенна — так называемый online-snapshot. Это означает, что если например, пользователь создал immutable disk, а потом в процессе работы, создал «снэпшот», не завершив работу виртуальной машины, то начиная с упомянутого «снэпшота» все последующие операции и действия внутри системы будут носить необратимый эффект, т.к. все действия будут де-факто происходить в «снэпшоте».
В случае если основной целью является «свежая система» при каждом запуске, то от использования снэпшотов, лучше воздержаться.
Во-вторых, вышеописанное «обнуление» отдельного образа происходит только в случае, когда команда включения/отключения виртуальной машины посылается самой средой VirtualBox, а не происходит внутри гостевой ОС. Проще говоря, если например перезагрузить гостевую ОС Windows стандартным методом (Меню пуск, перезагрзить систему), то обнуление immutable диска не произойдет.
Наконец последнее и самое важное — все изменения происходившие внутри виртуальной машины сохраняются на физическом диске и остаются там до тех пор, пока виртуальная машина не будет запущена заново.
После того, как текущий контейнер установлен в режим immutable, VirtualBox перестает использовать этот контейнер и фактически диск переходит в режим «read only». Все операции записи перенаправляются в отдельный образ и каждый раз, когда виртуальная машина начинает работу этот новый «отдельный» образ «обнуляется». В реальности на жестком диске создается временный «снэпшот», который находится в папке Snapshots, соответствующей виртуальной машины, внутри которого и происходит вся работа. После завершения работы виртуальной машины вышеупомянутый временный скриншот остается нетронутым.
Рассмотрим простой пример
Боб создал виртуальную машину, настроил ОС и перевел диск в режим immutable. Боб регулярно использует свою виртуальную машину для тайного общения с Алисой. При каждом запуске, загружается «свежая» система, не содержащая никаких логов предыдущего общения, текстов, видео или фото. В очередной раз закончив переписку, Боб спокойно выключает виртуальную машину и идет спать.
Предположим также, что перед каждым запуском ОС Боб проверяет, что режим диска установлен как “immutable”.
Ева имеет доступ к компьютеру на котором установлена виртуальная машина. Ей достаточно зайти в папку Snapshots внутри директории соответствующей виртуальной машины и там будет требуемый «снэпшот».
Все что остается сделать Еве, что бы увидеть всю переписку, равно как и результат всех действий производимых Бобом внутри ОС, это перевести диск в «нормальный» режим и перед тем, как запустить виртуальную машину прикрепить к ней снэпшот. Более того, Ева может каждый день делать резервные копии таких «снэпшотов», главное, что бы это было сделано до того, как Боб снова запустит виртуальную машину.
Решением для Боба в данной ситуации будет после завершения работы, вручную удалять все содержимое папки Snapshots. Не говоря уже о том, что надо постоянно проверять в каком режиме работает диск и желательно, либо вообще заблокировать некоторые элементы GUI, что достаточно просто реализуется
Справедливости ради стоит сказать, что у тех-же Parallels, с самых ранних версий для того, что бы перевести диски из одного режима в другой необходим пароль суперпользователя, а временные «снэпшоты» удаляются моментально, после завершения работы.