February 2026 - Users - libvirt List Archives

Writeback vs default cache modes
by João Jandre 05 Mar '26

05 Mar '26

Hi, all I've been reading the QEMU documentation, the Libvirt documentation, as well as doing some testing and code investigation regarding disk cache modes. In the Libvirt documentation, it is stated that the disk driver cache modes accepted are "default", "none", "writethrough", "writeback", "directsync" and "unsafe". Analyzing the code, we can see that this is somewhat reflected on the cache modes that QEMU documents on the -drive option (https://qemu-project.gitlab.io/qemu/system/invocation.html) https://github.com/libvirt/libvirt/blob/04c1f458313e9001f5a804a898408e1f498… However, the default option (when we do not define the "cache" option) is different from other options and does not seem to map to any option on the Qemu side. I see that, from testing and analyzing the code, if the default (not defining the "cache" options) is used, cache.direct and cache.no-flush are not informed; also, the write-cache option is not informed. Just for comparison, here is a disk defined with cache=writeback: XML: |<disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='writeback'/> <source file='/mnt/a66f48f5-13c6-3676-b320-a15d32bbf32f/c0e925a9-6697-4ee9-8abf-d36c7a95cea4' index='2'/> <backingStore type='file' index='3'> <format type='qcow2'/> <source file='/mnt/a66f48f5-13c6-3676-b320-a15d32bbf32f/0db52809-9f33-43ac-8151-5452e9dee330'/> <backingStore/> </backingStore> <target dev='vda' bus='virtio'/> <serial>c0e925a966974ee98abf</serial> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> | Generated QEMU command: |-blockdev {"driver":"file","filename":"/mnt/a66f48f5-13c6-3676-b320-a15d32bbf32f/c0e925a9-6697-4ee9-8abf-d36c7a95cea4","node-name":"libvirt-2-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":false,"no-flush":false},"driver":"qcow2","file":"libvirt-2-storage","backing":"libvirt-3-format"} -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=libvirt-2-format,id=virtio-disk0,bootindex=2,write-cache=on,serial=c0e925a966974ee98abf | And here is a disk that does not have the cache option: XML: |<disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/mnt/b59eff0f-5b97-37ed-a513-9e1983d1d19b/b430296b-0924-412e-a7b1-ddc3d4c90f83' index='2'/> <backingStore/> <target dev='vdc' bus='virtio'/> <serial>b430296b0924412ea7b1</serial> <alias name='virtio-disk2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </disk> | Generated QEMU command: |blockdev {"driver":"file","filename":"/mnt/b59eff0f-5b97-37ed-a513-9e1983d1d19b/b430296b-0924-412e-a7b1-ddc3d4c90f83","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":null} -device virtio-blk-pci,bus=pci.0,addr=0x8,drive=libvirt-2-format,id=virtio-disk2,serial=b430296b0924412ea7b1 | The QEMU documentation states in the -drive option that the default cache mode is |Writeback| (see https://qemu-project.gitlab.io/qemu/system/invocation.html) so I expected that setting |Writeback| or |Default| as the cache mode on Libvirt would also be the same. I ran some performance tests using both options to try and verify if they were the same, but they are clearly different. For each of the configuration profiles below, I created a VM and ran some fio tests: Combination Disk cache mode Disk Controller IO thread IO policy hds0i default virtio-scsi 0 iouring hds0t default virtio-scsi 0 threads hds1i default virtio-scsi 1 iouring hds1t default virtio-scsi 1 threads hdv0i default virtio 0 iouring hdv0t default virtio 0 threads hdv1i default virtio 1 iouring hdv1t default virtio 1 threads wbs0i writeback virtio-scsi 0 iouring wbs0t writeback virtio-scsi 0 threads wbs1i writeback virtio-scsi 1 iouring wbs1t writeback virtio-scsi 1 threads wbv0i writeback virtio 0 iouring wbv0t writeback virtio 0 threads wbv1i writeback virtio 1 iouring wbv1t writeback virtio 1 threads The fio test results are in a html attached to the email. I would like to understand what the practical difference is between not informing the cache and any other option. I can see that the disk is defined in different way, but just by analyzing the code I was not able to understand what that leads to; also, looking at the performance tests, we clearly see a difference in the results. Would anyone be able to explain what is the expected behavior when the disk is defined in such a way? By the way, I'm using Libvirt 8.0.0 and Qemu 6.2.0. Best regards, João Jandre

3 2

How to properly modify xml in snapshot memory / managed save file
by wrangle 17 Feb '26

17 Feb '26

I am trying to move virtual machines to a new location on the same host. I want to preserve not only snapshots, but domain manage saved state as well as snapshot saved state. The xml is embedded in the snapshot and domain saved state and paths base image files are hard coded. I tried to sed replace the paths and necessary info, but it seems like libvirt expects the xml to be a certain length so it fails parsing. Parsing fails at different points of the embedded xml when I change the length of the path in the embedded xml. How can I properly edit the snapshot and domain managed saved state xml?

