source: vbox/trunk/doc/manual/fr_FR/user_Storage.xml@ 35147

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
<chapter id="storage">
  <title>Stockage virtuel</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 experimental 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</title>

    <para>In a real PC, hard disks and CD/DVD drives are connected to a device
    called hard disk controller which drives hard disk operation and data
    transfers. VirtualBox can emulate the three most common types of hard disk
    controllers typically found in today's PCs: IDE, SATA (AHCI) and
    SCSI.<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.</para>
      </footnote><itemizedlist>
        <listitem>
          <para><emphasis role="bold">IDE (ATA)</emphasis> controllers have
          been in use since the 1980s. Initially, this type of interface
          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 hard disk
          controllers have two connectors for such cables; as a result, most
          PCs support up to four devices.</para>

          <para>In VirtualBox, each virtual machine has one IDE controller
          enabled by default, 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
          machine's virtual CD/DVD drive, but this can be changed.<footnote>
              <para>The assignment of the machine's CD/DVD drive to 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 the default IDE
          controller that is enabled by default.</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 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 where the virtual CD/DVD drive will be attached
          to one of the four 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 hard disk 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>For compatibility reasons, AHCI controllers by default operate
          the disks attached to it in a so-called "IDE compatibility mode",
          unless SATA support is explicitly requested. "IDE compatibility
          mode" only means that the drives can be seen and operated by the
          computer's BIOS. Still, disks assigned to those slots will operate
          in full-speed AHCI mode once the guest operating system has loaded
          its AHCI device driver.</para>

          <para>Like a real SATA controller, VirtualBox's virtual SATA
          controller operates faster and also consumes less 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).
          Of these, the first four (numbered 0-3 in the graphical user
          interface) are operated in IDE compatibility mode by default.</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 SP2) 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
              http://downloadcenter.intel.com/Product_Filter.aspx?ProductID=2101
              </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
          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-storage" />.</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.<footnote>
              <para>Support for the LSI Logic SAS controller was added with
              VirtualBox 3.2.</para>
            </footnote></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 SP2) will not
            see such disks unless you install additional drivers.</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
          are always present (one of which typically is a virtual CD/DVD
          drive);</para>
        </listitem>

        <listitem>
          <para>30 slots attached to the SATA controller, if enabled and
          provided that your guest operating system can see it; these slots
          can either be<orderedlist>
              <listitem>
                <para>in IDE compatibility mode (by default, slots 0-3)
                or</para>
              </listitem>

              <listitem>
                <para>in SATA mode;</para>
              </listitem>
            </orderedlist></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>
      </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.</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>Note that when you create an image file, its size needs to be
    specified, which represents a fixed geometry of the virtual disk. It is
    therefore not possible to change the size of the virtual hard disk
    later.</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 format, as briefly mentioned in <xref
    linkend="gui-createvm" />, there are two options of how to create a disk
    image: fixed-size or dynamically expanding.</para>

    <itemizedlist>
      <listitem>
        <para>If you create a <emphasis role="bold">fixed-size
        image</emphasis> of e.g. 10 GB, an image file of roughly the same size
        will be created on your host system. 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 expanding image</emphasis>. This will
        initially be very small and not occupy any space for unused virtual
        disk sectors, but the image file will grow every time a disk sector is
        written to for the first time. While this format takes less space
        initially, the fact that VirtualBox needs to constantly expand the
        image file consumes additional computing resources, so until the disk
        has fully expanded, write operations are slower than with fixed size
        disks. However, after a dynamic disk has fully expanded, the
        performance penalty for read and write operations is
        negligible.</para>
      </listitem>
    </itemizedlist>
  </sect1>

  <sect1 id="vdis">
    <title>The Virtual Media Manager</title>

    <para>VirtualBox keeps an internal registry of all available hard disk,
    CD/DVD-ROM and floppy disk images. This registry 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>
          <imagedata align="center" fileref="images/virtual-disk-manager.png"
                     width="10cm" />
        </imageobject>
      </mediaobject>The window shows you all images that are currently
    registered with VirtualBox, 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 above;</para>
      </listitem>

      <listitem>
        <para>CD/DVD images in standard ISO format;</para>
      </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>create new hard disk images using the <emphasis
        role="bold">"New"</emphasis> button; this will bring up the "Create
        Disk Image" wizard already described in <xref
        linkend="gui-createvm" />;</para>
      </listitem>

      <listitem>
        <para>import existing image files from your hard drive into VirtualBox
        using the <emphasis role="bold">"Add"</emphasis> button;</para>
      </listitem>

      <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>We recommend that you maintain two special folders on your system
    for keeping images: one for hard disk image files (which can, in the case
    of dynamically expanding images, grow to considerable sizes), and one for
    ISO files (which were probably downloaded from the Internet).</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
        import/export facility that might be better suited for your needs; see
        <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 use
    special commands how write operations from the virtual machine should
    affect the image and how snapshots should affect it. 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
    expanding.</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>

        <para>To <emphasis>create</emphasis> a disk image in VDI format as
        "write-through", use the <computeroutput>VBoxManage
        createhd</computeroutput> command; see <xref
        linkend="vboxmanage-createvdi" />. To mark an
        <emphasis>existing</emphasis> image as write-through, use
        <computeroutput>VBoxManage modifyhd</computeroutput>; see <xref
        linkend="vboxmanage-modifyvdi" />.</para>
      </listitem>

      <listitem>
        <para><emphasis role="bold">Shareable hard disks</emphasis> are a
        variant of write-through hard disks. In principle they behave exactly
        the same, i.e. their state is <emphasis>not</emphasis> saved when a
        snapshot is taken, and not restored when a snapshot is restored. The
        difference only shows if you attach such disks to several VMs.
        Shareable VMs 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 growing images are rejected.</para>

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

        <para>To <emphasis>create</emphasis> a disk image in VDI format as
        "shareable", use the <computeroutput>VBoxManage
        createhd</computeroutput> command; see <xref
        linkend="vboxmanage-createvdi" />. To mark an
        <emphasis>existing</emphasis> image as shareable, use
        <computeroutput>VBoxManage modifyhd</computeroutput>; see <xref
        linkend="vboxmanage-modifyvdi" />.</para>
      </listitem>

      <listitem>
        <para>Finally, <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 using
        <computeroutput>VBoxManage modifyhd</computeroutput>; again, please
        see <xref linkend="vboxmanage-modifyvdi" />. Alternatively, open an
        existing image in "immutable" mode using <computeroutput>VBoxManage
        openmedium</computeroutput>; see <xref
        linkend="vboxmanage-registerimage" />.</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>
    </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>
          <imagedata align="center" fileref="images/virtual-disk-manager2.png"
                     width="10cm" />
        </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
    <computeroutput>/boot/grub/menu.lst</computeroutput>). The disk ID looks
    like this:<screen>scsi-SATA_VBOX_HARDDISK_VB5cfdb1e2-c251e503</screen></para>

    <para>The ID for the copied image can be determined with <screen>hdparm -i /dev/sda</screen></para>
  </sect1>

  <sect1 id="iocaching">
    <title>Disk images and I/O caching</title>

    <para>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 occured
    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>As a result, starting with version 3.2, VirtualBox allows you to
    optionally disable host I/O caching of disk image files. In that case,
    VirtualBox uses its own small cache to buffer writes, but there is no read
    caching since this is 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 &lt;vm&gt; --name &lt;controllername&gt; --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>

    <note>
      <para>Disabling the host I/O caches will currently yield poor
      performance with VHD and sparse VMDK files. See <xref
      linkend="KnownIssues" /> for details.</para>
    </note>
  </sect1>

  <sect1 id="storage-cds">
    <title>CD/DVD drive operation</title>

    <para>The virtual CD/DVD drive(s) by default support only reading. The
    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. Medium changes of
          the host drives are signalled to the guest.</para>
        </listitem>

        <listitem>
          <para><emphasis role="bold">Image file</emphasis> gives the guest
          read-only access to the image data (often referred to as ISO image).
          A medium change is signalled when switching to a different image or
          selecting another option.</para>
        </listitem>

        <listitem>
          <para><emphasis role="bold">Empty</emphasis> stands for a drive
          without an inserted medium. The drive responds as usual to this
          situation, however no data can be read.</para>
        </listitem>
      </itemizedlist></para>

    <para>As mentioned, the medium change signalling depends on the selected
    option for the medium. 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 situation via the VirtualBox GUI or the
    VBoxManage command line tool. Effectively this is the equivalent of the
    emergency eject which many CD/DVD drives provide, with all associated side
    effects. The guest OS can issue error messages in this case, just like on
    real hardware. Use with caution.</para>

    <para>In any case, only data media is supported for CD/DVD drives. This
    means that all data CD formats and all DVD formats can be used in
    principle. Since host DVD drives refuse to read encrypted DVD video media,
    you cannot play such videos with the regular CD/DVD drive emulation. You
    may be able to get it working with the experimental passthrough support
    described in <xref linkend="storage-write-cds" />.</para>

    <para>Audio CD and video CD formats are not supported, which means you
    cannot play such media from a virtual machine.</para>
  </sect1>

  <sect1 id="storage-write-cds">
    <title>Writing CDs and DVDs using the host drive</title>

    <para>When you attach your host's CD/DVD drive to a virtual machine (see
    <xref linkend="settings-storage" />), this normally gives the machine
    read-only access to the host drive. This prevents the guest from writing
    to the host drive. In particular, you cannot burn CDs and DVDs from the
    guest this way.</para>

    <para>As an experimental feature (which currently works for data media
    only, audio and video CD formats are not supported), it is possible to
    give the guest access to the CD/DVD writing features of the host drive (if
    available). There is a "Passthrough" checkbox in the GUI dialog for
    configuring the media attached to a storage controller, or you can use the
    command line:</para>

    <screen>VBoxManage storageattach &lt;uuid|vmname&gt;
                        --storagectl &lt;name&gt;
                        --port &lt;number&gt;
                        --device &lt;number&gt;
                        [--type &lt;dvddrive|hdd|fdd&gt;
                         --medium &lt;none|emptydrive|uuid|filename|host:&lt;drive&gt;&gt;]
                        [--passthrough &lt;on|off&gt;]
                        [--forceunmount]</screen>

    <para>See also <xref linkend="vboxmanage-storage" />.</para>

    <para>Even if pass-through is enabled, unsafe commands, such as updating
    the drive firmware, will be blocked. On some host drives the pass-through
    feature allows playing encrypted DVD video media.</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>
    <title id="storage-iscsi">iSCSI servers</title>

    <para>iSCSI stands for "Internet SCSI" and is a standard that allows for
    using the SCSI protocol over Internet (TCP/IP) connections. Especially
    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 first register it as a
    virtual hard disk with <computeroutput>VBoxManage</computeroutput>; see
    <xref linkend="vboxmanage-addiscsidisk" />. The target will show up in the
    list of disk images, as described in <xref linkend="vdis" />, and can thus
    be attached to one of the VM's three hard disk slots the usual way.</para>

    <sect2>
      <title id="iscsi-intnet">Access iSCSI targets via Internal
      Networking</title>

      <para>As an experimental feature, VirtualBox allows for accessing an
      iSCSI target running in a virtual machine which is configured for using
      Internal Networking mode (as described in <xref
      linkend="network_internal" />). The setup of the virtual machine which
      uses such an iSCSI target is done as described above. The only
      difference is that the IP address of the target must be specified as a
      numeric IP address.</para>

      <para>The IP stack accessing Internal Networking must be configured in
      the virtual machine which accesses the iSCSI target. A free static IP
      and a MAC address not used by other virtual machines must be chosen. In
      the example below, adapt the name of the virtual machine, the MAC
      address, the IP configuration and the Internal Networking name
      ("MyIntNet") according to your needs. The following seven commands must
      be issued:<screen>VBoxManage setextradata "VM name" VBoxInternal/Devices/IntNetIP/0/Trusted 1
