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