- Users - libvirt List Archives

domain not getting IP address
by Pavel Mores 18 Sep '25

18 Sep '25

Hi, I'm examining a domain that's connected to the 'default' network # virsh net-dumpxml default <network connections='1'> <name>default</name> <uuid>c757baa7-2b31-4794-9dfb-0df384575602</uuid> <forward mode='nat'> <nat> <port start='1024' end='65535'/> </nat> </forward> <bridge name='virbr0' stp='on' delay='0'/> <mac address='52:54:00:37:b7:92'/> <ip address='192.168.122.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.122.2' end='192.168.122.254'/> </dhcp> </ip> </network> using a device as follows: <interface type='network'> <mac address='52:54:00:ed:06:2e'/> <source network='default' portid='83db8ca9-baed-47f3-ba0d-1a967ee86aa5' bridge='virbr0'/> <target dev='vnet19'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> The domain is running but apparently without an IP address: # virsh domifaddr podvm-podsandbox-totok-8f10756a Name MAC address Protocol Address ------------------------------------------------------------------------------- The requisite host-side interfaces look good (to me anyway :-)): 10: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP group default qlen 1000 link/ether 52:54:00:37:b7:92 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever [...] 35: vnet19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UNKNOWN group default qlen 1000 link/ether fe:54:00:ed:06:2e brd ff:ff:ff:ff:ff:ff inet6 fe80::fc54:ff:feed:62e/64 scope link proto kernel_ll valid_lft forever preferred_lft forever I can share more information about the setup if necessary but I'll stop here for now since I feel this must be just a simple stupid oversight on my part. Please let me know if you'd like to have additional info. Thanks in advance, pvl

2 3

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

11 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 27 Aug '25

27 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