VBoxManage setextradata "VM name" VBoxInternal/Devices/IntNetIP/0/Config/MAC 08:00:27:01:02:0f
VBoxManage setextradata "VM name" VBoxInternal/Devices/IntNetIP/0/Config/IP 10.0.9.1
VBoxManage setextradata "VM name" VBoxInternal/Devices/IntNetIP/0/Config/Netmask 255.255.255.0
VBoxManage setextradata "VM name" VBoxInternal/Devices/IntNetIP/0/LUN#0/Driver IntNet
VBoxManage setextradata "VM name" VBoxInternal/Devices/IntNetIP/0/LUN#0/Config/Network MyIntNet
VBoxManage setextradata "VM name" VBoxInternal/Devices/IntNetIP/0/LUN#0/Config/IsService 1</screen></para>

      <para>Finally the iSCSI disk must be registered with the
      <code>--intnet</code> option to tell the iSCSI initiator to use internal
      networking:<screen>VBoxManage addiscsidisk --server 10.0.9.30 --target iqn.2008-12.com.sun:sampletarget --intnet</screen></para>

      <para>The target address must be specified as a numeric IP address, as
      there is no DNS resolver for internal networking.</para>

      <para>The virtual machine with the iSCSI target should be started before
      the VM using it is powered on. If a virtual machine using an iSCSI disk
      is started without having the iSCSI target powered up, it can take up to
      200 seconds to detect this situation. The VM will fail to power
      up.</para>
    </sect2>
  </sect1>
</chapter>