- Users - libvirt List Archives

purge question about https://libvirt.org/kbase/live_full_disk_backup.html
by pjbondi＠systemdatabase.com 25 Aug '25

25 Aug '25

Hello libvirt users: On QNAP, this is my outcome from the following step "2. Enumerate the current block device(s) in use, again. Notice that the current disk image in use is the above-created overlay, overlay1.qcow2:" I'm showing both pre- and post-execution from the shell. There's 2 files. Should both files be purged according to the instruction "Now you can safely discard the overlay image"? + virsh domblklist 9c7d2c4d-9c28-44bd-8da9-642a63b25c39 Target Source ------------------------------------------------------------------------------- vda /share/Virtual-Machines/SHACKLETON1210/SHACKLETON1210_00.1755932401 hda /share/Virtual-Machines/debian-12.10.0-amd64-netinst.iso ls -alF /share/CACHEDEV2_DATA/Virtual-Machines/SHACKLETON1210/SHACKLETON1210_00.1755932401* -rw-r--r-- 1 admin administrators 177602560 2025-08-23 05:02 SHACKLETON1210_00.1755932401 -rw------- 1 admin administrators 40470118400 2025-08-23 03:42 SHACKLETON1210_00.1755932401.1755934525

1 0

FYI: Planned list outage Mon 25th Aug from 10:00 JST
by Daniel P. Berrangé 20 Aug '25

20 Aug '25

We have a planned outage of the libvirt.org mailing lists on Monday 25th August. The outage is anticipated to begin at approx 10:00 JST (Japan), and all going well, should last no more than a couple hours. There will be various cosmetic changes to the lists.libvirt.org web interface after the upgrade, due to the newer software versions introduced. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

1 0

Re: Clarification Needed: virsh snapshot-delete Behavior with External Snapshots (--disk-only)
by Peter Krempa 25 Jul '25

25 Jul '25

On Wed, Jul 23, 2025 at 04:57:57 +0000, P, Rajasekar via Users wrote: > Hello libvirt community, > > I am seeking clarification on the behavior of `virsh snapshot-delete` when used with external snapshots (created with the `--disk-only` option). > > **Environment:** > - libvirt version: 10.5.0 Note that this was released almost a year ago. > - Kernel version: 5.14.0-503.22.1.el9_5.x86_64 > - Disk image format: qcow2 > - Host OS: RHEL 9.5 > > **Steps to reproduce:** > 1. Create an external snapshot: > virsh snapshot-create-as --domain <vm> --name snap1 --disk-only --atomic > 2. Delete the snapshot: > virsh snapshot-delete <vm> --snapshotname snap1 > > **Observed behavior:** > - Changes from the overlay (snapshot) file are merged into the base image. > - The snapshot metadata is removed from libvirt. > - The snapshot file remains on disk (appears orphaned). You mean that the original overlay images remained on disk? e.g. /path/to/originalimage.snap1 ? > **Questions:** > - Is the observed automatic merge of the overlay file into the base image during `snapshot-delete` the intended behavior for external snapshots in recent libvirt versions? Or we need separate `blockcommit` step. Yes it is intended, because deleting a snapshot is effectively meaning "I don't want to return to this point any more" so the extra overlay makes no sense. > - Should the snapshot file be deleted automatically, or is manual cleanup required? If you mean the overlay, then yes it should have been deleted. > - Is there any official documentation that clarifies this behavior for external snapshots, as most documentation seems to focus on internal snapshots? The semantics of external and internal snapshots are supposed to be indentical. I don't think we document to a deep extent the actual behaviour WRT to the disk files.

1 0

Clarification Needed: virsh snapshot-delete Behavior with External Snapshots (--disk-only)
by P, Rajasekar 23 Jul '25

23 Jul '25

