- Users - libvirt List Archives

How to recover from "Display output is not active"
by Jeffrey Walton 12 Sep '25

12 Sep '25

Hi Everyone, I'm working on Ubuntu 22.04.5, amd64, fully patched. It provides QEMU 1:6.2+dfsg-2ubuntu6.26 and libvirt 8.0.0-1ubuntu7.11. The problem I am experiencing is, when the host machine blanks the monitor, I lose the display on the guest when I sit back down at the computer and wake the monitor. The error message (?) in the guest window is, "Display output is not active." The condition happens with both VIRTIO and VGA models. Also see <https://imgur.com/a/tEp73k2>. I have not found a workaround to stop it from happening or recover after it happens. I have to Force Off the VM and then restart the VM to the display back. My host power configuration is: disable sleep, suspend, hibernate and hybrid-sleep via systemd's systemctl. However, I allow the monitor to be turned off after 15 minutes of inactivity. My guest power configuration is whatever the distro provides. Based on my searching, others have experienced the problem. And one fellow says switching to the VGA model fixed it for him. (But no joy for me). Does anyone have any suggestions for a work around? Thanks in advance. (And my apologies if this is the wrong list). Jeff

2 5

QNAP backup of virsh virtual machines and NFS shared drives for Plex, Subversion, Mailbox to OneDrive via rclone
by pjbondi＠systemdatabase.com 10 Sep '25

10 Sep '25

Hello virsh community. https://community.qnap.com/t/qnap-backup-of-virsh-virtual-machines-and-nfs-… Thank you so much for your help with my online virsh backup script. I've posted my script at the above address. I hope it helps someone protect their data. In my opinion, the script is an excellent implementation of --> https://libvirt.org/kbase/live_full_disk_backup.html https://www.worldbackupday.com/en

1 0

List checkpoints
by francisco.garcia＠baculasystems.com 09 Sep '25

09 Sep '25

Hello, I'm using checkpoints to back up Libvirt domains. I'm using the "virsh backup-begin" tool and specifying the dombackup and checkpoint XML files. Everything works correctly (I perform full and incremental backups) without any issues. When I list the checkpoints using the "virsh checkpoint-list DOMAIN --parent --topological" tool, it correctly shows me the entire chain of full and incremental backups. However, when I perform a differential backup, setting the parent of that checkpoint to the last full checkpoint, I have problems when listing them. It tells me that the parent of the differential checkpoint is the last incremental checkpoint, instead of the full checkpoint. And I don't understand why, because when I perform the backup-begin, I specify the full checkpoint in the "incremental" label, and the bitmap generated from the disk is all the data from the full checkpoint on. I put the xmls that I used: FULL BACKUP: dombackup.xml: ``` <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <domainbackup mode="pull"> <server name="localhost" port="10809"/> <disks> <disk name="vda" type="file"> <scratch file="/tmp/libvirt-full-30-vda-debian12.scratch"/> </disk> <disk name="vdb" type="file"> <scratch file="/tmp/libvirt-full-30-vdb-debian12.scratch"/> </disk> </disks> </domainbackup> ``` checkpoint.xml ``` <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <domaincheckpoint> <name>Full-30-Debian12</name> <disks> <disk name="vda" bitmap="Full-30-Debian12" checkpoint="bitmap"/> <disk name="vdb" bitmap="Full-30-Debian12" checkpoint="bitmap"/> <disk name="sda" checkpoint="no"/> </disks> </domaincheckpoint> ``` -------------------------------------------------------- INCREMENTAL BACKUP: dombackup.xml ``` <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <domainbackup mode="pull"> <server name="localhost" port="10809"/> <incremental>Full-30-Debian12</incremental> <disks> <disk name="vda" type="file"> <scratch file="/tmp/libvirt-incremental-35-vda-debian12.scratch"/> </disk> <disk name="vdb" type="file"> <scratch file="/tmp/libvirt-incremental-35-vdb-debian12.scratch"/> </disk> </disks> </domainbackup> ``` checkpoint.xml ``` <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <domaincheckpoint> <name>Incremental-31-Debian12</name> <parent> <name>Full-30-Debian12</name> </parent> <disks> <disk name="vda" bitmap="Incremental-31-Debian12" checkpoint="bitmap"/> <disk name="vdb" bitmap="Incremental-31-Debian12" checkpoint="bitmap"/> <disk name="sda" checkpoint="no"/> </disks> </domaincheckpoint> ``` ----------------------------------------------------------------- DIFFERENTIAL BACKUP: dombackup.xml ``` <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <domainbackup mode="pull"> <server name="localhost" port="10809"/> <incremental>Full-30-Debian12</incremental> <disks> <disk name="vda" type="file"> <scratch file="/tmp/libvirt-differential-36-vda-debian12.scratch"/> </disk> <disk name="vdb" type="file"> <scratch file="/tmp/libvirt-differential-36-vdb-debian12.scratch"/> </disk> </disks> </domainbackup> ``` checkpoint.xml ``` <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <domaincheckpoint> <name>Differential-32-Debian12</name> <parent> <name>Full-30-Debian12</name> </parent> <disks> <disk name="vda" bitmap="Differential-32-Debian12" checkpoint="bitmap"/> <disk name="vdb" bitmap="Differential-32-Debian12" checkpoint="bitmap"/> <disk name="sda" checkpoint="no"/> </disks> </domaincheckpoint> ``` ----------------------------------------------------------------------- After apply several "virsh backup-begin" with these files: ``` virsh checkpoint-list debian12 --topological --parent Name Creation Time Parent -------------------------------------------------------------------------------------------------------------------------------- Full-30-Debian12 2025-07-09 17:08:31 +0200 Incremental-31-Debian12 2025-07-09 17:34:56 +0200 Full-30-Debian12 Differential-32-Debian12 2025-07-09 17:37:51 +0200 Incremental-31-Debian12 ``` I do not know why the parent of "Differential-32-Debian12" is "Incremental-31-Debian12" instead of "Full-30-Debian12". Any ideas?

