<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
<chapter id="storage">
<title>Virtual storage</title>
<para>As the virtual machine will most probably expect to see a hard disk
built into its virtual computer, VirtualBox must be able to present "real"
storage to the guest as a virtual hard disk. There are presently three
methods in which to achieve this:</para>
<orderedlist>
<listitem>
<para>Most commonly, VirtualBox will use large image files on a real
hard disk and present them to a guest as a virtual hard disk. This is
described in <xref linkend="vdidetails" />.</para>
</listitem>
<listitem>
<para>Alternatively, if you have iSCSI storage servers, you can attach
such a server to VirtualBox as well; this is described in <xref
linkend="storage-iscsi" />.</para>
</listitem>
<listitem>
<para>Finally, as an advanced feature, you can allow a virtual
machine to access one of your host disks directly; this advanced feature
is described in <xref linkend="rawdisk" />.</para>
</listitem>
</orderedlist>
<para>Each such virtual storage device (image file, iSCSI target or physical
hard disk) will need to be connected to the virtual hard disk controller
that VirtualBox presents to a virtual machine. This is explained in the next
section.</para>
<sect1 id="harddiskcontrollers">
<title>Hard disk controllers: IDE, SATA (AHCI), SCSI, SAS, USB MSC</title>
called hard disk controller which drives hard disk operation and data
transfers. VirtualBox can emulate the five most common types of hard disk
controllers typically found in today's PCs: IDE, SATA (AHCI), SCSI,
SAS and USB-based mass storage devices.<footnote>
<para>SATA support was added with VirtualBox 1.6; experimental SCSI
support was added with 2.1 and fully implemented with 2.2. Generally,
storage attachments were made much more flexible with VirtualBox 3.1;
see below. Support for the LSI Logic SAS controller was added with
VirtualBox 3.2; USB mass storage devices are supported since
VirtualBox 5.0.</para>
</footnote><itemizedlist>
<listitem>
<para><emphasis role="bold">IDE (ATA)</emphasis> controllers are a
backwards compatible yet very advanced extension of the disk
worked only with hard disks, but was later extended to also support
CD-ROM drives and other types of removable media. In physical PCs,
this standard uses flat ribbon parallel cables with 40 or 80 wires.
Each such cable can connect two devices to a controller, which have
traditionally been called "master" and "slave". Typical PCs had
two connectors for such cables; as a result, support for up to four
IDE devices was most common.</para>
<para>In VirtualBox, each virtual machine may have one IDE
contoller enabled, which gives you up to four virtual storage
devices that you can attach to the machine. (By default, one of
these four -- the secondary master -- is preconfigured to be the
secondary master was fixed before VirtualBox 3.1; it is now
changeable, and the drive can be at other slots of the IDE
controller, and there can be more than one such drive.</para>
</footnote>)</para>
<para>So even if your guest operating system has no support for SCSI
or SATA devices, it should always be able to see an IDE controller.
</para>
<para>You can also select which exact type of IDE controller
hardware VirtualBox should present to the virtual machine (PIIX3,
PIIX4 or ICH6). This makes no difference in terms of performance,
but if you import a virtual machine from another virtualization
product, the operating system in that machine may expect a
particular controller type and crash if it isn't found.</para>
<para>After you have created a new virtual machine with the "New
Virtual Machine" wizard of the graphical user interface, you will
typically see one IDE controller in the machine's "Storage" settings
ports of this controller.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Serial ATA (SATA)</emphasis> is a newer
standard introduced in 2003. Compared to IDE, it supports both much
higher speeds and more devices per controller. Also, with
physical hardware, devices can be added and removed while the system
is running. The standard interface for SATA controllers is called
Advanced Host Controller Interface (<emphasis
role="bold">AHCI</emphasis>).</para>
<para>Like a real SATA controller, VirtualBox's virtual SATA
controller operates faster and also consumes fewer CPU resources than
the virtual IDE controller. Also, this allows you to connect up to
30 virtual hard disks to one machine instead of just three, as with
the VirtualBox IDE controller (with the DVD drive already attached).</para>
<para>For this reason, starting with version 3.2 and depending on
the selected guest operating system, VirtualBox uses SATA as the
default for newly created virtual machines. One virtual SATA
controller is created by default, and the default disk that is
created with a new VM is attached to this controller.<warning>
<para>The entire SATA controller and the virtual disks attached
to it (including those in IDE compatibility mode) will not be
seen by operating systems that do not have device support for
AHCI. In particular, <emphasis role="bold">there is no support
for AHCI in Windows before Windows Vista</emphasis>, so Windows
XP (even SP3) will not see such disks unless you install
additional drivers. It is possible to switch from IDE to SATA
after installation by installing the SATA drivers and changing
the controller type in the VM settings dialog.<footnote>
<para>VirtualBox recommends the Intel Matrix Storage drivers
which can be downloaded from <ulink
url="http://downloadcenter.intel.com/Product_Filter.aspx?ProductID=2101">http://downloadcenter.intel.com/Product_Filter.aspx?ProductID=2101</ulink>.</para>
</footnote></para>
</warning></para>
<para>To add a SATA controller to a machine for which it has not
been enabled by default (either because it was created by an earlier
version of VirtualBox, or because SATA is not supported by default
by the selected guest operating system), go to the "Storage" page of
the machine's settings dialog, click on the "Add Controller" button
under the "Storage Tree" box and then select "Add SATA Controller".
After this, the additional controller will appear as a separate PCI
device in the virtual machine, and you can add virtual disks to
it.</para>
<para>To change the IDE compatibility mode settings for the SATA
controller, please see <xref
linkend="vboxmanage-storagectl" />.</para>
</listitem>
<listitem>
<para><emphasis role="bold">SCSI</emphasis> is another established
industry standard, standing for "Small Computer System Interface".
SCSI was standardized as early as 1986 as a generic interface for
data transfer between all kinds of devices, including storage
devices. Today SCSI is still used for connecting hard disks and tape
devices, but it has mostly been displaced in commodity hardware. It
is still in common use in high-performance workstations and
servers.</para>
<para>Primarily for compatibility with other virtualization
software, VirtualBox optionally supports LSI Logic and BusLogic SCSI
controllers, to each of which up to 15 virtual hard disks can be
attached.</para>
<para>To enable a SCSI controller, on the "Storage" page of a
virtual machine's settings dialog, click on the "Add Controller"
button under the "Storage Tree" box and then select "Add SCSI
Controller". After this, the additional controller will appear as a
separate PCI device in the virtual machine.<warning>
<para>As with the other controller types, a SCSI controller will
only be seen by operating systems with device support for it.
Windows 2003 and later ships with drivers for the LSI Logic
controller, while Windows NT 4.0 and Windows 2000 ships with
drivers for the BusLogic controller. Windows XP ships with
drivers for neither.</para>
</warning></para>
</listitem>
<listitem>
<para><emphasis role="bold">Serial Attached SCSI (SAS)</emphasis> is
another bus standard which uses the SCSI command set. As opposed to
SCSI, however, with physical devices, serial cables are used instead
of parallel ones, which simplifies physical device connections. In
some ways, therefore, SAS is to SCSI what SATA is to IDE: it allows
for more reliable and faster connections.</para>
<para>To support high-end guests which require SAS controllers,
VirtualBox emulates a LSI Logic SAS controller, which can be enabled
much the same way as a SCSI controller. At this time, up to eight
devices can be connected to the SAS controller.</para>
<warning>
<para>As with SATA, the SAS controller will only be seen by
operating systems with device support for it. In particular,
<emphasis role="bold">there is no support for SAS in Windows
before Windows Vista</emphasis>, so Windows XP (even SP3) will not
see such disks unless you install additional drivers.</para>
</warning>
</listitem>
<listitem>
<para>The <emphasis role="bold">USB mass storage device class</emphasis>
is a standard to connect external storage devices like hard disksor flash
drives to a host through USB. All major operating systems support these
devices for a long time and ship generic drivers making third-party
drivers superfluous. In particular legacy operating systems without
support for SATA controllers may benefit from USB mass storage devices.</para>
<para>The virtual USB storage controller offered by VirtualBox works
different than the other storage controller types: When storage
controllers appear as a single PCI device to the guest with multiple
disks attached to it, the USB-based storage controller does not appear
as virtual storage controller. Each disk attached to the controller
appears as a dedicated USB device to the guest.</para>
<warning>
<para>Booting from drives attached via USB is not supported as the
BIOS lacks USB support.</para>
</warning>
</listitem>
</itemizedlist></para>
<para>In summary, VirtualBox gives you the following categories of virtual
storage slots:<orderedlist>
<listitem>
<para>four slots attached to the traditional IDE controller, which
drive);</para>
</listitem>
<listitem>
<para>30 slots attached to the SATA controller, if enabled and
supported by the guest operating system;</para>
</listitem>
<listitem>
<para>15 slots attached to the SCSI controller, if enabled and
supported by the guest operating system;</para>
</listitem>
<listitem>
<para>eight slots attached to the SAS controller, if enabled and
supported by the guest operating system.</para>
</listitem>
<listitem>
<para>eight slots attached to the virtual USB controller, if enabled and
supported by the guest operating system.</para>
</listitem>
</orderedlist></para>
<para>Given this large choice of storage controllers, you may ask yourself
which one to choose. In general, you should avoid IDE unless it is the
only controller supported by your guest. Whether you use SATA, SCSI or SAS
does not make any real difference. The variety of controllers is only
supplied for VirtualBox for compatibility with existing hardware and other
hypervisors.</para>
</sect1>
<sect1 id="vdidetails">
<title>Disk image files (VDI, VMDK, VHD, HDD)</title>
<para>Disk image files reside on the host system and are seen by the guest
systems as hard disks of a certain geometry. When a guest operating system
reads from or writes to a hard disk, VirtualBox redirects the request to
the image file.</para>
<para>Like a physical disk, a virtual disk has a size (capacity), which
must be specified when the image file is created. As opposed to a physical
disk however, VirtualBox allows you to expand an image file after
creation, even if it has data already; see <xref
linkend="vboxmanage-modifyvdi" /> for details.<footnote>
<para>Image resizing was added with VirtualBox 4.0.</para>
</footnote></para>
<para>VirtualBox supports four variants of disk image files:<itemizedlist>
<listitem>
<para>Normally, VirtualBox uses its own container format for guest
hard disks -- Virtual Disk Image (VDI) files. In particular, this
format will be used when you create a new virtual machine with a new
disk.</para>
</listitem>
<listitem>
<para>VirtualBox also fully supports the popular and open VMDK
container format that is used by many other virtualization products,
in particular, by VMware.<footnote>
<para>Initial support for VMDK was added with VirtualBox 1.4;
since version 2.1, VirtualBox supports VMDK fully, meaning that
you can create snapshots and use all the other advanced features
described above for VDI images with VMDK also.</para>
</footnote></para>
</listitem>
<listitem>
<para>VirtualBox also fully supports the VHD format used by
Microsoft.</para>
</listitem>
<listitem>
<para>Image files of Parallels version 2 (HDD format) are also
supported.<footnote>
<para>Support was added with VirtualBox 3.1.</para>
</footnote> For lack of documentation of the format, newer formats
(3 and 4) are not supported. You can however convert such image
files to version 2 format using tools provided by Parallels.</para>
</listitem>
</itemizedlist></para>
<para>Irrespective of the disk capacity and format, as briefly mentioned
in <xref linkend="gui-createvm" />, there are two options of how to create
a disk image: fixed-size or dynamically allocated.</para>
<itemizedlist>
<listitem>
<para>If you create a <emphasis role="bold">fixed-size
image</emphasis>, an image file will be created on your host system
which has roughly the same size as the virtual disk's capacity. So,
for a 10G disk, you will have a 10G file. Note that the creation of a
fixed-size image can take a long time depending on the size of the
image and the write performance of your hard disk.</para>
</listitem>
<listitem>
<para>For more flexible storage management, use a <emphasis
role="bold">dynamically allocated image</emphasis>. This will
initially be very small and not occupy any space for unused virtual
disk sectors, but will grow every time a disk sector is written to for
the first time, until the drive reaches the maximum capacity chosen
when the drive was created. While this format takes less space
initially, the fact that VirtualBox needs to expand the image file
consumes additional computing resources, so until the disk file size has
stabilized, write operations may be slower than with fixed size disks.
However, after a time the rate of growth will slow and the average penalty
for write operations will be negligible.</para>
</listitem>
</itemizedlist>
</sect1>
<sect1 id="vdis">
<title>The Virtual Media Manager</title>
disk images which are in use by virtual machines. These are often referred
to as "known media" and come from two sources:<itemizedlist>
<listitem>
<para>all media currently attached to virtual machines;</para>
</listitem>
<listitem>
<para>"registered" media for compatibility with VirtualBox versions
older than version 4.0. For details about how media registration has
changed with version 4.0, please refer to <xref
linkend="vboxconfigdata" />.</para>
</listitem>
</itemizedlist></para>
<para>The known media can be viewed and changed in the <emphasis
role="bold">Virtual Media Manager</emphasis>, which you can access from
the "File" menu in the VirtualBox main window:</para>
<para><mediaobject>
<imageobject>
width="12cm" />
</imageobject>
</mediaobject>The known media are conveniently grouped in three tabs for
the three possible formats. These formats are:</para>
<itemizedlist>
<listitem>
<para>Hard disk images, either in VirtualBox's own Virtual Disk Image
(VDI) format or in the third-party formats listed in the previous
chapter;</para>
</listitem>
<listitem>
</listitem>
<listitem>
<para>floppy images in standard RAW format.</para>
</listitem>
</itemizedlist>
<para>As you can see in the screenshot above, for each image, the Virtual
Media Manager shows you the full path of the image file and other
information, such as the virtual machine the image is currently attached
to, if any.</para>
<para>The Virtual Media Manager allows you to</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">remove</emphasis> an image from the
registry (and optionally delete the image file when doing so);</para>
</listitem>
<listitem>
<para><emphasis role="bold">"release"</emphasis> an image, that is,
detach it from a virtual machine if it is currently attached to one as
a virtual hard disk.</para>
</listitem>
</itemizedlist>
<para>Starting with version 4.0, to <emphasis role="bold">create new disk
images,</emphasis> please use the "Storage" page in a virtual machine's
settings dialog because disk images are now by default stored in each
machine's own folder.</para>
<para>Hard disk image files can be copied onto other host systems and
imported into virtual machines there, although certain guest systems
(notably Windows 2000 and XP) will require that the new virtual machine be
set up in a similar way to the old one.<note>
<para>Do not simply make copies of virtual disk images. If you import
such a second copy into a virtual machine, VirtualBox will complain
with an error, since VirtualBox assigns a unique identifier (UUID) to
each disk image to make sure it is only used once. See <xref
linkend="cloningvdis" /> for instructions on this matter. Also, if you
want to copy a virtual machine to another system, VirtualBox has an
<xref linkend="ovf" />.</para>
</note></para>
</sect1>
<sect1 id="hdimagewrites">
<title>Special image write modes</title>
<para>For each virtual disk image supported by VirtualBox, you can
determine separately how it should be affected by write operations from a
virtual machine and snapshot operations. This applies to all of the
aforementioned image formats (VDI, VMDK, VHD or HDD) and irrespective of
whether an image is fixed-size or dynamically allocated.</para>
<para>By default, images are in "normal" mode. To mark an existing image
with one of the non-standard modes listed below, use
<computeroutput>VBoxManage modifyhd</computeroutput>; see <xref
linkend="vboxmanage-modifyvdi" />. Alternatively, use VBoxManage to attach
the image to a VM and use the <computeroutput>--mtype</computeroutput>
argument; see <xref linkend="vboxmanage-storageattach" />.</para>
<orderedlist>
<listitem>
<para>With <emphasis role="bold">normal images</emphasis> (the default
setting), there are no restrictions on how guests can read from and
write to the disk.</para>
<para>When you take a snapshot of your virtual machine as described in
<xref linkend="snapshots" />, the state of such a "normal hard disk"
will be recorded together with the snapshot, and when reverting to the
snapshot, its state will be fully reset.</para>
<para>(Technically, strictly speaking, the image file itself is not
"reset". Instead, when a snapshot is taken, VirtualBox "freezes" the
image file and no longer writes to it. For the write operations from
the VM, a second, "differencing" image file is created which receives
only the changes to the original image; see the next section for
details.)</para>
<para>While you can attach the same "normal" image to more than one
virtual machine, only one of these virtual machines attached to the
same image file can be executed simultaneously, as otherwise there
would be conflicts if several machines write to the same image
file.<footnote>
<para>This restriction is more lenient now than it was before
VirtualBox 2.2. Previously, each "normal" disk image could only be
<emphasis>attached</emphasis> to one single machine. Now it can be
attached to more than one machine so long as only one of these
machines is running.</para>
</footnote></para>
</listitem>
<listitem>
<para>By contrast, <emphasis role="bold">write-through hard
disks</emphasis> are completely unaffected by snapshots: their state
is <emphasis>not</emphasis> saved when a snapshot is taken, and not
restored when a snapshot is restored.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Shareable hard disks</emphasis> are a
variant of write-through hard disks. In principle they behave exactly
snapshot is taken, and not restored when a snapshot is restored. The
difference only shows if you attach such disks to several VMs.
Shareable disks may be attached to several VMs which may run
concurrently. This makes them suitable for use by cluster filesystems
between VMs and similar applications which are explicitly prepared to
access a disk concurrently. Only fixed size images can be used in this
way, and dynamically allocated images are rejected.<warning>
<para>This is an expert feature, and misuse can lead to data loss
-- regular filesystems are not prepared to handle simultaneous
changes by several parties.</para>
</warning></para>
</listitem>
<listitem>
<para>Next, <emphasis role="bold">immutable images</emphasis> only
remember write accesses temporarily while the virtual machine is
running; all changes are lost when the virtual machine is powered on
the next time. As a result, as opposed to "normal" images, the same
immutable image can be used with several virtual machines without
restrictions.</para>
<para><emphasis>Creating</emphasis> an immutable image makes little
sense since it would be initially empty and lose its contents with
every machine restart (unless you really want to have a disk that is
always unformatted when the machine starts up). As a result, normally,
you would first create a "normal" image and then, when you deem its
contents useful, later mark it immutable.</para>
<para>If you take a snapshot of a machine with immutable images, then
on every machine power-up, those images are reset to the state of the
last (current) snapshot (instead of the state of the original
immutable image).</para>
<note>
<para>As a special exception, immutable images are
<emphasis>not</emphasis> reset if they are attached to a machine
whose last snapshot was taken while the machine was running (a
so-called "online" snapshot). As a result, if the machine's current
snapshot is such an "online" snapshot, its immutable images behave
exactly like the "normal" images described previously. To re-enable
the automatic resetting of such images, delete the current snapshot
of the machine.</para>
</note>
<para>Again, technically, VirtualBox never writes to an immutable
image directly at all. All write operations from the machine will be
directed to a differencing image; the next time the VM is powered on,
the differencing image is reset so that every time the VM starts, its
immutable images have exactly the same content.<footnote>
<para>This behavior also changed with VirtualBox 2.2. Previously,
the differencing images were discarded when the machine session
<emphasis>ended</emphasis>; now they are discarded every time the
machine is powered on.</para>
</footnote> The differencing image is only reset when the machine is
powered on from within VirtualBox, not when you reboot by requesting a
reboot from within the machine. This is also why immutable images
behave as described above when snapshots are also present, which use
differencing images as well.</para>
<para>If the automatic discarding of the differencing image on VM
startup does not fit your needs, you can turn it off using the
<computeroutput>autoreset</computeroutput> parameter of
<computeroutput>VBoxManage modifyhd</computeroutput>; see <xref
linkend="vboxmanage-modifyvdi" /> for details.</para>
</listitem>
<listitem>
<para>An image in <emphasis role="bold">multiattach mode</emphasis>
can be attached to more than one virtual machine at the same time,
even if these machines are running simultaneously. For each virtual
machine to which such an image is attached, a differencing image is
created. As a result, data that is written to such a virtual disk by
one machine is not seen by the other machines to which the image is
attached; each machine creates its own write history of the
multiattach image.</para>
<para>Technically, a "multiattach" image behaves identically to an
"immutable" image except the differencing image is not reset every
time the machine starts.</para>
<para>This mode is useful for sharing files which are almost never
written, for instance picture galleries, where every guest changes
only a small amount of data and the majority of the disk content
remains unchanged. The modified blocks are stored in differencing
images which remain reletively small and the shared content is stored
only once at the host.</para>
</listitem>
<listitem>
<para>Finally, the <emphasis role="bold">read-only image</emphasis> is
written to.</para>
</listitem>
</orderedlist>
<para>To illustrate the differences between the various types with respect
to snapshots: Assume you have installed your guest operating system in
your VM, and you have taken a snapshot. Imagine you have accidentally
infected your VM with a virus and would like to go back to the snapshot.
With a normal hard disk image, you simply restore the snapshot, and the
earlier state of your hard disk image will be restored as well (and your
virus infection will be undone). With an immutable hard disk, all it takes
is to shut down and power on your VM, and the virus infection will be
discarded. With a write-through image however, you cannot easily undo the
virus infection by means of virtualization, but will have to disinfect
your virtual machine like a real computer.</para>
<para>Still, you might find write-through images useful if you want to
preserve critical data irrespective of snapshots, and since you can attach
more than one image to a VM, you may want to have one immutable for the
operating system and one write-through for your data files.</para>
</sect1>
<sect1 id="diffimages">
<title>Differencing images</title>
<para>The previous section hinted at differencing images and how they are
used with snapshots, immutable images and multiple disk attachments. For
the inquisitive VirtualBox user, this section describes in more detail how
they work.</para>
<para>A differencing image is a special disk image that only holds the
differences to another image. A differencing image by itself is useless,
it must always refer to another image. The differencing image is then
typically referred to as a "child", which holds the differences to its
"parent".</para>
<para>When a differencing image is active, it receives all write
operations from the virtual machine instead of its parent. The
differencing image only contains the sectors of the virtual hard disk that
have changed since the differencing image was created. When the machine
reads a sector from such a virtual hard disk, it looks into the
differencing image first. If the sector is present, it is returned from
there; if not, VirtualBox looks into the parent. In other words, the
parent becomes "read-only"; it is never written to again, but it is read
from if a sector has not changed.</para>
<para>Differencing images can be chained. If another differencing image is
created for a virtual disk that already has a differencing image, then it
becomes a "grandchild" of the original parent. The first differencing
image then becomes read-only as well, and write operations only go to the
second-level differencing image. When reading from the virtual disk,
VirtualBox needs to look into the second differencing image first, then
into the first if the sector was not found, and then into the original
image.</para>
<para>There can be an unlimited number of differencing images, and each
image can have more than one child. As a result, the differencing images
can form a complex tree with parents, "siblings" and children, depending
on how complex your machine configuration is. Write operations always go
to the one "active" differencing image that is attached to the machine,
and for read operations, VirtualBox may need to look up all the parents in
the chain until the sector in question is found. You can look at such a
tree in the Virtual Media Manager:<mediaobject>
<imageobject>
width="12cm" />
</imageobject>
</mediaobject></para>
<para>In all of these situations, from the point of view of the virtual
machine, the virtual hard disk behaves like any other disk. While the
virtual machine is running, there is a slight run-time I/O overhead
because VirtualBox might need to look up sectors several times. This is
not noticeable however since the tables with sector information are always
kept in memory and can be looked up quickly.</para>
<para>Differencing images are used in the following
situations:<orderedlist>
<listitem>
<para><emphasis role="bold">Snapshots.</emphasis> When you create a
snapshot, as explained in the previous section, VirtualBox "freezes"
the images attached to the virtual machine and creates differencing
images for each of them (to be precise: one for each image that is
not in "write-through" mode). From the point of view of the virtual
machine, the virtual disks continue to operate before, but all write
operations go into the differencing images. Each time you create
another snapshot, for each hard disk attachment, another
differencing image is created and attached, forming a chain or
tree.</para>
<para>In the above screenshot, you see that the original disk image
is now attached to a snapshot, representing the state of the disk
when the snapshot was taken.</para>
<para>If you now <emphasis role="bold">restore</emphasis> a snapshot
-- that is, if you want to go back to the exact machine state that
was stored in the snapshot --, the following happens:<orderedlist>
<listitem>
<para>VirtualBox copies the virtual machine settings that were
copied into the snapshot back to the virtual machine. As a
result, if you have made changes to the machine configuration
since taking the snapshot, they are undone.</para>
</listitem>
<listitem>
<para>If the snapshot was taken while the machine was running,
it contains a saved machine state, and that state is restored
as well; after restoring the snapshot, the machine will then
be in "Saved" state and resume execution from there when it is
next started. Otherwise the machine will be in "Powered Off"
state and do a full boot.</para>
</listitem>
<listitem>
<para>For each disk image attached to the machine, the
differencing image holding all the write operations since the
current snapshot was taken is thrown away, and the original
parent image is made active again. (If you restored the "root"
snapshot, then this will be the root disk image for each
attachment; otherwise, some other differencing image descended
from it.) This effectively restores the old machine
state.</para>
</listitem>
</orderedlist></para>
<para>If you later <emphasis role="bold">delete</emphasis> a
snapshot in order to free disk space, for each disk attachment, one
of the differencing images becomes obsolete. In this case, the
differencing image of the disk attachment cannot simply be deleted.
Instead, VirtualBox needs to look at each sector of the differencing
image and needs to copy it back into its parent; this is called
"merging" images and can be a potentially lengthy process, depending
on how large the differencing image is. It can also temporarily need
a considerable amount of extra disk space, before the differencing
image obsoleted by the merge operation is deleted.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Immutable images.</emphasis> When an
image is switched to "immutable" mode, a differencing image is
created as well. As with snapshots, the parent image then becomes
read-only, and the differencing image receives all the write
operations. Every time the virtual machine is started, all the
immutable images which are attached to it have their respective
differencing image thrown away, effectively resetting the virtual
machine's virtual disk with every restart.</para>
</listitem>
</orderedlist></para>
</sect1>
<sect1 id="cloningvdis">
<title>Cloning disk images</title>
<para>You can duplicate hard disk image files on the same host to quickly
produce a second virtual machine with the same operating system setup.
However, you should <emphasis>only</emphasis> make copies of virtual disk
images using the utility supplied with VirtualBox; see <xref
linkend="vboxmanage-clonevdi" />. This is because VirtualBox assigns a
unique identity number (UUID) to each disk image, which is also stored
inside the image, and VirtualBox will refuse to work with two images that
use the same number. If you do accidentally try to reimport a disk image
which you copied normally, you can make a second copy using VirtualBox's
utility and import that instead.</para>
<para>Note that newer Linux distributions identify the boot hard disk from
the ID of the drive. The ID VirtualBox reports for a drive is determined
from the UUID of the virtual disk image. So if you clone a disk image and
try to boot the copied image the guest might not be able to determine its
own boot disk as the UUID changed. In this case you have to adapt the disk
ID in your boot loader script (for example
like this:<screen>scsi-SATA_VBOX_HARDDISK_VB5cfdb1e2-c251e503</screen></para>
</sect1>
<sect1 id="iocaching">
<title>Host I/O caching</title>
<para>Starting with version 3.2, VirtualBox can optionally disable the I/O
caching that the host operating system would otherwise perform on disk
image files.</para>
<para>Traditionally, VirtualBox has opened disk image files as normal
files, which results in them being cached by the host operating system
like any other file. The main advantage of this is speed: when the guest
OS writes to disk and the host OS cache uses delayed writing, the write
operation can be reported as completed to the guest OS quickly while the
host OS can perform the operation asynchronously. Also, when you start a
VM a second time and have enough memory available for the OS to use for
caching, large parts of the virtual disk may be in system memory, and the
VM can access the data much faster.</para>
<para>Note that this applies only to image files; buffering never occurred
for virtual disks residing on remote iSCSI storage, which is the more common
scenario in enterprise-class setups (see <xref
linkend="storage-iscsi" />).</para>
<para>While buffering is a useful default setting for virtualizating a few
machines on a desktop computer, there are some disadvantages to this
approach:<orderedlist>
<listitem>
<para>Delayed writing through the host OS cache is less secure. When
the guest OS writes data, it considers the data written even though
it has not yet arrived on a physical disk. If for some reason the
write does not happen (power failure, host crash), the likelihood of
data loss increases.</para>
</listitem>
<listitem>
<para>Disk image files tend to be very large. Caching them can
therefore quickly use up the entire host OS cache. Depending on the
efficiency of the host OS caching, this may slow down the host
immensely, especially if several VMs run at the same time. For
example, on Linux hosts, host caching may result in Linux delaying
all writes until the host cache is nearly full and then writing out
all these changes at once, possibly stalling VM execution for
minutes. This can result in I/O errors in the guest as I/O requests
time out there.</para>
</listitem>
<listitem>
<para>Physical memory is often wasted as guest operating systems
typically have their own I/O caches, which may result in the data
being cached twice (in both the guest and the host caches) for
little effect.</para>
</listitem>
</orderedlist></para>
<para>If you decide to disable host I/O caching for the above reasons,
VirtualBox uses its own small cache to buffer writes, but no read caching
since this is typically already performed by the guest OS. In addition,
VirtualBox fully supports asynchronous I/O for its virtual SATA, SCSI and
SAS controllers through multiple I/O threads.</para>
<para>Since asynchronous I/O is not supported by IDE controllers, for
performance reasons, you may want to leave host caching enabled for your
VM's virtual IDE controllers.</para>
<para>For this reason, VirtualBox allows you to configure whether the host
I/O cache is used for each I/O controller separately. Either uncheck the
"Use host I/O cache" box in the "Storage" settings for a given virtual
storage controller, or use the following VBoxManage command to disable the
host I/O cache for a virtual storage controller:<screen>VBoxManage storagectl "VM name" --name <controllername> --hostiocache off</screen></para>
<para>See <xref linkend="vboxmanage-storagectl" /> for details.</para>
<para>For the above reasons also, VirtualBox now uses SATA controllers by
default for new virtual machines.</para>
</sect1>
<sect1 id="storage-bandwidth-limit">
<title>Limiting bandwidth for disk images</title>
<para>Starting with version 4.0, VirtualBox allows for limiting the
maximum bandwidth used for asynchronous I/O. Additionally it supports
sharing limits through bandwidth groups for several images. It is possible
to have more than one such limit.</para>
<para>Limits are configured through
<computeroutput>VBoxManage</computeroutput>. The example below creates a
bandwidth group named "Limit", sets the limit to 20 MB/s and assigns the
group to the attached disks of the VM:<screen>VBoxManage bandwidthctl "VM name" add Limit --type disk --limit 20M
VBoxManage storageattach "VM name" --storagectl "SATA" --port 0 --device 0 --type hdd
--medium disk1.vdi --bandwidthgroup Limit
VBoxManage storageattach "VM name" --storagectl "SATA" --port 1 --device 0 --type hdd
<para>All disks in a group share the bandwidth limit, meaning that in the
example above the bandwidth of both images combined can never exceed 20
MB/s. However, if one disk doesn't require bandwidth the other can use the
remaining bandwidth of its group.</para>
<para>The limits for each group can be changed while the VM is running,
with changes being picked up immediately. The example below changes the
limit for the group created in the example above to 10 MB/s:<screen>VBoxManage bandwidthctl "VM name" set Limit --limit 10M</screen></para>
</sect1>
<sect1 id="storage-cds">
medium configuration is changeable at runtime. You can select between
three options to provide the medium data:<itemizedlist>
<listitem>
<para><emphasis role="bold">Host Drive</emphasis> defines that the
guest can read from the medium in the host drive.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Image file</emphasis> (typically an ISO
file) gives the guest read-only access to the data in the
image.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Empty</emphasis> stands for a drive
without an inserted medium.</para>
</listitem>
</itemizedlist></para>
<para>Changing between the above, or changing a medium in the host drive
that is accessed by a machine, or changing an image file will signal a
medium change to the guest operating system, which can then react to the
change (e.g. by starting an installation program).</para>
<para>Medium changes can be prevented by the guest, and VirtualBox
reflects that by locking the host drive if appropriate. You can force a
medium removal in such situations via the VirtualBox GUI or the VBoxManage
command line tool. Effectively this is the equivalent of the emergency
the guest OS can issue error messages, just like on real hardware, and
guest applications may misbehave. Use this with caution.<note>
<para>The identification string of the drive provided to the guest
(which, in the guest, would be displayed by configuration tools such
as the Windows Device Manager) is always "VBOX CD-ROM", irrespective
of the current configuration of the virtual drive. This is to prevent
hardware detection from being triggered in the guest operating system
every time the configuration is changed.</para>
</note></para>
and DVD formats only. As an experimental feature, for additional
host drive by enabling "passthrough" mode. Depending on the host hardware,
this may enable three things to work, potentially:<itemizedlist>
<listitem>
</listitem>
<listitem>
<para>playing audio CDs;</para>
</listitem>
<listitem>
<para>playing encrypted DVDs.</para>
</listitem>
</itemizedlist></para>
<para>There is a "Passthrough" checkbox in the GUI dialog for configuring
the media attached to a storage controller, or you can use the
<computeroutput>--passthrough</computeroutput> option with
<computeroutput>VBoxManage storageattach</computeroutput>; see <xref
linkend="vboxmanage-storageattach" /> for details.</para>
<para>Even if pass-through is enabled, unsafe commands, such as updating
the drive firmware, will be blocked. Video CD formats are never supported,
not even in passthrough mode, and cannot be played from a virtual
machine.</para>
<para>On Solaris hosts, pass-through requires running VirtualBox with real
root permissions due to security measures enforced by the host.</para>
</sect1>
<sect1 id="storage-iscsi">
<title>iSCSI servers</title>
<para>iSCSI stands for "Internet SCSI" and is a standard that allows for
with the advent of Gigabit Ethernet, it has become affordable to attach
iSCSI storage servers simply as remote hard disks to a computer network.
In iSCSI terminology, the server providing storage resources is called an
"iSCSI target", while the client connecting to the server and accessing
its resources is called "iSCSI initiator".</para>
<para>VirtualBox can transparently present iSCSI remote storage to a
virtual machine as a virtual hard disk. The guest operating system will
not see any difference between a virtual disk image (VDI file) and an
iSCSI target. To achieve this, VirtualBox has an integrated iSCSI
initiator.</para>
<para>VirtualBox's iSCSI support has been developed according to the iSCSI
standard and should work with all standard-conforming iSCSI targets. To
use an iSCSI target with VirtualBox, you must use the command line; see
<xref linkend="vboxmanage-storageattach" />.</para>
</sect1>
</chapter>