Hello libvirt community, I am seeking clarification on the behavior of `virsh snapshot-delete` when used with external snapshots (created with the `--disk-only` option). **Environment:** - libvirt version: 10.5.0 - Kernel version: 5.14.0-503.22.1.el9_5.x86_64 - Disk image format: qcow2 - Host OS: RHEL 9.5 **Steps to reproduce:** 1. Create an external snapshot: virsh snapshot-create-as --domain <vm> --name snap1 --disk-only --atomic 2. Delete the snapshot: virsh snapshot-delete <vm> --snapshotname snap1 **Observed behavior:** - Changes from the overlay (snapshot) file are merged into the base image. - The snapshot metadata is removed from libvirt. - The snapshot file remains on disk (appears orphaned). **Questions:** - Is the observed automatic merge of the overlay file into the base image during `snapshot-delete` the intended behavior for external snapshots in recent libvirt versions? Or we need separate `blockcommit` step. - Should the snapshot file be deleted automatically, or is manual cleanup required? - Is there any official documentation that clarifies this behavior for external snapshots, as most documentation seems to focus on internal snapshots? Thank you for your help and clarification! Best regards, Raj.

1 0

Hanging migration leaving domain in paused state
by Yangchen Ye 22 Jul '25

22 Jul '25

Hi, We are running libvirt 8.0.0, and sometimes live migration could not finish (because the guest is dirtying the memory too fast). We implemented a monitor that increases max downtime when it observed that "Data Remaining" bumps up. But we found a strange sequence of events from the monitor, which leads to a paused domain on the destination hypervisor: The monitor sees Data Remaining bumping up and increases max downtime up to 20 seconds, but weird thing is that after a period of time, it started reporting "Data Remaining" and "Data Total" is both 0, but the migration job is still unfinished: "Migration in progress - DataTotal: 85 904728064, DataRemaining: 22201458688, TimeElapsed: 20005, MaxDowntime: 500, DirtyRate: 0" "Migration in progress - DataTotal: 85904728064, DataRemaining: 43801825280, TimeElapsed: 10005, MaxDowntime: 500, DirtyRate: 0" "Migration in progress - DataTotal: 85904728064, DataRemaining: 52382912512, TimeElapsed: 10004, MaxDowntime: 500, DirtyRate: 0" (DataRemaining bumps up, we start increasing max downtime) "Migration in progress - DataTotal: 85904728064, DataRemaining: 4219596800, TimeElapsed: 40004, MaxDowntime: 1500, DirtyRate: 0" (Last poll where we see the job info) After which monitor logs "Migration in progress - DataTotal: 0, DataRemaining: 0, TimeElapsed: 40004, MaxDowntime: 13500, DirtyRate: 0" The domain is always running on the source hypervisor but there is a paused domain on the destination hypervisor which is paused at start up. Trying to understand what might have happened: - Is this a known issue for live migrating high memory activity guests and the way we interact with libvirt? - What is the recommended way to ensure that a started live migration always run to completion if we don't care about downtime? Appreciate any help here Yangchen Ye

1 1

How to disable sysctl calls performed by libvirt?
by Chimmie Firefly 11 Jul '25

11 Jul '25

Hello, I have an issue whenever using `/proc/sys/ipv6/conf` as read-only mountpoint. While the libvirt by itself is running fine, I'm unable to create NAT network interfaces because of the following error: ``` 2025-07-05 19:33:32.821+0000: 100: error : networkSetIPv6Sysctl:1847 : cannot write to '/proc/sys/net/ipv6/conf/virbr0/disable_ipv6' on bridge 'virbr0': Read-only file system 2025-07-05 19:33:32.841+0000: 100: error : virNetDevSetIFFlag:601 : Cannot get interface flags on 'virbr0': No such device 2025-07-05 19:33:32.947+0000: 100: error : virNetlinkDelLink:688 : error destroying network device virbr0: No such device ``` While using iproute2 and bridge utils, I'm able to create and configure new bridge device, along with attaching the VM to the interface. I've used the following commands: ``` sysctl -w net.ipv4.ip_forward=1 brctl addbr br0 ip link set br0 up ip addr add 192.168.100.1/24 dev br0 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A FORWARD -i br0 -o eth0 -j ACCEPT iptables -A FORWARD -i eth0 -o br0 -m state --state RELATED,ESTABLISHED -j ACCEPT ``` Is libvirt allowing to disable sysctl calls in the configuration files? If so, what should I set in the config?

