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