hdimagewrites.dita@ 102568

Last change on this file since 102568 was 99797, checked in by vboxsync, 21 months ago
Docs: bugref:10302. Merging changes from the docs team. Almost exclusively conkeyref related stuff.
Property svn:eol-style set to `native` Property svn:keywords set to `Author Date Id Revision`
File size: 9.1 KB

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

Note: See TracBrowser for help on using the repository browser.

Download in other formats:

Original Format