2 1

fsck unable to fix fs issue
by ola . 08 Jul '25

08 Jul '25

I am able to boot VMs by using rbd as the root disk. When I restart and stop the VM everything works fine however, anytime the host goes down say due to a power outage, when next I try to boot the VM, I run into a situation where the root disk gets corrupted and get stuck at "initramfs". I have tried to fix this but to no avail. Here are the errors I get when I try yo use fix the fs issue with fsck manually. done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... [ 7.760625] Btrfs loaded, crc32c=crc32c-intel, zoned=yes, fsverity=yes Scanning for Btrfs filesystems done. Begin: Will now check root file system ... fsck from util-linux 2.37.2 [/usr/sbin/fsck.ext4 (1) -- /dev/vda1] fsck.ext4 -a -C0 /dev/vda1 [ 7.866954] blk_update_request: I/O error, dev vda, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0 cloudimg-rootfs: recovering journal [ 8.164279] blk_update_request: I/O error, dev vda, sector 227328 op 0x1:(WRITE) flags 0x800 phys_seg 24 prio class 0 [ 8.168272] Buffer I/O error on dev vda1, logical block 0, lost async page write [ 8.170413] Buffer I/O error on dev vda1, logical block 1, lost async page write [ 8.172545] Buffer I/O error on dev vda1, logical block 2, lost async page write [ 8.174601] Buffer I/O error on dev vda1, logical block 3, lost async page write [ 8.176651] Buffer I/O error on dev vda1, logical block 4, lost async page write [ 8.178694] Buffer I/O error on dev vda1, logical block 5, lost async page write [ 8.180601] Buffer I/O error on dev vda1, logical block 6, lost async page write [ 8.182641] Buffer I/O error on dev vda1, logical block 7, lost async page write [ 8.184710] Buffer I/O error on dev vda1, logical block 8, lost async page write [ 8.186744] Buffer I/O error on dev vda1, logical block 9, lost async page write [ 8.188748] blk_update_request: I/O error, dev vda, sector 229392 op 0x1:(WRITE) flags 0x800 phys_seg 8 prio class 0 [ 8.191433] blk_update_request: I/O error, dev vda, sector 229440 op 0x1:(WRITE) flags 0x800 phys_seg 32 prio class 0 [ 8.194204] blk_update_request: I/O error, dev vda, sector 229480 op 0x1:(WRITE) flags 0x800 phys_seg 16 prio class 0 [ 8.196976] blk_update_request: I/O error, dev vda, sector 229512 op 0x1:(WRITE) flags 0x800 phys_seg 8 prio class 0 [ 8.243612] blk_update_request: I/O error, dev vda, sector 229544 op 0x1:(WRITE) flags 0x800 phys_seg 8 prio class 0 [ 8.246068] blk_update_request: I/O error, dev vda, sector 229640 op 0x1:(WRITE) flags 0x800 phys_seg 32 prio class 0 [ 8.248668] blk_update_request: I/O error, dev vda, sector 229688 op 0x1:(WRITE) flags 0x800 phys_seg 8 prio class 0 [ 8.251174] blk_update_request: I/O error, dev vda, sector 229704 op 0x1:(WRITE) flags 0x800 phys_seg 8 prio class 0 fsck.ext4: Input/output error while recovering journal of cloudimg-rootfs fsck.ext4: unable to set superblock flags on cloudimg-rootfs cloudimg-rootfs: ********** WARNING: Filesystem still has errors ********** fsck exited with status code 12 done. Failure: File system check of the root filesystem failed The root filesystem on /dev/vda1 requires a manual fsck BusyBox v1.30.1 (Ubuntu 1:1.30.1-7ubuntu3.1) built-in shell (ash) Enter 'help' for a list of built-in commands. (initramfs) fsck.ext4 -f -y /dev/vda1 e2fsck 1.46.5 (30-Dec-2021) [ 24.286341] print_req_error: 174 callbacks suppressed [ 24.286358] blk_update_request: I/O error, dev vda, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0 cloudimg-rootfs: recovering journal [ 24.552343] blk_update_request: I/O error, dev vda, sector 227328 op 0x1:(WRITE) flags 0x800 phys_seg 24 prio class 0 [ 24.556674] buffer_io_error: 5222 callbacks suppressed [ 24.558925] Buffer I/O error on dev vda1, logical block 0, lost async page write [ 24.562116] Buffer I/O error on dev vda1, logical block 1, lost async page write [ 24.565161] Buffer I/O error on dev vda1, logical block 2, lost async page write [ 24.567872] Buffer I/O error on dev vda1, logical block 3, lost async page write [ 24.570586] Buffer I/O error on dev vda1, logical block 4, lost async page write [ 24.573418] Buffer I/O error on dev vda1, logical block 5, lost async page write [ 24.575940] Buffer I/O error on dev vda1, logical block 6, lost async page write [ 24.578622] Buffer I/O error on dev vda1, logical block 7, lost async page write [ 24.581386] Buffer I/O error on dev vda1, logical block 8, lost async page write [ 24.583873] Buffer I/O error on dev vda1, logical block 9, lost async page write [ 24.586410] blk_update_request: I/O error, dev vda, sector 229392 op 0x1:(WRITE) flags 0x800 phys_seg 8 prio class 0 [ 24.589821] blk_update_request: I/O error, dev vda, sector 229440 op 0x1:(WRITE) flags 0x800 phys_seg 32 prio class 0 [ 24.593380] blk_update_request: I/O error, dev vda, sector 229480 op 0x1:(WRITE) flags 0x800 phys_seg 16 prio class 0 [ 24.596615] blk_update_request: I/O error, dev vda, sector 229512 op 0x1:(WRITE) flags 0x800 phys_seg 8 prio class 0 [ 24.643829] blk_update_request: I/O error, dev vda, sector 229544 op 0x1:(WRITE) flags 0x800 phys_seg 8 prio class 0 [ 24.646924] blk_update_request: I/O error, dev vda, sector 229640 op 0x1:(WRITE) flags 0x800 phys_seg 32 prio class 0 [ 24.650051] blk_update_request: I/O error, dev vda, sector 229688 op 0x1:(WRITE) flags 0x800 phys_seg 8 prio class 0 [ 24.653128] blk_update_request: I/O error, dev vda, sector 229704 op 0x1:(WRITE) flags 0x800 phys_seg 8 prio class 0 fsck.ext4: Input/output error while recovering journal of cloudimg-rootfs fsck.ext4: unable to set superblock flags on cloudimg-rootfs cloudimg-rootfs: ********** WARNING: Filesystem still has errors ********** This is what my rbd disk looks like <disk type='network' device='disk'> <driver name='qemu' type='raw' cache='none' io='native'/> <auth username='dove'> <secret type='ceph' uuid='b608caae-5eb4-45cc-bfd4-0b4ac11c7613'/> </auth> <source protocol='rbd' name='vms/wing-64700f1d-8c469a54-3f50-4d1e-9db2-2b6ea5f3d14a'> <host name='x.168.1.x' port='6789'/> </source> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> So, my questions are; - How do I prevent this from happening as i have tried different options like changing the "cache" value for the disk template? - How can this be fixed? Thanks

