Как найти файлы виртуальной машины

%userprofile%VirtualBox VMs
%userprofile%.VirtualBox

20 гб на каждую

Это виртуальные диски такого размера, а не настройки виртуальных машин. Диски могут быть разных типов, соответственно и расширение у них будет разное. Обычно находятся в папке виртуальной машины, но могут быть где угодно (вы же их создавали — вспоминайте где). Обычно при удалении виртуальной машины VirtualBox запрашивает и удаление соответствующего виртуального диска (по-умолчанию «Да» — вы же говорили «Нет»).

Надо искать на ПК файлы .vdi, это и есть файл системы, а не .vbox как говорили ранее.

папка по умолчанию для размещения виртуальных машин в virtualBox может быть различной.
поищите на Вашем компьютере файлы с расширением «.vbox»
это файлы с описаниями виртуальных машин.
все файлы внутри папки содержащей файл .vbox» и будут составлять одну виртуальную машину.
Т.е. для удаления машины надо удалить папку в которой содержится файл с расширением «.vbox»

Если не знаете как искать файлы вот статья
pc-users.ru/windows/poisk-fajlov-v-windows-7.html
в поле поиска ввести «*.vbox»

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

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

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

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

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

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

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

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

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

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

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

VirtualBox использует файлы формата XML для хранения настройки машины и глобальных настроек VirtualBox.xml .

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

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

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

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

   Примечание

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

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

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

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.

• 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 ).

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

• С 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.

Подробнее о программной виртуализации

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

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.

Подробнее об аппаратной виртуализации

• В 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 режиме выполняется гостевая ОС.

Nested paging and VPIDs

• Новая функцию под названием «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» .