1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd">
<topic xml:lang="en-us" id="iocaching">
<title>Host Input/Output Caching</title>
<body>
<p><ph conkeyref="vbox-conkeyref-phrases/product-name"/> can optionally disable the I/O caching that the host OS
would otherwise perform on disk image files. </p>
<p>Traditionally, <ph conkeyref="vbox-conkeyref-phrases/product-name"/> has opened disk image files as normal files,
which results in them being cached by the host OS like any other file. The main advantage of this is speed: when
the guest OS writes to disk and the host OS cache uses delayed writing, the write operation can be reported as
completed to the guest OS quickly while the host OS can perform the operation asynchronously. Also, when you start
a VM a second time and have enough memory available for the OS to use for caching, large parts of the virtual disk
may be in system memory, and the VM can access the data much faster. </p>
<p>Note that this applies only to image files. Buffering does not occur for virtual disks residing on remote iSCSI
storage, which is the more common scenario in enterprise-class setups. See <xref
href="storage-iscsi.dita#storage-iscsi"/>. </p>
<p>While buffering is a useful default setting for virtualizing a few machines on a desktop computer, there are some
disadvantages to this approach: </p>
<ul>
<li>
<p>Delayed writing through the host OS cache is less secure. When the guest OS writes data, it considers the
data written even though it has not yet arrived on a physical disk. If for some reason the write does not
happen, such as power failure or host crash, the likelihood of data loss increases. </p>
</li>
<li>
<p>Disk image files tend to be very large. Caching them can therefore quickly use up the entire host OS cache.
Depending on the efficiency of the host OS caching, this may slow down the host immensely, especially if
several VMs run at the same time. For example, on Linux hosts, host caching may result in Linux delaying all
writes until the host cache is nearly full and then writing out all these changes at once, possibly stalling
VM execution for minutes. This can result in I/O errors in the guest as I/O requests time out there. </p>
</li>
<li>
<p>Physical memory is often wasted as guest OSes typically have their own I/O caches, which may result in the
data being cached twice, in both the guest and the host caches, for little effect. </p>
</li>
</ul>
<p>If you decide to disable host I/O caching for the above reasons, <ph
conkeyref="vbox-conkeyref-phrases/product-name"/> uses its own small cache to buffer writes, but no read caching
since this is typically already performed by the guest OS. In addition, <ph
conkeyref="vbox-conkeyref-phrases/product-name"/> fully supports asynchronous I/O for its virtual SATA, SCSI,
and SAS controllers through multiple I/O threads. </p>
<p>Since asynchronous I/O is not supported by IDE controllers, for performance reasons, you may want to leave host
caching enabled for your VM's virtual IDE controllers. </p>
<p>For this reason, <ph conkeyref="vbox-conkeyref-phrases/product-name"/> enables you to configure whether the host
I/O cache is used for each I/O controller separately. Either select the <b outputclass="bold">Use Host I/O
Cache</b> check box in the <b outputclass="bold">Storage</b> settings for a given virtual storage controller, or
use the following <userinput>VBoxManage</userinput> command to disable the host I/O cache for a virtual storage
controller: </p>
<pre xml:space="preserve">VBoxManage storagectl "VM name" --name <controllername> --hostiocache off</pre>
<p>See <xref href="vboxmanage-storagectl.dita"/>. </p>
<p>For the above reasons, <ph conkeyref="vbox-conkeyref-phrases/product-name"/> uses SATA controllers by default for
new virtual machines. </p>
</body>
</topic>
|