2 1

RBD Namespace
by Rodrigo Prieto 23 Jun '25

23 Jun '25

Hello, I want to connect to an RBD pool specifying the namespace, but it doesn’t work. If I connect directly to the pool, it works. For example: <source protocol="rbd" name="rbd-pool/vm"> But when I try to specify the namespace like this, I cannot connect: <source protocol="rbd" name="rbd-pool/vm" namespace="vms"> <source protocol="rbd" name="rbd-pool/vms/vm"> Error al iniciar dominio: error interno: process exited while connecting to monitor: 2025-06-20T22:54:55.076193Z qemu-system-x86_64: -blockdev {"driver":"rbd","pool":"rbd-pool","image":"loli/mari","server":[{"host":"ceph-admin","port":"6789"}],"user":"admin","auth-client-required":["cephx","none"],"key-secret":"libvirt-2-storage-auth-secret0","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}: error reading header from loli/mari: No such file or directory Using the rbd command from the terminal, I can connect both ways; the error occurs only with libvirt. I’m using the following versions on Debian 12: libvirtd (libvirt) 9.0.0 QEMU emulator version 7.2.17 (Debian 1:7.2+dfsg-7+deb12u13) Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers Thanks.

2 2

Re: Question about managed/unmanaged persistent reservation disks
by Michal Prívozník 18 Jun '25

18 Jun '25

On 6/10/25 19:15, Simon Coter wrote: > Adding users DL to possibly reach out a wider audience. > > Simon > Dropping devel list as this is users list material. >> On Jun 9, 2025, at 7:28 PM, Annie Li <annie.li(a)oracle.com> wrote: >> >> Hello, >> >> I've been looking at source code related to persistent reservation and >> got confused a little bit about managed persistent reservation disks. >> For disk configured with 'managed=yes' as the following, >> >> <reservations managed='yes'> >> <source type='unix' path='/var/lib/libvirt/qemu/domain-7- >> brml10g19-iscsi-rese/pr-helper0.sock' mode='client'/> >> </reservations> >> >> libvirt is responsible for starting a pr-helper program with a >> specific associated socket file. The following source code shows that >> there is only one pr-helper and socket file associated with the >> managed disks for one VM. >> >> const char * >> qemuDomainGetManagedPRAlias(void) >> { >> return "pr-helper0"; >> } >> char * >> qemuDomainGetManagedPRSocketPath(qemuDomainObjPrivate *priv) >> { >> return g_strdup_printf("%s/%s.sock", priv->libDir, >> qemuDomainGetManagedPRAlias()); >> } >> >> So if the VM is booted with multiple disks configured with >> 'managed=yes' for reservation, I suppose these multiple disks share >> the this managed pr-helper and socket file. However, per the qemu >> document, https://www.qemu.org/docs/master/interop/pr-helper.html >> <https://www.qemu.org/docs/master/interop/pr-helper.html> >> "It is invalid to send multiple commands concurrently on the same >> socket. It is however possible to connect multiple sockets to the >> helper and send multiple commands to the helper for one or more file >> descriptors." >> This certainly did not use to be the case. IIRC this was discussed in this very old thread: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/UUL3… Maybe QEMU has some internal lock that does the right thing and serializes requests? Michal >> Due to this limitation above, only one persistent reservation disk is >> allowed as managed in theory. However, libvirt doesn't throw out any >> error or warning when the VM is booted up with multiple managed >> persistent reservation disks. I am wondering if I've missed something >> here? >> >> For unmanaged persistent reservation disks, libvirt doesn't start the >> pr-helper program for them. It is user's responsibility to start this >> program with customized socket file per disk, but the complexity >> increases with numbers of persistent reservation disks, especially in >> the case of hotplug/hotunplog. Is there any plan to support multiple >> managed persistent reservation disks with separate pr-helper/socket file? >> >> Any suggestions/clarifications are greatly appreciated. >> >> Thanks >> >> Annie >> >

3 7

significant delay live migrating a vm with an sr-iov interface
by Paul B. Henson 10 Jun '25

10 Jun '25

I'm using libvirt under Debian 12 (9.0.0-4+deb12u2 w/qemu 7.2+dfsg-7+deb12u12). I have a vm using sr-iov, and configured it with a failover macvtap interface so I could live migrate it. However, there is a significant delay at the end of the migration resulting in a lot of lost traffic. If I only have the macvtap interface, migration completes immediately at the end of the transfer of memory with no loss of traffic. I enabled debug logging, and found the following. On the source system, it logs that the system is paused for the cutover: 2025-04-30 01:08:12.526+0000: 1696180: debug : qemuMigrationAnyCompleted:1957 : Migration paused before switchover at that point, for almost a minute, the source system just keeps printing the same statistics: 2025-04-30 01:08:12.923+0000: 1696272: info : qemuMonitorJSONIOProcessLine:208 : QEMU_MONITOR_RECV_REPLY: mon=0x7f8fdc0ad2f0 reply={"return": {"expected-downtime": 300, "status": "device", "setup-time": 297, "total-time": 26107, "ram": {"total": 137452265472, "postcopy-requests": 0, "dirty-sync-count": 3, "multifd-bytes": 2821784576, "pages-per-second": 297855, "downtime-bytes": 13208, "page-size": 4096, "remaining": 0, "postcopy-bytes": 0, "mbps": 9786.9158461538464, "transferred": 3117658825, "dirty-sync-missed-zero-copy": 0, "precopy-bytes": 295861041, "duplicate": 32874480, "dirty-pages-rate": 56, "skipped": 0, "normal-bytes": 2804301824, "normal": 684644}}, "id": "libvirt-577"} [...] 2025-04-30 01:09:06.290+0000: 1696272: info : qemuMonitorJSONIOProcessLine:208 : QEMU_MONITOR_RECV_REPLY: mon=0x7f8fdc0ad2f0 reply={"return": {"expected-downtime": 300, "status": "device", "setup-time": 297, "total-time" : 79474, "ram": {"total": 137452265472, "postcopy-requests": 0, "dirty-sync-count": 3, "multifd-bytes": 2821784576, "pages-per-second": 297855, "downtime-bytes": 13208, "page-size": 4096, "remaining": 0, "postcopy-bytes" : 0, "mbps": 9786.9158461538464, "transferred": 3117658825, "dirty-sync-missed-zero-copy": 0, "precopy-bytes": 295861041, "duplicate": 32874480, "dirty-pages-rate": 56, "skipped": 0, "normal-bytes": 2804301824, "normal": 684644}}, "id": "libvirt-629"} until finally it completes: 2025-04-30 01:09:06.327+0000: 1696272: info : qemuMonitorJSONIOProcessLine:203 : QEMU_MONITOR_RECV_EVENT: mon=0x7f8fdc0ad2f0 event={"timestamp": {"seconds": 1745975346, "microseconds": 327382}, "event": "MIGRATION", "dat a": {"status": "completed"}} On the destination side, it says something about negotiating failover for the network link: 2025-04-30 01:08:12.923+0000: 1384503: info : qemuMonitorJSONIOProcessLine:203 : QEMU_MONITOR_RECV_EVENT: mon= 0x7fc7900ab2f0 event={"timestamp": {"seconds": 1745975292, "microseconds": 922783}, "event": "FAILOVER_NEGOTIA TED", "data": {"device-id": "ua-sr-iov-backup"}} Then nothing happens for about a minute until it says it is done: 2025-04-30 01:09:06.328+0000: 1384503: debug : qemuMonitorJSONIOProcessLine:189 : Line [{"timestamp": {"second s": 1745975346, "microseconds": 327991}, "event": "MIGRATION", "data": {"status": "completed"}}] Any thoughts on what is going on here to cause this delay? It's clearly somehow related to the sv-iov component of the migration. Thanks much…

2 1