Configuring a Virtual Disk Cache Mode
- WHAT?
Virtual machines use disk caches to make reading and writing operations more effective.
- WHY?
Selecting an appropriate disk cache mode affects performance and data security of a virtual machine.
- EFFORT
It takes up to 15 minutes to understand what a virtual disk cache is and how individual cache modes are different. To configure a cache mode either by using Virtual Machine Manager or
virsh
takes another 10 minutes.- REQUIREMENTS
Advanced knowledge of the Linux system administration.
A working
libvirt
environment with at least one virtual machine set up.Installed Virtual Machine Manager application.
root
privileges.
1 Virtual disk cache #
A disk cache is a memory used to speed up the process of storing and accessing data from the hard disk. Physical hard disks have their cache integrated as a standard feature. For virtual disks, the cache uses VM Host Server's memory and you can fine-tune its behavior.
1.1 How does a disk cache work? #
Normally, a disk cache stores the most recent and frequently used programs and data. When a user or program requests data, the operating system first checks the disk cache. If the data is there, the operating system quickly delivers the data to the program instead of rereading the data from the disk.
1.2 Benefits of disk caching #
Caching of virtual disk devices affects the overall performance of guest machines. You can improve the performance by optimizing the combination of cache mode, disk image format, and storage subsystem.
2 Virtual disk cache modes #
A virtual disk is an essential part of a virtual machine (VM). To speed up disk reading and writing operations, you can enable a caching mechanism. This article describes available disk caching modes and how they behave with regards to data integrity and live migration of VMs. The cache modes are sorted from the safest one to the least safe one.
If you do not specify a cache mode, writeback
is used by default.
- none
The host cache is bypassed, and reads and writes happen directly between the hypervisor and the storage device. Because the actual storage device may report a write as completed when the data is still placed in its write queue only, the guest's virtual storage adapter is informed that there is a writeback cache. This mode is equivalent to direct access to the host's disk.
- writethrough
Writes are reported as completed only when the data has been written to the storage device, which happens immediately. The guest's virtual storage adapter is informed that there is no writeback cache, so the guest does not need to send flush commands to manage data integrity.
- directsync
Similar to writethrough but the host cache is bypassed.
- writeback
writeback
uses the host disk cache. Writes are reported to the guest as completed when they are placed in the host cache. Cache management handles writing cached data to the storage device, which can happen later. The guest's virtual storage adapter is informed of the writeback cache and therefore expected to send flush commands as needed to manage data integrity.- unsafe
Similar to the writeback mode, except all flush commands from the guests are ignored. Using this mode implies that the user prioritizes performance gain over data security.
Warning: Possible data lossUsing the unsafe mode can cause data loss in case of a host failure. Do not use this mode for production workloads.
- default
The default cache mode of the used hypervisor is enabled.
2.1 Cache modes and data integrity #
- writethrough, none, directsync
These modes are considered to be the safest when the guest operating system uses flushes as needed. For unsafe or unstable guests, use writethrough or directsync.
- writeback
This mode informs the guest of the presence of a write cache, and it relies on the guest to send flush commands as needed to maintain data integrity within its disk image.
WarningUsing the writeback mode exposes the guest to data loss in case of a host failure. It is caused by the gap between when a write is reported as completed and when it is written to the storage device.
- unsafe
This mode is similar to writeback caching, except the guest flush commands are ignored.
Warning: Possible data lossUsing the unsafe mode can cause data loss in case of a host failure. Do not use this mode for production workloads.
2.2 Cache modes and live migration #
The caching of storage data restricts the configurations that support live migration.
Currently, only raw
and qcow2
image formats can be used
for live migration. If a clustered file system is used, all cache modes support live
migration. Otherwise, the only cache mode that supports live migration on read/write shared
storage is none
.
The libvirt
management layer includes checks for migration compatibility based on several
factors. If the guest storage is hosted on a clustered file system, is read-only, or is
marked shareable, then the cache mode is ignored when determining if migration can be
allowed. Otherwise, libvirt
does not allow migration unless the cache mode is set to
none
.
If you need to do a live migration with a different cache mode than
none
, use the --unsafe
option, for example:
>
virsh migrate --live --unsafe
Be aware that this option may cause loss of data that the migrated VM is caching.
When using the native
asynchronous I/O mode (AIO) in libvirt
, the
cache mode none
is required. Using a different caching mode switches the
AIO mode back to the default threads
.
3 Configure using Virtual Machine Manager #
Start Virtual Machine Manager, left-click the name of an existing VM, and select
to open the VM console window.From the VM console window, click
› to open the detailed information about the VM's virtual hardware.From the left list, select the disk for which you want to configure the cache mode and unfold its
.From the
drop-down list, select the cache mode that matches your scenario.Confirm with
.
4 Configure using virsh
#
Open your favorite terminal application and identify the VM.
>
sudo
virsh list --all
Id Name State --------------------------- - sle15sp5 shut offIdentify the disk for which you want to configure the cache mode.
>
sudo
virsh domblklist sle15sp5
Target Source ------------------------------------------ vda /home/example-user/virt/sle15.qcow2 sda -Dump the XML definition of the VM to a file.
>
sudo
virsh dumpxml sle15sp5 > virt/sle15sp5.xml
Edit the dumped XML file and search for a
<disk/>
definition that includes a path to your disk in the<source>
definition, for example:<disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='writethrough'/> <source file='/home/example-user/virt/sle15.qcow2'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </disk>
Update the
<driver/>
definition and appendcache='CACHE_TYPE'
. Replace CACHE_TYPE with one of the caching modes described in Section 2, “Virtual disk cache modes”. For example:<driver name='qemu' type='qcow2' cache='writethrough'/>
Save the updated XML definition and update the VM accordingly, for example:
>
sudo
sudo virsh define virt/sle15sp5.xml
Domain 'sle15sp5' defined from virt/sle15sp5.xml
5 Legal Notice #
Copyright© 2006–2024 SUSE LLC and contributors. All rights reserved.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”.
For SUSE trademarks, see https://www.suse.com/company/legal/. All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks.
All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors, nor the translators shall be held liable for possible errors or the consequences thereof.