Occasionally, some host file systems provide very poor writing performance and as a consequence cause the guest to time out IDE/SATA commands. This is normal behavior and should normally cause no real problems, as the guest should repeat commands that have timed out. However, guests such as some Linux versions have severe problems if a write to an image file takes longer than about 15 seconds. Some file systems however require more than a minute to complete a single write, if the host cache contains a large amount of data that needs to be written.
The symptom for this problem is that the guest can no longer access its files during large write or copying operations, usually leading to an immediate hang of the guest.
In order to work around this problem, the true fix is to use a faster file system that does not exhibit such unacceptable write performance, it is possible to flush the image file after a certain amount of data has been written. This interval is normally infinite, but can be configured individually for each disk of a VM.
For IDE disks use the following command:
VBoxManage setextradataVM-name
"VBoxInternal/Devices/piix3ide/0/LUN#[x
]/Config/FlushInterval" [b
]
For SATA disks use the following command:
VBoxManage setextradataVM-name
"VBoxInternal/Devices/ahci/0/LUN#[x
]/Config/FlushInterval" [b
]
[
specifies the
disk for IDE. x
]0
represents the master device
on the first channel, 1
represents the slave
device on the first channel, 2
represents the
master device on the second channel, and 3
represents the slave device on the second channel. For SATA, use
values between 0
and 29
.
This configuration option applies to disks only. Do not use this
option for CD or DVD drives.
The unit of the interval
([
) is the
number of bytes written since the last flush. The value for it
must be selected so that the occasional long write delays do not
occur. Since the proper flush interval depends on the
performance of the host and the host filesystem, finding the
optimal value that makes the problem disappear requires some
experimentation. Values between 1000000 and 10000000 (1 to 10
megabytes) are a good starting point. Decreasing the interval
both decreases the probability of the problem and the write
performance of the guest. Setting the value unnecessarily low
will cost performance without providing any benefits. An
interval of 1 will cause a flush for each write operation and
should solve the problem in any case, but has a severe write
performance penalty.
b
]
Providing a value of 0
for
[
is treated as
an infinite flush interval, effectively disabling this
workaround. Removing the extra data key by specifying no value
for b
][
has the
same effect.
b
]
If desired, the virtual disk images can be flushed when the guest issues the IDE FLUSH CACHE command. Normally these requests are ignored for improved performance. The parameters below are only accepted for disk drives. They must not be set for DVD drives.
To enable flushing for IDE disks, issue the following command:
$ VBoxManage setextradataVM-name
"VBoxInternal/Devices/piix3ide/0/LUN#[x
]/Config/IgnoreFlush" 0
[
specifies the
disk. is 0 for the master device on the first channel, 1 for the
slave device on the first channel, 2 for the master device on
the second channel or 3 for the master device on the second
channel.
x
]
To enable flushing for SATA disks, issue the following command:
$ VBoxManage setextradata VM-name
"VBoxInternal/Devices/ahci/0/LUN#[x]/Config/IgnoreFlush" 0
The value [x] that selects the disk can be a value between 0 and 29.
Note that this does not affect the flushes performed according to the configuration described in Section 5.2.1, “Guest Shows IDE/SATA Errors for File-Based Images on Slow Host File System”. Restoring the default of ignoring flush commands is possible by setting the value to 1 or by removing the key.
Many multicore processors support some form of frequency boosting, which means that if only one core is utilized, it can run possibly 50% faster or even more than the rated CPU frequency. This causes measured performance to vary somewhat as a function of the momentary overall system load. The exact behavior depends strongly on the specific processor model.
As a consequence, benchmarking on systems which utilize frequency boosting may produce unstable and non-repeatable results. This is especially true if benchmark runs are short, of the order of seconds. To obtain stable results, benchmarks must be run over longer periods of time and with a constant system load apart from the VM being tested.
On some hardware platforms and operating systems, CPU frequency scaling may cause CPU usage reporting to be highly misleading. This happens in situations when the host CPU load is significant but not heavy, such as between 15% to 30% of the maximum.
Most operating systems determine CPU usage in terms of time spent, measuring for example how many nanoseconds the systems or a process was active within one second. However, in order to save energy, systems can significantly scale down CPU speed when the system is not fully loaded. When the CPU is running at for example one half of its maximum speed, the same number of instructions will take roughly twice as long to execute compared to running at full speed.
Depending on the specific hardware and host OS, this effect can very significantly skew the CPU usage reported by the OS. The reported CPU usage can be several times higher than what it would have been had the CPU been running at full speed. The effect can be observed both on the host OS and in a guest OS.
CPU usage reporting tools which come with Windows, such as Task Manager or Resource Monitor, do not take the time spent processing hardware interrupts into account. If the interrupt load is heavy, with thousands of interrupts per second, CPU usage may be significantly underreported.
This problem affects Windows as both host and guest OS. Sysinternals tools, such as Process Explorer, do not suffer from this problem.
On some hardware platforms and operating systems, virtualization performance is negatively affected by host CPU power management. The symptoms may be choppy audio in the guest or erratic guest clock behavior.
Some of the problems may be caused by firmware and/or host operating system bugs. Therefore, updating the firmware and applying operating systems fixes is recommended.
For optimal virtualization performance, the C1E power state
support in the system's BIOS should be disabled, if such a
setting is available. Not all systems support the C1E power
state. On Intel systems, the Intel C State
setting should be disabled. Disabling other power management
settings may also improve performance. However, a balance
between performance and power consumption must always be
considered.
To use 2D Video Acceleration within Oracle VM VirtualBox, your host's video card should support certain OpenGL extensions. On startup, Oracle VM VirtualBox checks for those extensions, and, if the test fails, this option is silently grayed out.
To find out why it has failed, you can manually execute the following command:
$ VBoxTestOGL --log "log_file_name" --test 2D
It will list the required OpenGL extensions one by one and will show you which one failed the test. This usually means that you are running an outdated or misconfigured OpenGL driver on your host. It can also mean that your video chip is lacking required functionality.