2 2

RBD pool not starting "An error occurred, but the cause is unknown"
by me＠vk4msl.com 16 Feb '26

16 Feb '26

Hi all, I've been battling this for about a year now. I've deployed virtual machine hosts running AlpineLinux 3.23 (recently updated from 3.21) which ships `libvirtd` 11.10.0, Ceph 19.2.3 and QEMU 10.1.3. (For reference: previous thread is archived at https://www.spinics.net/linux/fedora/libvirt-users/msg14421.html) I have two RBD pools defined: one is a "high availability" pool which replicates a copy of each block on every node, the other (previously used with OpenNebula) just makes sure there are at least 2 copies of blocks across the nodes (preferrably 3). They're called "ha-images" and "opennebula-images" respectively. "ha-images" starts without issue. It has a configuration like the following: ``` <pool type="rbd"> <name>ha-images</name> <uuid>6beab982-52b3-495b-a4a7-ab7ebb522ef5</uuid> <capacity unit="bytes">16003182362624</capacity> <allocation unit="bytes">184657756160</allocation> <available unit="bytes">6658209792000</available> <source> <host name="172.31.252.1" port="6789"/> <host name="172.31.252.2" port="6789"/> <host name="172.31.252.5" port="6789"/> <host name="172.31.252.6" port="6789"/> <host name="172.31.252.7" port="6789"/> <name>ha</name> <auth type="ceph" username="libvirt"> <secret uuid="c14a16b5-bba5-473a-ae9b-53a9a6b0a4e3"/> </auth> </source> </pool> ``` No issues with it, it starts just fine. "opennebula-images" never starts, its configuration: ``` <pool type="rbd"> <name>opennebula-images</name> <uuid>fcaa2fa8-f0d2-4919-9168-756a9f4ad7ee</uuid> <capacity unit="bytes">16003182362624</capacity> <allocation unit="bytes">7893286499025</allocation> <available unit="bytes">6658213388288</available> <source> <host name="172.31.252.1" port="6789"/> <host name="172.31.252.2" port="6789"/> <host name="172.31.252.5" port="6789"/> <host name="172.31.252.6" port="6789"/> <host name="172.31.252.7" port="6789"/> <name>one</name> <auth type="ceph" username="libvirt"> <secret uuid="c14a16b5-bba5-473a-ae9b-53a9a6b0a4e3"/> </auth> </source> </pool> ``` The `libvirt` user I created in Ceph is able to list the RBD pool: ``` lithium:~# rbd --id libvirt ls -p one | head gapmx-old-vda gapmx-old-vdb gapmx-testing-vda gapmx-testing-vdb gapmx-vda gapmx-vdb mastodon-vda mastodon-vdb mastodon-vdd mastodon-vde ``` Starting it, `libvirt` merely tells me: "An error occurred, but the cause is unknown". No logs written anywhere, no explanation. Just "computer says no". Yet, if I hand-configure my virtual machines, I can still mount RBD volumes as virtual disks within either pool. I just can't browse them via `virsh` or `virt-manager` on the `opennebula-images` pool like I can for the `ha-images` pool. Where should I be looking for the error? What did I do wrong that makes it refuse to start?

4 3

How to enable 'nesting' in the virtual machine XML config for an LXC container?
by ttk_foo＠internet.ru 13 Feb '26

13 Feb '26

The old LXC-managed container had these settings: lxc.apparmor.allow_nesting = 1 Is it possible to specify this somewhere in the libvirt/lxc container settings?

1 0

Guest to Guest Communication in NAT Network
by fc26wuqa＠studserv.uni-leipzig.de 03 Feb '26

03 Feb '26

Hi, I have a nat based network. I want to communicate between two hosts on a secure basis (not http) I have two guests, one guest is reachable to the outside internet via git.example.de. git.example.de has a DNS Entry for my supervisor. On my Supervisor I am forwarding the port 443 the respective guest. Is it possible to access a guest via its domain name (git.example.de) from a guest that is in the same network? I looked at the tcpdump, and traffic goes through to the guest, but I think its not sending anything back. When trying to curl a guest from a guest it only says: Trying 123.45.67.89:80 ... Is there anything I can do? Thank you. Best, dot

2 1

Migration pull vs. push
by johnt＠panix.com 03 Feb '26

03 Feb '26

The migration examples I've found I was able to repeat the steps successfully. They follow the pattern of what I am calling a "push". You are logged into the source hypervisor you want to migrate from and run something like "virsh migrate --live <local VM name> qemu://<Destination Hypervisor>/system" My question is if libvirt support a "pull" migration? Where the user starts on the destination node and "pulls" a VM to itself from the source node. -John

3 2