VirtualBox

source: vbox/trunk/doc/manual/en_US/user_Storage.xml@ 69249

最後變更 在這個檔案從69249是 68977,由 vboxsync 提交於 7 年 前

Manual: Trimmed whitespaces.

檔案大小: 50.5 KB
 
1<?xml version="1.0" encoding="UTF-8"?>
2<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
3"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
4<chapter id="storage">
5 <title>Virtual storage</title>
6
7 <para>As the virtual machine will most probably expect to see a hard disk
8 built into its virtual computer, VirtualBox must be able to present "real"
9 storage to the guest as a virtual hard disk. There are presently three
10 methods in which to achieve this:</para>
11
12 <orderedlist>
13 <listitem>
14 <para>Most commonly, VirtualBox will use large image files on a real
15 hard disk and present them to a guest as a virtual hard disk. This is
16 described in <xref linkend="vdidetails" />.</para>
17 </listitem>
18
19 <listitem>
20 <para>Alternatively, if you have iSCSI storage servers, you can attach
21 such a server to VirtualBox as well; this is described in <xref
22 linkend="storage-iscsi" />.</para>
23 </listitem>
24
25 <listitem>
26 <para>Finally, as an advanced feature, you can allow a virtual
27 machine to access one of your host disks directly; this advanced feature
28 is described in <xref linkend="rawdisk" />.</para>
29 </listitem>
30 </orderedlist>
31
32 <para>Each such virtual storage device (image file, iSCSI target or physical
33 hard disk) will need to be connected to the virtual hard disk controller
34 that VirtualBox presents to a virtual machine. This is explained in the next
35 section.</para>
36
37 <sect1 id="harddiskcontrollers">
38 <title>Hard disk controllers: IDE, SATA (AHCI), SCSI, SAS, USB MSD, NVMe</title>
39
40 <para>In a real PC, hard disks and CD/DVD drives are connected to a device
41 called hard disk controller which drives hard disk operation and data
42 transfers. VirtualBox can emulate the five most common types of hard disk
43 controllers typically found in today's PCs: IDE, SATA (AHCI), SCSI,
44 SAS, USB-based and NVMe mass storage devices.<footnote>
45 <para>SATA support was added with VirtualBox 1.6; experimental SCSI
46 support was added with 2.1 and fully implemented with 2.2. Generally,
47 storage attachments were made much more flexible with VirtualBox 3.1;
48 see below. Support for the LSI Logic SAS controller was added with
49 VirtualBox 3.2; USB mass storage devices are supported since
50 VirtualBox 5.0; NVMe controller support was added with VirtualBox 5.1.</para>
51 </footnote><itemizedlist>
52 <listitem>
53 <para><emphasis role="bold">IDE (ATA)</emphasis> controllers are a
54 backwards compatible yet very advanced extension of the disk
55 controller in the IBM PC/AT (1984). Initially, this interface
56 worked only with hard disks, but was later extended to also support
57 CD-ROM drives and other types of removable media. In physical PCs,
58 this standard uses flat ribbon parallel cables with 40 or 80 wires.
59 Each such cable can connect two devices to a controller, which have
60 traditionally been called "master" and "slave". Typical PCs had
61 two connectors for such cables; as a result, support for up to four
62 IDE devices was most common.</para>
63
64 <para>In VirtualBox, each virtual machine may have one IDE
65 controller enabled, which gives you up to four virtual storage
66 devices that you can attach to the machine. (By default, one of
67 these four -- the secondary master -- is preconfigured to be the
68 machine's virtual CD/DVD drive, but this can be changed.<footnote>
69 <para>The assignment of the machine's CD/DVD drive to the
70 secondary master was fixed before VirtualBox 3.1; it is now
71 changeable, and the drive can be at other slots of the IDE
72 controller, and there can be more than one such drive.</para>
73 </footnote>)</para>
74
75 <para>So even if your guest operating system has no support for SCSI
76 or SATA devices, it should always be able to see an IDE controller.
77 </para>
78
79 <para>You can also select which exact type of IDE controller
80 hardware VirtualBox should present to the virtual machine (PIIX3,
81 PIIX4 or ICH6). This makes no difference in terms of performance,
82 but if you import a virtual machine from another virtualization
83 product, the operating system in that machine may expect a
84 particular controller type and crash if it isn't found.</para>
85
86 <para>After you have created a new virtual machine with the "New
87 Virtual Machine" wizard of the graphical user interface, you will
88 typically see one IDE controller in the machine's "Storage" settings
89 where the virtual CD/DVD drive will be attached to one of the four
90 ports of this controller.</para>
91 </listitem>
92
93 <listitem>
94 <para><emphasis role="bold">Serial ATA (SATA)</emphasis> is a newer
95 standard introduced in 2003. Compared to IDE, it supports both much
96 higher speeds and more devices per controller. Also, with
97 physical hardware, devices can be added and removed while the system
98 is running. The standard interface for SATA controllers is called
99 Advanced Host Controller Interface (<emphasis
100 role="bold">AHCI</emphasis>).</para>
101
102 <para>Like a real SATA controller, VirtualBox's virtual SATA
103 controller operates faster and also consumes fewer CPU resources than
104 the virtual IDE controller. Also, this allows you to connect up to
105 30 virtual hard disks to one machine instead of just three, as with
106 the VirtualBox IDE controller (with the DVD drive already attached).</para>
107
108 <para>For this reason, starting with version 3.2 and depending on
109 the selected guest operating system, VirtualBox uses SATA as the
110 default for newly created virtual machines. One virtual SATA
111 controller is created by default, and the default disk that is
112 created with a new VM is attached to this controller.<warning>
113 <para>The entire SATA controller and the virtual disks attached
114 to it (including those in IDE compatibility mode) will not be
115 seen by operating systems that do not have device support for
116 AHCI. In particular, <emphasis role="bold">there is no support
117 for AHCI in Windows before Windows Vista</emphasis>, so Windows
118 XP (even SP3) will not see such disks unless you install
119 additional drivers. It is possible to switch from IDE to SATA
120 after installation by installing the SATA drivers and changing
121 the controller type in the VM settings dialog.<footnote>
122 <para>VirtualBox recommends the Intel Matrix Storage drivers
123 which can be downloaded from <ulink
124 url="http://downloadcenter.intel.com/Product_Filter.aspx?ProductID=2101">http://downloadcenter.intel.com/Product_Filter.aspx?ProductID=2101</ulink>.</para>
125 </footnote></para>
126 </warning></para>
127
128 <para>To add a SATA controller to a machine for which it has not
129 been enabled by default (either because it was created by an earlier
130 version of VirtualBox, or because SATA is not supported by default
131 by the selected guest operating system), go to the "Storage" page of
132 the machine's settings dialog, click on the "Add Controller" button
133 under the "Storage Tree" box and then select "Add SATA Controller".
134 After this, the additional controller will appear as a separate PCI
135 device in the virtual machine, and you can add virtual disks to
136 it.</para>
137
138 <para>To change the IDE compatibility mode settings for the SATA
139 controller, please see <xref
140 linkend="vboxmanage-storagectl" />.</para>
141 </listitem>
142
143 <listitem>
144 <para><emphasis role="bold">SCSI</emphasis> is another established
145 industry standard, standing for "Small Computer System Interface".
146 SCSI was standardized as early as 1986 as a generic interface for
147 data transfer between all kinds of devices, including storage
148 devices. Today SCSI is still used for connecting hard disks and tape
149 devices, but it has mostly been displaced in commodity hardware. It
150 is still in common use in high-performance workstations and
151 servers.</para>
152
153 <para>Primarily for compatibility with other virtualization
154 software, VirtualBox optionally supports LSI Logic and BusLogic SCSI
155 controllers, to each of which up to 15 virtual hard disks can be
156 attached.</para>
157
158 <para>To enable a SCSI controller, on the "Storage" page of a
159 virtual machine's settings dialog, click on the "Add Controller"
160 button under the "Storage Tree" box and then select "Add SCSI
161 Controller". After this, the additional controller will appear as a
162 separate PCI device in the virtual machine.<warning>
163 <para>As with the other controller types, a SCSI controller will
164 only be seen by operating systems with device support for it.
165 Windows 2003 and later ships with drivers for the LSI Logic
166 controller, while Windows NT 4.0 and Windows 2000 ships with
167 drivers for the BusLogic controller. Windows XP ships with
168 drivers for neither.</para>
169 </warning></para>
170 </listitem>
171
172 <listitem>
173 <para><emphasis role="bold">Serial Attached SCSI (SAS)</emphasis> is
174 another bus standard which uses the SCSI command set. As opposed to
175 SCSI, however, with physical devices, serial cables are used instead
176 of parallel ones, which simplifies physical device connections. In
177 some ways, therefore, SAS is to SCSI what SATA is to IDE: it allows
178 for more reliable and faster connections.</para>
179
180 <para>To support high-end guests which require SAS controllers,
181 VirtualBox emulates a LSI Logic SAS controller, which can be enabled
182 much the same way as a SCSI controller. At this time, up to eight
183 devices can be connected to the SAS controller.</para>
184
185 <warning>
186 <para>As with SATA, the SAS controller will only be seen by
187 operating systems with device support for it. In particular,
188 <emphasis role="bold">there is no support for SAS in Windows
189 before Windows Vista</emphasis>, so Windows XP (even SP3) will not
190 see such disks unless you install additional drivers.</para>
191 </warning>
192 </listitem>
193
194 <listitem>
195 <para>The <emphasis role="bold">USB mass storage device class</emphasis>
196 is a standard to connect external storage devices like hard disks or flash
197 drives to a host through USB. All major operating systems support these
198 devices for a long time and ship generic drivers making third-party
199 drivers superfluous. In particular legacy operating systems without
200 support for SATA controllers may benefit from USB mass storage devices.</para>
201 <para>The virtual USB storage controller offered by VirtualBox works
202 different than the other storage controller types: When storage
203 controllers appear as a single PCI device to the guest with multiple
204 disks attached to it, the USB-based storage controller does not appear
205 as virtual storage controller. Each disk attached to the controller
206 appears as a dedicated USB device to the guest.</para>
207 <warning>
208 <para>Booting from drives attached via USB is when EFI is used as the
209 BIOS lacks USB support.</para>
210 </warning>
211 </listitem>
212
213 <listitem>
214 <para><emphasis role="bold">Non volatile memory express (NVMe)</emphasis>
215 is a very recent standard which emerged in 2011 connecting non volatile
216 memory (NVM) directly over PCI express to lift the bandwidth limitation
217 of the previously used SATA protocol for SSDs. Unlike other standards
218 the command set is very simple to achieve maximum throughput and is
219 not compatible with ATA or SCSI. Operating systems need to support NVMe
220 devices to make use of them. For example Windows 8.1 added native NVMe
221 support, for Windows 7 native support was added with an update.
222 <footnote>
223 <para>The NVMe controller is part of the extension pack.</para>
224 </footnote></para>
225 <warning>
226 <para>Booting from drives attached via NVMe is only supported when
227 EFI is used as the BIOS lacks the appropriate driver.</para>
228 </warning>
229 </listitem>
230 </itemizedlist></para>
231
232 <para>In summary, VirtualBox gives you the following categories of virtual
233 storage slots:<orderedlist>
234 <listitem>
235 <para>four slots attached to the traditional IDE controller, which
236 are always present (one of which typically is a virtual CD/DVD
237 drive);</para>
238 </listitem>
239
240 <listitem>
241 <para>30 slots attached to the SATA controller, if enabled and
242 supported by the guest operating system;</para>
243 </listitem>
244
245 <listitem>
246 <para>15 slots attached to the SCSI controller, if enabled and
247 supported by the guest operating system;</para>
248 </listitem>
249
250 <listitem>
251 <para>eight slots attached to the SAS controller, if enabled and
252 supported by the guest operating system.</para>
253 </listitem>
254
255 <listitem>
256 <para>eight slots attached to the virtual USB controller, if enabled and
257 supported by the guest operating system.</para>
258 </listitem>
259
260 <listitem>
261 <para>up to 255 slots attached to the NVMe controller, if enabled and
262 supported by the guest operating system.</para>
263 </listitem>
264 </orderedlist></para>
265
266 <para>Given this large choice of storage controllers, you may ask yourself
267 which one to choose. In general, you should avoid IDE unless it is the
268 only controller supported by your guest. Whether you use SATA, SCSI or SAS
269 does not make any real difference. The variety of controllers is only
270 supplied for VirtualBox for compatibility with existing hardware and other
271 hypervisors.</para>
272 </sect1>
273
274 <sect1 id="vdidetails">
275 <title>Disk image files (VDI, VMDK, VHD, HDD)</title>
276
277 <para>Disk image files reside on the host system and are seen by the guest
278 systems as hard disks of a certain geometry. When a guest operating system
279 reads from or writes to a hard disk, VirtualBox redirects the request to
280 the image file.</para>
281
282 <para>Like a physical disk, a virtual disk has a size (capacity), which
283 must be specified when the image file is created. As opposed to a physical
284 disk however, VirtualBox allows you to expand an image file after
285 creation, even if it has data already; see <xref
286 linkend="vboxmanage-modifyvdi" /> for details.<footnote>
287 <para>Image resizing was added with VirtualBox 4.0.</para>
288 </footnote></para>
289
290 <para>VirtualBox supports four variants of disk image files:<itemizedlist>
291 <listitem>
292 <para>Normally, VirtualBox uses its own container format for guest
293 hard disks -- Virtual Disk Image (VDI) files. In particular, this
294 format will be used when you create a new virtual machine with a new
295 disk.</para>
296 </listitem>
297
298 <listitem>
299 <para>VirtualBox also fully supports the popular and open VMDK
300 container format that is used by many other virtualization products,
301 in particular, by VMware.<footnote>
302 <para>Initial support for VMDK was added with VirtualBox 1.4;
303 since version 2.1, VirtualBox supports VMDK fully, meaning that
304 you can create snapshots and use all the other advanced features
305 described above for VDI images with VMDK also.</para>
306 </footnote></para>
307 </listitem>
308
309 <listitem>
310 <para>VirtualBox also fully supports the VHD format used by
311 Microsoft.</para>
312 </listitem>
313
314 <listitem>
315 <para>Image files of Parallels version 2 (HDD format) are also
316 supported.<footnote>
317 <para>Support was added with VirtualBox 3.1.</para>
318 </footnote> For lack of documentation of the format, newer formats
319 (3 and 4) are not supported. You can however convert such image
320 files to version 2 format using tools provided by Parallels.</para>
321 </listitem>
322 </itemizedlist></para>
323
324 <para>Irrespective of the disk capacity and format, as briefly mentioned
325 in <xref linkend="gui-createvm" />, there are two options of how to create
326 a disk image: fixed-size or dynamically allocated.</para>
327
328 <itemizedlist>
329 <listitem>
330 <para>If you create a <emphasis role="bold">fixed-size
331 image</emphasis>, an image file will be created on your host system
332 which has roughly the same size as the virtual disk's capacity. So,
333 for a 10G disk, you will have a 10G file. Note that the creation of a
334 fixed-size image can take a long time depending on the size of the
335 image and the write performance of your hard disk.</para>
336 </listitem>
337
338 <listitem>
339 <para>For more flexible storage management, use a <emphasis
340 role="bold">dynamically allocated image</emphasis>. This will
341 initially be very small and not occupy any space for unused virtual
342 disk sectors, but will grow every time a disk sector is written to for
343 the first time, until the drive reaches the maximum capacity chosen
344 when the drive was created. While this format takes less space
345 initially, the fact that VirtualBox needs to expand the image file
346 consumes additional computing resources, so until the disk file size has
347 stabilized, write operations may be slower than with fixed size disks.
348 However, after a time the rate of growth will slow and the average penalty
349 for write operations will be negligible.</para>
350 </listitem>
351 </itemizedlist>
352 </sect1>
353
354 <sect1 id="vdis">
355 <title>The Virtual Media Manager</title>
356
357 <para>VirtualBox keeps track of all the hard disk, CD/DVD-ROM and floppy
358 disk images which are in use by virtual machines. These are often referred
359 to as "known media" and come from two sources:<itemizedlist>
360 <listitem>
361 <para>all media currently attached to virtual machines;</para>
362 </listitem>
363
364 <listitem>
365 <para>"registered" media for compatibility with VirtualBox versions
366 older than version 4.0. For details about how media registration has
367 changed with version 4.0, please refer to <xref
368 linkend="vboxconfigdata" />.</para>
369 </listitem>
370 </itemizedlist></para>
371
372 <para>The known media can be viewed and changed in the <emphasis
373 role="bold">Virtual Media Manager</emphasis>, which you can access from
374 the "File" menu in the VirtualBox main window:</para>
375
376 <para><mediaobject>
377 <imageobject>
378 <imagedata align="center" fileref="images/virtual-disk-manager.png"
379 width="12cm" />
380 </imageobject>
381 </mediaobject>The known media are conveniently grouped in three tabs for
382 the three possible formats. These formats are:</para>
383
384 <itemizedlist>
385 <listitem>
386 <para>Hard disk images, either in VirtualBox's own Virtual Disk Image
387 (VDI) format or in the third-party formats listed in the previous
388 chapter;</para>
389 </listitem>
390
391 <listitem>
392 <para>CD/DVD images in standard ISO format;</para>
393 </listitem>
394
395 <listitem>
396 <para>floppy images in standard RAW format.</para>
397 </listitem>
398 </itemizedlist>
399
400 <para>As you can see in the screenshot above, for each image, the Virtual
401 Media Manager shows you the full path of the image file and other
402 information, such as the virtual machine the image is currently attached
403 to, if any.</para>
404
405 <para>The Virtual Media Manager allows you to</para>
406
407 <itemizedlist>
408 <listitem>
409 <para><emphasis role="bold">remove</emphasis> an image from the
410 registry (and optionally delete the image file when doing so);</para>
411 </listitem>
412
413 <listitem>
414 <para><emphasis role="bold">"release"</emphasis> an image, that is,
415 detach it from a virtual machine if it is currently attached to one as
416 a virtual hard disk.</para>
417 </listitem>
418
419 <listitem>
420 <para><emphasis role="bold">copy</emphasis> a virtual hard disk, to
421 another one - target type can be different, options are - VDI, VHD or VMDK.</para>
422 </listitem>
423
424 <listitem>
425 <para><emphasis role="bold">modify</emphasis> the attributes of the
426 disk image file - available options are : Normal, Immutable,
427 Writethrough, Shareable, Multi-attach.</para>
428 </listitem>
429
430 <listitem>
431 <para><emphasis role="bold">refresh</emphasis> the values for the displayed
432 attributes of the disk image currently selected in the window.</para>
433 </listitem>
434
435 </itemizedlist>
436
437 <para>These commands are accessible once a medium has been selected either by selecting
438 from the options shown at the top of the window, or by right-clicking the medium
439 and selecting from the options shown on the drop-down menu.</para>
440
441 <para>Starting with version 4.0, to <emphasis role="bold">create new disk
442 images,</emphasis> please use the "Storage" page in a virtual machine's
443 settings dialog because disk images are now by default stored in each
444 machine's own folder.</para>
445
446 <para>Hard disk image files can be copied onto other host systems and
447 imported into virtual machines there, although certain guest systems
448 (notably Windows 2000 and XP) will require that the new virtual machine be
449 set up in a similar way to the old one.<note>
450 <para>Do not simply make copies of virtual disk images. If you import
451 such a second copy into a virtual machine, VirtualBox will complain
452 with an error, since VirtualBox assigns a unique identifier (UUID) to
453 each disk image to make sure it is only used once. See <xref
454 linkend="cloningvdis" /> for instructions on this matter. Also, if you
455 want to copy a virtual machine to another system, VirtualBox has an
456 import/export facility that might be better suited for your needs; see
457 <xref linkend="ovf" />.</para>
458 </note></para>
459 </sect1>
460
461 <sect1 id="hdimagewrites">
462 <title>Special image write modes</title>
463
464 <para>For each virtual disk image supported by VirtualBox, you can
465 determine separately how it should be affected by write operations from a
466 virtual machine and snapshot operations. This applies to all of the
467 aforementioned image formats (VDI, VMDK, VHD or HDD) and irrespective of
468 whether an image is fixed-size or dynamically allocated.</para>
469
470 <para>By default, images are in "normal" mode. To mark an existing image
471 with one of the non-standard modes listed below, use
472 <computeroutput>VBoxManage modifyhd</computeroutput>; see <xref
473 linkend="vboxmanage-modifyvdi" />. Alternatively, use VBoxManage to attach
474 the image to a VM and use the <computeroutput>--mtype</computeroutput>
475 argument; see <xref linkend="vboxmanage-storageattach" />.</para>
476
477 <orderedlist>
478 <listitem>
479 <para>With <emphasis role="bold">normal images</emphasis> (the default
480 setting), there are no restrictions on how guests can read from and
481 write to the disk.</para>
482
483 <para>When you take a snapshot of your virtual machine as described in
484 <xref linkend="snapshots" />, the state of such a "normal hard disk"
485 will be recorded together with the snapshot, and when reverting to the
486 snapshot, its state will be fully reset.</para>
487
488 <para>(Technically, strictly speaking, the image file itself is not
489 "reset". Instead, when a snapshot is taken, VirtualBox "freezes" the
490 image file and no longer writes to it. For the write operations from
491 the VM, a second, "differencing" image file is created which receives
492 only the changes to the original image; see the next section for
493 details.)</para>
494
495 <para>While you can attach the same "normal" image to more than one
496 virtual machine, only one of these virtual machines attached to the
497 same image file can be executed simultaneously, as otherwise there
498 would be conflicts if several machines write to the same image
499 file.<footnote>
500 <para>This restriction is more lenient now than it was before
501 VirtualBox 2.2. Previously, each "normal" disk image could only be
502 <emphasis>attached</emphasis> to one single machine. Now it can be
503 attached to more than one machine so long as only one of these
504 machines is running.</para>
505 </footnote></para>
506 </listitem>
507
508 <listitem>
509 <para>By contrast, <emphasis role="bold">write-through hard
510 disks</emphasis> are completely unaffected by snapshots: their state
511 is <emphasis>not</emphasis> saved when a snapshot is taken, and not
512 restored when a snapshot is restored.</para>
513 </listitem>
514
515 <listitem>
516 <para><emphasis role="bold">Shareable hard disks</emphasis> are a
517 variant of write-through hard disks. In principle they behave exactly
518 the same, i.e. their state is <emphasis>not</emphasis> saved when a
519 snapshot is taken, and not restored when a snapshot is restored. The
520 difference only shows if you attach such disks to several VMs.
521 Shareable disks may be attached to several VMs which may run
522 concurrently. This makes them suitable for use by cluster filesystems
523 between VMs and similar applications which are explicitly prepared to
524 access a disk concurrently. Only fixed size images can be used in this
525 way, and dynamically allocated images are rejected.<warning>
526 <para>This is an expert feature, and misuse can lead to data loss
527 -- regular filesystems are not prepared to handle simultaneous
528 changes by several parties.</para>
529 </warning></para>
530 </listitem>
531
532 <listitem>
533 <para>Next, <emphasis role="bold">immutable images</emphasis> only
534 remember write accesses temporarily while the virtual machine is
535 running; all changes are lost when the virtual machine is powered on
536 the next time. As a result, as opposed to "normal" images, the same
537 immutable image can be used with several virtual machines without
538 restrictions.</para>
539
540 <para><emphasis>Creating</emphasis> an immutable image makes little
541 sense since it would be initially empty and lose its contents with
542 every machine restart (unless you really want to have a disk that is
543 always unformatted when the machine starts up). As a result, normally,
544 you would first create a "normal" image and then, when you deem its
545 contents useful, later mark it immutable.</para>
546
547 <para>If you take a snapshot of a machine with immutable images, then
548 on every machine power-up, those images are reset to the state of the
549 last (current) snapshot (instead of the state of the original
550 immutable image).</para>
551
552 <note>
553 <para>As a special exception, immutable images are
554 <emphasis>not</emphasis> reset if they are attached to a machine
555 in saved state or whose last snapshot was taken while the machine
556 was running (a so-called "online" snapshot). As a result, if the
557 machine's current snapshot is such an "online" snapshot, its
558 immutable images behave exactly like the "normal" images described
559 previously. To re-enable the automatic resetting of such images,
560 delete the current snapshot of the machine.</para>
561 </note>
562
563 <para>Again, technically, VirtualBox never writes to an immutable
564 image directly at all. All write operations from the machine will be
565 directed to a differencing image; the next time the VM is powered on,
566 the differencing image is reset so that every time the VM starts, its
567 immutable images have exactly the same content.<footnote>
568 <para>This behavior also changed with VirtualBox 2.2. Previously,
569 the differencing images were discarded when the machine session
570 <emphasis>ended</emphasis>; now they are discarded every time the
571 machine is powered on.</para>
572 </footnote> The differencing image is only reset when the machine is
573 powered on from within VirtualBox, not when you reboot by requesting a
574 reboot from within the machine. This is also why immutable images
575 behave as described above when snapshots are also present, which use
576 differencing images as well.</para>
577
578 <para>If the automatic discarding of the differencing image on VM
579 startup does not fit your needs, you can turn it off using the
580 <computeroutput>autoreset</computeroutput> parameter of
581 <computeroutput>VBoxManage modifyhd</computeroutput>; see <xref
582 linkend="vboxmanage-modifyvdi" /> for details.</para>
583 </listitem>
584
585 <listitem>
586 <para>An image in <emphasis role="bold">multiattach mode</emphasis>
587 can be attached to more than one virtual machine at the same time,
588 even if these machines are running simultaneously. For each virtual
589 machine to which such an image is attached, a differencing image is
590 created. As a result, data that is written to such a virtual disk by
591 one machine is not seen by the other machines to which the image is
592 attached; each machine creates its own write history of the
593 multiattach image.</para>
594
595 <para>Technically, a "multiattach" image behaves identically to an
596 "immutable" image except the differencing image is not reset every
597 time the machine starts.</para>
598 <para>This mode is useful for sharing files which are almost never
599 written, for instance picture galleries, where every guest changes
600 only a small amount of data and the majority of the disk content
601 remains unchanged. The modified blocks are stored in differencing
602 images which remain relatively small and the shared content is stored
603 only once at the host.</para>
604 </listitem>
605
606 <listitem>
607 <para>Finally, the <emphasis role="bold">read-only image</emphasis> is
608 used automatically for CD/DVD images, since CDs/DVDs can never be
609 written to.</para>
610 </listitem>
611 </orderedlist>
612
613 <para>To illustrate the differences between the various types with respect
614 to snapshots: Assume you have installed your guest operating system in
615 your VM, and you have taken a snapshot. Imagine you have accidentally
616 infected your VM with a virus and would like to go back to the snapshot.
617 With a normal hard disk image, you simply restore the snapshot, and the
618 earlier state of your hard disk image will be restored as well (and your
619 virus infection will be undone). With an immutable hard disk, all it takes
620 is to shut down and power on your VM, and the virus infection will be
621 discarded. With a write-through image however, you cannot easily undo the
622 virus infection by means of virtualization, but will have to disinfect
623 your virtual machine like a real computer.</para>
624
625 <para>Still, you might find write-through images useful if you want to
626 preserve critical data irrespective of snapshots, and since you can attach
627 more than one image to a VM, you may want to have one immutable for the
628 operating system and one write-through for your data files.</para>
629 </sect1>
630
631 <sect1 id="diffimages">
632 <title>Differencing images</title>
633
634 <para>The previous section hinted at differencing images and how they are
635 used with snapshots, immutable images and multiple disk attachments. For
636 the inquisitive VirtualBox user, this section describes in more detail how
637 they work.</para>
638
639 <para>A differencing image is a special disk image that only holds the
640 differences to another image. A differencing image by itself is useless,
641 it must always refer to another image. The differencing image is then
642 typically referred to as a "child", which holds the differences to its
643 "parent".</para>
644
645 <para>When a differencing image is active, it receives all write
646 operations from the virtual machine instead of its parent. The
647 differencing image only contains the sectors of the virtual hard disk that
648 have changed since the differencing image was created. When the machine
649 reads a sector from such a virtual hard disk, it looks into the
650 differencing image first. If the sector is present, it is returned from
651 there; if not, VirtualBox looks into the parent. In other words, the
652 parent becomes "read-only"; it is never written to again, but it is read
653 from if a sector has not changed.</para>
654
655 <para>Differencing images can be chained. If another differencing image is
656 created for a virtual disk that already has a differencing image, then it
657 becomes a "grandchild" of the original parent. The first differencing
658 image then becomes read-only as well, and write operations only go to the
659 second-level differencing image. When reading from the virtual disk,
660 VirtualBox needs to look into the second differencing image first, then
661 into the first if the sector was not found, and then into the original
662 image.</para>
663
664 <para>There can be an unlimited number of differencing images, and each
665 image can have more than one child. As a result, the differencing images
666 can form a complex tree with parents, "siblings" and children, depending
667 on how complex your machine configuration is. Write operations always go
668 to the one "active" differencing image that is attached to the machine,
669 and for read operations, VirtualBox may need to look up all the parents in
670 the chain until the sector in question is found. You can look at such a
671 tree in the Virtual Media Manager:<mediaobject>
672 <imageobject>
673 <imagedata align="center" fileref="images/virtual-disk-manager2.png"
674 width="12cm" />
675 </imageobject>
676 </mediaobject></para>
677
678 <para>In all of these situations, from the point of view of the virtual
679 machine, the virtual hard disk behaves like any other disk. While the
680 virtual machine is running, there is a slight run-time I/O overhead
681 because VirtualBox might need to look up sectors several times. This is
682 not noticeable however since the tables with sector information are always
683 kept in memory and can be looked up quickly.</para>
684
685 <para>Differencing images are used in the following
686 situations:<orderedlist>
687 <listitem>
688 <para><emphasis role="bold">Snapshots.</emphasis> When you create a
689 snapshot, as explained in the previous section, VirtualBox "freezes"
690 the images attached to the virtual machine and creates differencing
691 images for each of them (to be precise: one for each image that is
692 not in "write-through" mode). From the point of view of the virtual
693 machine, the virtual disks continue to operate before, but all write
694 operations go into the differencing images. Each time you create
695 another snapshot, for each hard disk attachment, another
696 differencing image is created and attached, forming a chain or
697 tree.</para>
698
699 <para>In the above screenshot, you see that the original disk image
700 is now attached to a snapshot, representing the state of the disk
701 when the snapshot was taken.</para>
702
703 <para>If you now <emphasis role="bold">restore</emphasis> a snapshot
704 -- that is, if you want to go back to the exact machine state that
705 was stored in the snapshot --, the following happens:<orderedlist>
706 <listitem>
707 <para>VirtualBox copies the virtual machine settings that were
708 copied into the snapshot back to the virtual machine. As a
709 result, if you have made changes to the machine configuration
710 since taking the snapshot, they are undone.</para>
711 </listitem>
712
713 <listitem>
714 <para>If the snapshot was taken while the machine was running,
715 it contains a saved machine state, and that state is restored
716 as well; after restoring the snapshot, the machine will then
717 be in "Saved" state and resume execution from there when it is
718 next started. Otherwise the machine will be in "Powered Off"
719 state and do a full boot.</para>
720 </listitem>
721
722 <listitem>
723 <para>For each disk image attached to the machine, the
724 differencing image holding all the write operations since the
725 current snapshot was taken is thrown away, and the original
726 parent image is made active again. (If you restored the "root"
727 snapshot, then this will be the root disk image for each
728 attachment; otherwise, some other differencing image descended
729 from it.) This effectively restores the old machine
730 state.</para>
731 </listitem>
732 </orderedlist></para>
733
734 <para>If you later <emphasis role="bold">delete</emphasis> a
735 snapshot in order to free disk space, for each disk attachment, one
736 of the differencing images becomes obsolete. In this case, the
737 differencing image of the disk attachment cannot simply be deleted.
738 Instead, VirtualBox needs to look at each sector of the differencing
739 image and needs to copy it back into its parent; this is called
740 "merging" images and can be a potentially lengthy process, depending
741 on how large the differencing image is. It can also temporarily need
742 a considerable amount of extra disk space, before the differencing
743 image obsoleted by the merge operation is deleted.</para>
744 </listitem>
745
746 <listitem>
747 <para><emphasis role="bold">Immutable images.</emphasis> When an
748 image is switched to "immutable" mode, a differencing image is
749 created as well. As with snapshots, the parent image then becomes
750 read-only, and the differencing image receives all the write
751 operations. Every time the virtual machine is started, all the
752 immutable images which are attached to it have their respective
753 differencing image thrown away, effectively resetting the virtual
754 machine's virtual disk with every restart.</para>
755 </listitem>
756 </orderedlist></para>
757 </sect1>
758
759 <sect1 id="cloningvdis">
760 <title>Cloning disk images</title>
761
762 <para>You can duplicate hard disk image files on the same host to quickly
763 produce a second virtual machine with the same operating system setup.
764 However, you should <emphasis>only</emphasis> make copies of virtual disk
765 images using the utility supplied with VirtualBox; see <xref
766 linkend="vboxmanage-clonevdi" />. This is because VirtualBox assigns a
767 unique identity number (UUID) to each disk image, which is also stored
768 inside the image, and VirtualBox will refuse to work with two images that
769 use the same number. If you do accidentally try to re-import a disk image
770 which you copied normally, you can make a second copy using VirtualBox's
771 utility and import that instead.</para>
772
773 <para>Note that newer Linux distributions identify the boot hard disk from
774 the ID of the drive. The ID VirtualBox reports for a drive is determined
775 from the UUID of the virtual disk image. So if you clone a disk image and
776 try to boot the copied image the guest might not be able to determine its
777 own boot disk as the UUID changed. In this case you have to adapt the disk
778 ID in your boot loader script (for example
779 <computeroutput>/boot/grub/menu.lst</computeroutput>). The disk ID looks
780 like this:<screen>scsi-SATA_VBOX_HARDDISK_VB5cfdb1e2-c251e503</screen></para>
781
782 <para>The ID for the copied image can be determined with <screen>hdparm -i /dev/sda</screen></para>
783 </sect1>
784
785 <sect1 id="iocaching">
786 <title>Host I/O caching</title>
787
788 <para>Starting with version 3.2, VirtualBox can optionally disable the I/O
789 caching that the host operating system would otherwise perform on disk
790 image files.</para>
791
792 <para>Traditionally, VirtualBox has opened disk image files as normal
793 files, which results in them being cached by the host operating system
794 like any other file. The main advantage of this is speed: when the guest
795 OS writes to disk and the host OS cache uses delayed writing, the write
796 operation can be reported as completed to the guest OS quickly while the
797 host OS can perform the operation asynchronously. Also, when you start a
798 VM a second time and have enough memory available for the OS to use for
799 caching, large parts of the virtual disk may be in system memory, and the
800 VM can access the data much faster.</para>
801
802 <para>Note that this applies only to image files; buffering never occurred
803 for virtual disks residing on remote iSCSI storage, which is the more common
804 scenario in enterprise-class setups (see <xref
805 linkend="storage-iscsi" />).</para>
806
807 <para>While buffering is a useful default setting for virtualizing a few
808 machines on a desktop computer, there are some disadvantages to this
809 approach:<orderedlist>
810 <listitem>
811 <para>Delayed writing through the host OS cache is less secure. When
812 the guest OS writes data, it considers the data written even though
813 it has not yet arrived on a physical disk. If for some reason the
814 write does not happen (power failure, host crash), the likelihood of
815 data loss increases.</para>
816 </listitem>
817
818 <listitem>
819 <para>Disk image files tend to be very large. Caching them can
820 therefore quickly use up the entire host OS cache. Depending on the
821 efficiency of the host OS caching, this may slow down the host
822 immensely, especially if several VMs run at the same time. For
823 example, on Linux hosts, host caching may result in Linux delaying
824 all writes until the host cache is nearly full and then writing out
825 all these changes at once, possibly stalling VM execution for
826 minutes. This can result in I/O errors in the guest as I/O requests
827 time out there.</para>
828 </listitem>
829
830 <listitem>
831 <para>Physical memory is often wasted as guest operating systems
832 typically have their own I/O caches, which may result in the data
833 being cached twice (in both the guest and the host caches) for
834 little effect.</para>
835 </listitem>
836 </orderedlist></para>
837
838 <para>If you decide to disable host I/O caching for the above reasons,
839 VirtualBox uses its own small cache to buffer writes, but no read caching
840 since this is typically already performed by the guest OS. In addition,
841 VirtualBox fully supports asynchronous I/O for its virtual SATA, SCSI and
842 SAS controllers through multiple I/O threads.</para>
843
844 <para>Since asynchronous I/O is not supported by IDE controllers, for
845 performance reasons, you may want to leave host caching enabled for your
846 VM's virtual IDE controllers.</para>
847
848 <para>For this reason, VirtualBox allows you to configure whether the host
849 I/O cache is used for each I/O controller separately. Either uncheck the
850 "Use host I/O cache" box in the "Storage" settings for a given virtual
851 storage controller, or use the following VBoxManage command to disable the
852 host I/O cache for a virtual storage controller:<screen>VBoxManage storagectl "VM name" --name &lt;controllername&gt; --hostiocache off</screen></para>
853
854 <para>See <xref linkend="vboxmanage-storagectl" /> for details.</para>
855
856 <para>For the above reasons also, VirtualBox now uses SATA controllers by
857 default for new virtual machines.</para>
858 </sect1>
859
860 <sect1 id="storage-bandwidth-limit">
861 <title>Limiting bandwidth for disk images</title>
862
863 <para>Starting with version 4.0, VirtualBox allows for limiting the
864 maximum bandwidth used for asynchronous I/O. Additionally it supports
865 sharing limits through bandwidth groups for several images. It is possible
866 to have more than one such limit.</para>
867
868 <para>Limits are configured through
869 <computeroutput>VBoxManage</computeroutput>. The example below creates a
870 bandwidth group named "Limit", sets the limit to 20 MB/s and assigns the
871 group to the attached disks of the VM:<screen>VBoxManage bandwidthctl "VM name" add Limit --type disk --limit 20M
872VBoxManage storageattach "VM name" --storagectl "SATA" --port 0 --device 0 --type hdd
873 --medium disk1.vdi --bandwidthgroup Limit
874VBoxManage storageattach "VM name" --storagectl "SATA" --port 1 --device 0 --type hdd
875 --medium disk2.vdi --bandwidthgroup Limit</screen></para>
876
877 <para>All disks in a group share the bandwidth limit, meaning that in the
878 example above the bandwidth of both images combined can never exceed 20
879 MB/s. However, if one disk doesn't require bandwidth the other can use the
880 remaining bandwidth of its group.</para>
881
882 <para>The limits for each group can be changed while the VM is running,
883 with changes being picked up immediately. The example below changes the
884 limit for the group created in the example above to 10 MB/s:<screen>VBoxManage bandwidthctl "VM name" set Limit --limit 10M</screen></para>
885 </sect1>
886
887 <sect1 id="storage-cds">
888 <title>CD/DVD support</title>
889
890 <para>The virtual CD/DVD drive(s) by default support only reading. The
891 medium configuration is changeable at runtime. You can select between
892 three options to provide the medium data:<itemizedlist>
893 <listitem>
894 <para><emphasis role="bold">Host Drive</emphasis> defines that the
895 guest can read from the medium in the host drive.</para>
896 </listitem>
897
898 <listitem>
899 <para><emphasis role="bold">Image file</emphasis> (typically an ISO
900 file) gives the guest read-only access to the data in the
901 image.</para>
902 </listitem>
903
904 <listitem>
905 <para><emphasis role="bold">Empty</emphasis> stands for a drive
906 without an inserted medium.</para>
907 </listitem>
908 </itemizedlist></para>
909
910 <para>Changing between the above, or changing a medium in the host drive
911 that is accessed by a machine, or changing an image file will signal a
912 medium change to the guest operating system, which can then react to the
913 change (e.g. by starting an installation program).</para>
914
915 <para>Medium changes can be prevented by the guest, and VirtualBox
916 reflects that by locking the host drive if appropriate. You can force a
917 medium removal in such situations via the VirtualBox GUI or the VBoxManage
918 command line tool. Effectively this is the equivalent of the emergency
919 eject which many CD/DVD drives provide, with all associated side effects:
920 the guest OS can issue error messages, just like on real hardware, and
921 guest applications may misbehave. Use this with caution.<note>
922 <para>The identification string of the drive provided to the guest
923 (which, in the guest, would be displayed by configuration tools such
924 as the Windows Device Manager) is always "VBOX CD-ROM", irrespective
925 of the current configuration of the virtual drive. This is to prevent
926 hardware detection from being triggered in the guest operating system
927 every time the configuration is changed.</para>
928 </note></para>
929
930 <para>The standard CD/DVD emulation allows for reading standard data CD
931 and DVD formats only. As an experimental feature, for additional
932 capabilities, it is possible to give the guest direct access to the CD/DVD
933 host drive by enabling "passthrough" mode. Depending on the host hardware,
934 this may enable three things to work, potentially:<itemizedlist>
935 <listitem>
936 <para>CD/DVD writing from within the guest, if the host DVD drive is
937 a CD/DVD writer;</para>
938 </listitem>
939
940 <listitem>
941 <para>playing audio CDs;</para>
942 </listitem>
943
944 <listitem>
945 <para>playing encrypted DVDs.</para>
946 </listitem>
947 </itemizedlist></para>
948
949 <para>There is a "Passthrough" checkbox in the GUI dialog for configuring
950 the media attached to a storage controller, or you can use the
951 <computeroutput>--passthrough</computeroutput> option with
952 <computeroutput>VBoxManage storageattach</computeroutput>; see <xref
953 linkend="vboxmanage-storageattach" /> for details.</para>
954
955 <para>Even if pass-through is enabled, unsafe commands, such as updating
956 the drive firmware, will be blocked. Video CD formats are never supported,
957 not even in passthrough mode, and cannot be played from a virtual
958 machine.</para>
959
960 <para>On Solaris hosts, pass-through requires running VirtualBox with real
961 root permissions due to security measures enforced by the host.</para>
962 </sect1>
963
964 <sect1 id="storage-iscsi">
965 <title>iSCSI servers</title>
966
967 <para>iSCSI stands for "Internet SCSI" and is a standard that allows for
968 using the SCSI protocol over Internet (TCP/IP) connections. Especially
969 with the advent of Gigabit Ethernet, it has become affordable to attach
970 iSCSI storage servers simply as remote hard disks to a computer network.
971 In iSCSI terminology, the server providing storage resources is called an
972 "iSCSI target", while the client connecting to the server and accessing
973 its resources is called "iSCSI initiator".</para>
974
975 <para>VirtualBox can transparently present iSCSI remote storage to a
976 virtual machine as a virtual hard disk. The guest operating system will
977 not see any difference between a virtual disk image (VDI file) and an
978 iSCSI target. To achieve this, VirtualBox has an integrated iSCSI
979 initiator.</para>
980
981 <para>VirtualBox's iSCSI support has been developed according to the iSCSI
982 standard and should work with all standard-conforming iSCSI targets. To
983 use an iSCSI target with VirtualBox, you must use the command line; see
984 <xref linkend="vboxmanage-storageattach" />.</para>
985 </sect1>
986</chapter>
注意: 瀏覽 TracBrowser 來幫助您使用儲存庫瀏覽器

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy Automated Access Etiquette