| 1 | <?xml version='1.0' encoding='UTF-8'?>
|
|---|
| 2 | <!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd">
|
|---|
| 3 | <topic xml:lang="en-us" id="hdimagewrites">
|
|---|
| 4 | <title>Special Image Write Modes</title>
|
|---|
| 5 |
|
|---|
| 6 | <body>
|
|---|
| 7 | <p>For each virtual disk image supported by <ph conkeyref="vbox-conkeyref-phrases/product-name"/>, you can determine
|
|---|
| 8 | separately how it should be affected by write operations from a virtual machine and snapshot operations. This
|
|---|
| 9 | applies to all of the aforementioned image formats (VDI, VMDK, VHD, or HDD) and irrespective of whether an image
|
|---|
| 10 | is fixed-size or dynamically allocated. </p>
|
|---|
| 11 | <p>By default, images are in <i>normal</i> mode. To mark an existing image with one of the nonstandard modes listed
|
|---|
| 12 | below, use <userinput>VBoxManage modifymedium</userinput>. See <xref href="vboxmanage-modifymedium.dita"/>.
|
|---|
| 13 | Alternatively, use <userinput>VBoxManage storageattach</userinput> to attach the image to a VM and specify the
|
|---|
| 14 | <codeph>--mtype</codeph> argument. See <xref href="vboxmanage-storageattach.dita"/>. </p>
|
|---|
| 15 | <p>The available virtual disk image modes are as follows: </p>
|
|---|
| 16 | <ul>
|
|---|
| 17 | <li>
|
|---|
| 18 | <p><b outputclass="bold">Normal images</b> have no
|
|---|
| 19 | restrictions on how guests can read from and write to the
|
|---|
| 20 | disk. This is the default image mode.
|
|---|
| 21 | </p>
|
|---|
| 22 | <p>When you take a snapshot of your virtual machine as described in <xref href="snapshots.dita#snapshots"/>, the
|
|---|
| 23 | state of a normal hard disk is recorded together with the snapshot, and when reverting to the snapshot, its
|
|---|
| 24 | state will be fully reset. </p>
|
|---|
| 25 | <p>The image file itself is not reset. Instead, when a snapshot is taken, <ph
|
|---|
| 26 | conkeyref="vbox-conkeyref-phrases/product-name"/>
|
|---|
| 27 | <i>freezes</i> the image file and no longer writes to it. For the write operations from the VM, a second,
|
|---|
| 28 | <i>differencing</i> image file is created which receives only the changes to the original image. See <xref
|
|---|
| 29 | href="diffimages.dita#diffimages"/>. </p>
|
|---|
| 30 | <p>While you can attach the same normal image to more than one virtual machine, only one of these virtual
|
|---|
| 31 | machines attached to the same image file can be executed simultaneously, as otherwise there would be conflicts
|
|---|
| 32 | if several machines write to the same image file. </p>
|
|---|
| 33 | </li>
|
|---|
| 34 | <li>
|
|---|
| 35 | <p><b outputclass="bold">Write-through hard disks</b> are
|
|---|
| 36 | completely unaffected by snapshots. Their state is
|
|---|
| 37 | <i>not</i> saved when a snapshot is taken, and
|
|---|
| 38 | not restored when a snapshot is restored.
|
|---|
| 39 | </p>
|
|---|
| 40 | </li>
|
|---|
| 41 | <li>
|
|---|
| 42 | <p><b outputclass="bold">Shareable hard disks</b> are a
|
|---|
| 43 | variant of write-through hard disks. In principle they behave
|
|---|
| 44 | exactly the same. Their state is <i>not</i>
|
|---|
| 45 | saved when a snapshot is taken, and not restored when a
|
|---|
| 46 | snapshot is restored. The difference only shows if you attach
|
|---|
| 47 | such disks to several VMs. Shareable disks may be attached to
|
|---|
| 48 | several VMs which may run concurrently. This makes them
|
|---|
| 49 | suitable for use by cluster filesystems between VMs and
|
|---|
| 50 | similar applications which are explicitly prepared to access a
|
|---|
| 51 | disk concurrently. Only fixed size images can be used in this
|
|---|
| 52 | way, and dynamically allocated images are rejected.
|
|---|
| 53 | </p>
|
|---|
| 54 | <note type="caution">
|
|---|
| 55 | <p>This is an expert feature, and misuse can lead to data loss, as regular filesystems are not prepared to
|
|---|
| 56 | handle simultaneous changes by several parties. </p>
|
|---|
| 57 | </note>
|
|---|
| 58 | </li>
|
|---|
| 59 | <li>
|
|---|
| 60 | <p><b outputclass="bold">Immutable images</b> only
|
|---|
| 61 | remember write accesses temporarily while the virtual machine
|
|---|
| 62 | is running. All changes are lost when the virtual machine is
|
|---|
| 63 | powered on the next time. As a result, as opposed to Normal
|
|---|
| 64 | images, the same immutable image can be used with several
|
|---|
| 65 | virtual machines without restrictions.
|
|---|
| 66 | </p>
|
|---|
| 67 | <p>Creating an immutable image makes little sense since it would be initially empty and lose its contents with
|
|---|
| 68 | every machine restart. You would have a disk that is always unformatted when the machine starts up. Instead,
|
|---|
| 69 | you can first create a normal image and then later mark it as immutable when you decide that the contents are
|
|---|
| 70 | useful. </p>
|
|---|
| 71 | <p>If you take a snapshot of a machine with immutable images, then on every machine power-up, those images are
|
|---|
| 72 | reset to the state of the last (current) snapshot, instead of the state of the original immutable image. </p>
|
|---|
| 73 | <note>
|
|---|
| 74 | <p>As a special exception, immutable images are <i>not</i> reset if they are attached to a machine in a saved
|
|---|
| 75 | state or whose last snapshot was taken while the machine was running. This is called an <i>online
|
|---|
| 76 | snapshot</i>. As a result, if the machine's current snapshot is an online snapshot, its immutable images
|
|---|
| 77 | behave exactly like the a normal image. To reenable the automatic resetting of such images, delete the
|
|---|
| 78 | current snapshot of the machine. </p>
|
|---|
| 79 | </note>
|
|---|
| 80 | <p><ph conkeyref="vbox-conkeyref-phrases/product-name"/> never writes to an immutable image directly at all. All
|
|---|
| 81 | write operations from the machine are directed to a differencing image. The next time the VM is powered on,
|
|---|
| 82 | the differencing image is reset so that every time the VM starts, its immutable images have exactly the same
|
|---|
| 83 | content. </p>
|
|---|
| 84 | <p>The differencing image is only reset when the machine is powered on from within <ph
|
|---|
| 85 | conkeyref="vbox-conkeyref-phrases/product-name"/>, not when you reboot by requesting a reboot from within
|
|---|
| 86 | the machine. This is also why immutable images behave as described above when snapshots are also present,
|
|---|
| 87 | which use differencing images as well. </p>
|
|---|
| 88 | <p>If the automatic discarding of the differencing image on VM startup does not fit your needs, you can turn it
|
|---|
| 89 | off using the <codeph>autoreset</codeph> parameter of <userinput>VBoxManage modifymedium</userinput>. See
|
|---|
| 90 | <xref href="vboxmanage-modifymedium.dita"/>. </p>
|
|---|
| 91 | </li>
|
|---|
| 92 | <li>
|
|---|
| 93 | <p><b outputclass="bold">Multiattach mode images</b> can
|
|---|
| 94 | be attached to more than one virtual machine at the same time,
|
|---|
| 95 | even if these machines are running simultaneously. For each
|
|---|
| 96 | virtual machine to which such an image is attached, a
|
|---|
| 97 | differencing image is created. As a result, data that is
|
|---|
| 98 | written to such a virtual disk by one machine is not seen by
|
|---|
| 99 | the other machines to which the image is attached. Each
|
|---|
| 100 | machine creates its own write history of the multiattach
|
|---|
| 101 | image.
|
|---|
| 102 | </p>
|
|---|
| 103 | <p>Technically, a multiattach image behaves identically to an immutable image except the differencing image is
|
|---|
| 104 | not reset every time the machine starts. </p>
|
|---|
| 105 | <p>This mode is useful for sharing files which are almost never written, for instance picture galleries, where
|
|---|
| 106 | every guest changes only a small amount of data and the majority of the disk content remains unchanged. The
|
|---|
| 107 | modified blocks are stored in differencing images which remain relatively small and the shared content is
|
|---|
| 108 | stored only once at the host. </p>
|
|---|
| 109 | </li>
|
|---|
| 110 | <li>
|
|---|
| 111 | <p><b outputclass="bold">Read-only images</b> are used
|
|---|
| 112 | automatically for CD/DVD images, since CDs/DVDs can never be
|
|---|
| 113 | written to.
|
|---|
| 114 | </p>
|
|---|
| 115 | </li>
|
|---|
| 116 | </ul>
|
|---|
| 117 | <p>The following scenario illustrates the differences between the various image modes, with respect to snapshots. </p>
|
|---|
| 118 | <p>Assume you have installed your guest OS in your VM, and you have taken a snapshot. Later, your VM is infected
|
|---|
| 119 | with a virus and you would like to go back to the snapshot. With a normal hard disk image, you simply restore the
|
|---|
| 120 | snapshot, and the earlier state of your hard disk image will be restored as well and your virus infection will be
|
|---|
| 121 | undone. With an immutable hard disk, all it takes is to shut down and power on your VM, and the virus infection
|
|---|
| 122 | will be discarded. With a write-through image however, you cannot easily undo the virus infection by means of
|
|---|
| 123 | virtualization, but will have to disinfect your virtual machine like a real computer. </p>
|
|---|
| 124 | <p>You might find write-through images useful if you want to preserve critical data irrespective of snapshots. As
|
|---|
| 125 | you can attach more than one image to a VM, you may want to have one immutable image for the OS and one
|
|---|
| 126 | write-through image for your data files. </p>
|
|---|
| 127 | </body>
|
|---|
| 128 |
|
|---|
| 129 | </topic>
|
|---|