2 1

purge question about https://libvirt.org/kbase/live_full_disk_backup.html
by Philip Bondi 28 Aug '25

28 Aug '25

Hello libvirt users: On QNAP platform, 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

3 4

issue running SEV-SNP VM via virt-install
by sven.springer＠cloudandheat.com 26 Aug '25

26 Aug '25

Hi, I am a bit lost in which parameters I need to provide to virt-install to successfully launch an SEV-SNP capable VM. I already managed to start an SEV and SEV-ES VM via virt-install, and was also able to start an SEV-SNP VM via qemu-system-x86_64 directly. So what I am stuck with is this error message: ERROR internal error: QEMU unexpectedly closed the monitor (vm='debian-vm-1'): 2025-08-22T17:26:25.863482Z qemu-system-x86_64: pflash with kvm requires KVM readonly memory support when using this or variants of this command: virt-install \ --name "$VM_NAME" \ --noautoconsole \ --graphics none \ --import \ --memory 3072 \ --vcpus 2 \ --os-variant "$OS_VARIANT" \ --network network=default,model=virtio \ --memtune hard_limit=3407872 \ --qemu-commandline='-append "root=/dev/vda1 console=ttyS0"' \ --machine confidential-guest-support=sev0,memory-backend=ram1 \ --machine=q35 \ --boot uefi,loader=/usr/share/ovmf/OVMF.amdsev.fd,loader.stateless=yes,loader.secure=no,loader.type=pflash,kernel="$VMLINUZ",initrd="$INITRD" \ --qemu-commandline='-object memory-backend-memfd,id=ram1,size=8G,share=true,prealloc=false' \ --disk bus=virtio,path="$OVERLAY_IMG",format=qcow2 \ --cloud-init user-data="$USER_DATA" \ --virt-type kvm \ --launchSecurity sev-snp,policy=0x30000,cbitpos=51,reducedPhysBits=1,kernelHashes=on \ --cpu host-passthrough \ The issue is not with the images, since with the same ones it works when going directly via qemu-system-x86_64. I notice that libvirt is converting the --boot line to -blockdev, instead of -bios which seems to be the way to go according to https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/2106771 , so I tried something like --qemu-commandline='-bios /usr/share/ovmf/OVMF.amdsev.fd -kernel "$VMLINUZ"' \ but to no avail. Did anyone manage to run a SEV-SNP VM via virt-install, or even just a libvirt-xml ? I would appreciate any tips or working xml or cli call.

2 3

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