Advanced TopicsVirtualBox configuration data
For each system user, VirtualBox stores configuration data in the user’s home directory, as per the conventions of the host operating system:
• On Linux, this is $HOME/.VirtualBox.
• On Windows, this is %HOMEDRIVE%%HOMEPATH%\.VirtualBox; typically something like C:\Documents and Settings\Username\.VirtualBox.
VirtualBox creates this configuration directory automatically, if necessary. Optionally, you can supply an alternate configuration directory by setting the
VBOX_USER_HOME environment variable.
In the configuration directory, VirtualBox.xml is the main configuration file.
This includes global configuration options and the media and virtual machine registry. The media registry links to all CD/DVD, oppy and disk images that have been added to the Virtual Disk Manager. For each registered VM, there is one entry which points to the VM configuration file, also in XML format.
You can globally change some of the locations where VirtualBox keeps extra configuration and data by selecting “Global settings” from the “File” menu in the VirtualBox main window. Then, in the window that pops up, click on the “General” tab.
• Virtual machine settings and files are, by default, saved as XML files in a subdirectory of the .VirtualBox/Machines directory. You can change the location
of this main “Machines” folder in the “Global settings” dialog.
By default, for each virtual machine, VirtualBox uses another subdirectory of the “Machines” directory that carries the same name as the virtual machine. As a result, your virtual machine names must conform to the conventions of your operating system for valid file names. For example, a machine called “Fedora 6” would, by default, have its settings saved in .VirtualBox/Machines/Fedora 6/Fedora 6.xml.
The virtual machine directory will be renamed if you change the machine name.
If you do not wish this to happen, you can create the machine us-
ing VBoxManage createvm with the -basefolder option. In this case, the folder name will never change.
• VirtualBox keeps snapshots and saved states in another special folder for each virtual machine. By default, this is a subfolder of the virtual machine folder
called Snapshots – in our example, .VirtualBox/Machines/Fedora 6/Snapshots. You can change this setting for each machine using VBoxManage as well.
• VDI container files are, by default, created in the .VirtualBox/VDI directory.
In particular, this directory is used when the “Create new virtual disk” wizard is started to create a new VDI file. Changing this default is probably most useful
if the disk containing your home directory does not have enough room to hold your VDI files, which can grow very large.
Automated Windows guest logons (VBoxGINA)
When Windows is running in a virtual machine, it might be desirable to perform coordinated and automated logons of guest operating systems using credentials from a master logon system. (With “credentials”, we are referring to logon information consisting of user name, password and domain name, where each value might be empty.)
Since Windows NT, Windows has provided a modular system logon subsystem (“Winlogon”) which can be customized and extended by means of so-called GINA modules (Graphical Identification and Authentication). The VirtualBox Guest Additions for Windows come with such a GINA module and therefore allow Windows guesets to perform automated logons.
To activate the GINA module, first install the Guest Additions. You will then find the GINA module – a file called VBoxGINA.dll – in the Additions target directory.
Copy this file to the Windows SYSTEM32 directory. Then, in the registry, create the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\
Winlogon\GinaDLL
with a value of VBoxGINA.dll.
Note: The VirtualBox GINA is implemented as a wrapper around the standard Windows GINA (MSGINA.DLL) so it will most likely not work correctly with 3rd party GINA modules.
Secure labeling with VBoxSDL
When running guest operating systems in fullscreen mode, the guest operating system usually has control over the whole screen. This could present a security risk as the guest operating system might fool the user into thinking that it is either a different system (which might have a higher security level) or it might present messages on the screen that appear to stem from the host operating system.
In order to protect the user against the abovementioned security risks, the secure labeling feature has been developed. Secure labeling is currently available only for VBoxSDL. When enabled, a portion of the display area is reserved for a label in which a user defined message is displayed. The label height in set to 20 pixels in VBoxSDL.
The label font color and background color can be optionally set as hexadecimal RBG color values. The following syntax is used to enable secure labeling:
VBoxSDL -securelabel -seclabelfnt ~/fonts/arial.ttf \
-seclabelsiz 14 "Windows XP" \
-seclabelfbcol 00FF00 -seclabelbgcol 00FFFF
In addition to enabling secure labeling, a TrueType font has to be supplied.
Typically, full screen resolutions are limited to certain “standard” geometries such as 1024 x 768. Adding the secure label with a height of 20 pixels would therefore require the resolution to be 1024 x 788 which is either not possible for results in suboptimal display quality. In most cases, VBoxSDL would chose the next higher resolution, e.g. 1280 x 1024 and the guest’s screen would not cover the whole display surface. If VBoxSDL is unable to choose a higher resolution, the secure label will be painted on top of the guest’s screen surface. In order to address this problem, a feature called “Y offset” has been implemented. This takes the height of the secure label and provides custom video modes to the guest that are reduced by the height of the label so that guest height + label height results in a valid native display resolution. For Windows guests, the VirtualBox Guest Additions automatically provide the reduced video modes. In addition to that, the VESA BIOS has been adjusted to duplicate its standard mode table with adjusted resolutions. The adjusted mode IDs can be calculated using the following formula:
reduced_modeid = modeid + 0x30
For example, in order to start Linux with 1024 x 748 x 16, the standard mode 0x117
(1024 x 768 x 16) is used as a base. The Linux video mode kernel parameter can then be calculated using:
vga = 0x200 | 0x117 + 0x30
vga = 839
The reason for duplicating the standard modes instead of only supplying the adjusted modes is that most guest operating systems require the standard VESA modes
to be fixed and refuse to start with different modes.
When using the X.org VESA driver, custom modelines have to be calculated and added to the configuration (usually in /etc/X11/xorg.conf. A handy tool to determine
modeline entries can be found at http://www.tkk.fi/Misc/Electronics/
faq/vga2rgb/calc.html.
Custom VESA resolutions
Apart from the standard VESA resolutions, the VirtualBox VESA BIOS allows you to add up to 16 custom video modes which will be reported to the guest operating system.
When using Windows guests with the VirtualBox Guest Additions, a custom graphics driver will be used instead of the fallback VESA solution so this information does not apply.
Additional video modes can be configured for each VM using the extra data facility.
The extra data key is called CustomVideoMode
VBoxManage setextradata "Windows XP" \
"CustomVideoMode1" "1400x1050x16"
The VESA mode IDs for custom video modes start at 0x160. In order to use the above defined custom video mode, the following command line has be supplied to Linux:
vga = 0x200 | 0x160
vga = 864
For guest operating systems with VirtualBox Guest Additions, a custom video mode can be set using the video mode hint feature.
Releasing modifiers with VBoxSDL on Linux
When switching from a X virtual terminal (VT) to another VT using Ctrl-Alt-Fx while the VBoxSDL window has the input focus, the guest will receive Ctrl and Alt keypress events without receiving the corresponding key release events. This is an architectural limitation of Linux. In order to reset the modifier keys, it is possible to send SIGUSR1 to the VBoxSDL main thread (first entry in the ps list). For example, when switching away to another VT and saving the virtual machine from this terminal, the following sequence can be used to make sure the VM is not saved with stuck modifiers:
kill -usr1
./VBoxManage controlvm "Windows 2000" savestate
Using serial ports
Starting with version 1.4, VirtualBox can provide several serial ports to the guest. Up to 4 serial ports can be configured. The guest sees a standard 16450-type serial port.
Both receiving and transmitting data is supported. On a Windows host, the data is sent and received through a named pipe; on a Linux host, a local domain socket is used instead. You can configure whether VirtualBox acts as a server or as a client of such a named pipe or local domain socket.
Currently, you can attach only a single host application to the named pipe or local domain socket associated with a particular serial port. The current configuration method is through the generic configuration facility of VBoxManage. In the future, this may be replaced with a more convenient mechanism.
VBoxManage setextradata "YourVM"
"VBoxInternal/Devices/serial/0/Config/IRQ" 4
VBoxManage setextradata "YourVM"
"VBoxInternal/Devices/serial/0/Config/IOBase" 0x3f8
VBoxManage setextradata "YourVM"
"VBoxInternal/Devices/serial/0/LUN#0/Driver" Char
VBoxManage setextradata "YourVM"
"VBoxInternal/Devices/serial/0/LUN#0/AttachedDriver/Driver" NamedPipe
VBoxManage setextradata "YourVM"
"VBoxInternal/Devices/serial/0/LUN#0/AttachedDriver/Config/Location"
"\\.\pipe\vboxCOM1"
VBoxManage setextradata "YourVM"
"VBoxInternal/Devices/serial/0/LUN#0/AttachedDriver/Config/IsServer"
This example sets up a serial port in the guest with the default settings for COM1 (IRQ 4, I/O address 0x3f8) and the Location setting assumes that this configuration is used on a Windows host, because the Windows named pipe syntax is used. Keep in mind that on Windows hosts a named pipe must always start with \\.\pipe\“. On Linux the same config settings apply, except that the path name for the Location can be chosen more freely. Local domain sockets can be placed anywhere, provided the user running VirtualBox has the permission to create a new file in the directory. The final command above defines that VirtualBox acts as a server, i.e. it creates the named pipe itself instead of connecting to an already existing one.
On Linux there are various tools which can connect to a local domain socket or create one in server mode. The most exible tool is socat and is available as part of many distributions. For Windows there is a helper program called VMWare Serial Line Gateway, available for download at http://www.l4ka.org/tools/vmwaregateway.
php. This tool provides a fixed server mode named pipe at \\.\pipe\vmwaredebug and connects incoming TCP connections on port 567 with the named pipe.
Using a raw host hard disk from a guest Starting with version 1.4, as an alternative to using virtual disk images (as described in detail in chapter 5, Virtual storage, page 51), VirtualBox can also present either entire physical hard disks or selected partitions thereof as virtual disks to virtual machines.
With VirtualBox, this type of access is called “raw hard disk access”; it allows a guest operating system to access its virtual hard disk much more quickly than with disk images, since data does not have to pass through two file systems (the one in the guest and the one on the host).
Warning: Raw hard disk access is for expert users only. Incorrect use or use of an outdated configuration can lead to total loss of data on the physical disk. Most importantly, do not attempt to boot the partition with the currently running host operating system in a guest. This will lead to severe data corruption.
Raw hard disk access – both for entire disks and individual partitions – is implemented as part of the VMDK image format support (see chapter 5.2, VMDK image files, page 53). As a result, you will need to create a special VMDK image file which defines where the data will be stored. After creating such a special VMDK image, you can use it like a regular virtual disk image. For example, you can use the Virtual Disk Manager (chapter 3.5, The Virtual Disk Manager, page 34) or VBoxManage to assign the image to a virtual machine.
Access to entire physical hard disk
While this variant is the simplest to set up, you must be aware that this will give a guest operating system direct and full access to an entire physical disk. If your host operating system is also booted from this disk, please take special care to not access the partition from the guest at all. On the positive side, the physical disk can be repartitioned in arbitrary ways without having to recreate the image file that gives access to the raw disk.
To create an image that represents an entire physical hard disk (which will not contain any actual data, as this will all be stored on the physical disk), on a Linux host, use the command VBoxManage internalcommands createrawvmdk -filename /path/to/file.vmdk
-rawdisk /dev/sda
This creates the image /path/to/file.vmdk (must be absolute), and all data will be read and
written from /dev/sda.
On a Windows host, instead of the above device specification, use e.g.
\\.\PhysicalDrive0.
Creating the image requires read/write access for the given device. Read/write access is also later needed when using the image from a virtual machine.
Just like with regular disk images, this does not automatically register the newly created image in the internal registry of hard disks. If you want this done automatically, add -register:
VBoxManage internalcommands createrawvmdk -filename /path/to/file.vmdk
-rawdisk /dev/sda -register
After registering, you can assign the newly created image to a virtual machine with VBoxManage modifyvm WindowsXP -hda /path/to/file.vmdk
When this is done the selected virtual machine will boot from the specified physical disk.
Access to individual physical hard disk partitions
This “raw partition support” is quite similar to the “full hard disk” access described above. However, in this case, any partitioning information will be stored inside the VMDK image, so you can e.g. install a different boot loader in the virtual hard disk without affecting the host’s partitioning information. While the guest will be able to see all partitions that exist on the physical disk, access will be filtered in that reading from partitions for which no access is allowed the partitions will only yield zeroes, and all writes to them are ignored.
To create a special image for raw partition support (which will contain a small amount of data, as already mentioned), on a Linux host, use the command
VBoxManage internalcommands createrawvmdk -filename /path/to/file.vmdk -rawdisk /dev/sda -partitions 1,5
As you can see, the command is identical to the one for “full hard disk” access, except for the additional -partitions parameter. This example would create the
image /path/to/file.vmdk (which, again, must be absolute), and partitions 1 and 5 of /dev/sda would be made accessible to the guest.
VirtualBox uses the same partition numbering as your Linux host. As a result, the numbers given in the above example would refer to the first primary partition and the first logical drive in the extended partition, respectively.
On a Windows host, instead of the above device specification, use e.g.
\\.\PhysicalDrive0. Partition numbers are the same on Linux and Windows
hosts.
The numbers for the list of partitions can be taken from the output of VBoxManage internalcommands listpartitions -rawdisk /dev/sda
The output lists the partition types and sizes to give the user enough information to identify the partitions necessary for the guest.
Images which give access to individual partitions are specific to a particular host disk setup. You cannot transfer these images to another host; also, whenever the host partitioning changes, the image must be recreated.
Creating the image requires read/write access for the given device. Read/write access is also later needed when using the image from a virtual machine. If this is not feasible, there is a special variant for raw partition access (currently only available on Linux hosts) that avoids having to give the current user access to the entire disk. To set up such an image, use VBoxManage internalcommands createrawvmdk -filename /path/to/file.vmdk
-rawdisk /dev/sda -partitions 1,5 -relative.
When used from a virtual machine, the image will then refer not to the entire disk, but only to the individual partitions (in the example /dev/sda1 and /dev/sda5). As a consequence, read/write access is only required for the affected partitions, not for the entire disk. During creation however, read-only access to the entire disk is required to obtain the partitioning information.
-rawdisk /dev/sda -partitions 1,5 -mbr winxp.mbr
The modified MBR will be stored inside the image, not on the host disk.
For each of the above variants, you can register the resulting image for immediate use in VirtualBox by adding -register to the respective command line. The image will then immediately appear in the list of registered disk images. An example is VBoxManage internalcommands createrawvmdk -filename /path/to/file.vmdk
-rawdisk /dev/sda -partitions 1,5 -relative -register
which creates an image referring to individual partitions, and registers it when the
image is successfully created.
0 comments:
Post a Comment