- Users - libvirt List Archives

Direct passthrough of /dev/lp0
by billehhg1＠gmail.com 12 Jan '26

12 Jan '26

I want to give multiple domains access to my parallel printer. Can I share hardware parallel port with libvirt?

3 2

Qemu/libvirt with gpu acceleration on c9 ?
by lejeczek 08 Jan '26

08 Jan '26

Hi guys. Do you know if with centos9 it's possible to get graphics/video acceleration - but not as pass-through to host device "directly" ? I'm fiddling with things but without success, with different bits in guest: ... <devices> ... <graphics type='vnc'> <listen type='none'/> <gl enable='yes' rendernode='/dev/dri/by-path/pci-0000:04:00.0-render'/> </graphics> <audio id='1' type='none'/> <video> <model type='virtio' heads='1' primary='yes'>  <acceleration rendernode='/dev/dri/by-path/pci-0000:04:00.0-render'/>  </model>  <driver name='vhostuser'/> <alias name='video0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </video> Comments within XML - basically describe the issue, I hope. Is the issue steaming from Qemu/build - and if yes then, can building Qemu with some flags fix it? - or is this rather hardware side of things most likely the root cause? qemu-kvm-core-10.1.0 + libvirt-libs-11.9.0 many thanks, L.

1 0

Virtualization guest reports: kvm VS microsoft
by lejeczek 31 Dec '25

31 Dec '25

HI guys. How guest reports *Virtualization* with /hostnameclt /should not depend on the guest itself, right? Virtualization: microsoft vs Virtualization: kvm particularly if guests run off the same host with libvirtd v. 11.9.0 Is it somewhere in domain's xml - but if so I failed to spot what makes this difference - what is it? thanks, L.

1 1

Writeback vs default cache modes
by João Jandre 12 Dec '25

12 Dec '25

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

1 0

Recommendations for basic libvirt access control
by Nikolaus Rath 08 Dec '25

08 Dec '25

Hello, I noticed that (at least on my Fedora installation), adding a user to the libvirt group is equivalent to giving full root access (since the user can add arbitrary block devices to VMs, and then use the VM to modify the block device). Therefore, I'd like to give users more limited permissions - but I'm a bit lost about the best way to approach that. It seems that I could: - tighten (or relax) socket permissions in the systemd config - switch off socket activation and configure socket permissions in libvirtd.conf - Configure socket-dependent permissions in libvirt - Enable policykit ACL checks, and configure permissions there. Could someone give me a recommendation what (combination?) of these options would most suitable for a simple "users can interact with their predefined VMs" model? Ideally, users would be able to configure and interact with VMs that are assigned to them, without having access to operations that are trivially root-equivalent (like adding new storage devices from the host). If that's difficult, I'd also settle for a simpler model where users can't change VM permissions at all, and are limited to starting, stopping, and connecting to the console of their VM. What's the best way to accomplish that? Best, -Nikolaus

4 4

libvirt access control
by nikolaus＠rath.org 06 Dec '25

06 Dec '25

Hello, I'm puzzled by how libvirtd manages access control. As far as I can tell, on my Fedora system it runs qemu and virtiofsd instances as user qemu. Yet, the qemu process apparently has read/write access to storage devices in /dev that only root has rw access for. Similarly, virtiofsd is able to write into shared directories that the qemu user does not have access to (confirmed by switching to qemu user with sudo). What is libvirtd (or virt-manager) doing to make this work? Then, as far as I can tell, there's lots of sockets with different permissions created by systemd in /run/libvirt (e.g. libvirt-admin-sock, libvirt-sock, libvirt-sock-ro). But since they're all passed to libvirtd as open file descriptors, I don't understand how they can give different levels of access (since libvirtd has no way of knowing which socket was used). What am I missing? Best, -Nikolaus

5 8

libvirt access control
by Nikolaus Rath 04 Dec '25

04 Dec '25

Hello, I'm puzzled by how libvirtd manages access control. As far as I can tell, on my Fedora system it runs qemu and virtiofsd instances as user *qemu*. Yet, the qemu process apparently has read/write access to storage devices in /dev that only root has rw access for. Similarly, virtiofsd is able to write into shared directories that the qemu user does not have access to (confirmed by switching to qemu user with sudo). What is libvirtd (or virt-manager) doing to make this work? Then, as far as I can tell, there's lots of sockets with different permissions created by systemd in /run/libvirt (e.g. libvirt-admin-sock, libvirt-sock, libvirt-sock-ro). But since they're all passed to libvirtd as open file descriptors, I don't understand how they can give different levels of access (since libvirtd has no way of knowing which socket was used). What am I missing? Best, -Nikolaus

1 0

virDomainBlockCommit for offline domains
by melanie witt 13 Nov '25

13 Nov '25

Hi, I am trying to find info about whether block commit of an offline domain is possible? Historically I know it was not supported and I wanted to confirm whether that is still the case. I did not notice mention about the limitation in the libvirt domain API docs or in the virsh docs. I'm investigating in the context of OpenStack Nova -- we have had a feature request brought back up recently to be able to delete an "intermediary" image in a backing chain while the VM is shutdown. And from what I understand, we would need to be able to call virDomainBlockCommit for a domain that is not running [1] as part of it. So I'm just looking to learn about the current state of support. Thanks for any information, -melwitt [1] https://bugs.launchpad.net/nova/+bug/1919487

2 2

Linux bridge VLANs
by Ian Pilcher 12 Nov '25

12 Nov '25

Do recent versions of libvirt support configuring VLANs (truck and access ports) on Linux bridges? I've been using OVS bridges for a long time (because Linux bridges didn't even do VLANs when I started). Linux bridges should theoretically be a bit simpler, but I can't tell from the libvirt documentation if libvirt ever gained the ability to do VLANs with Linux bridges. -- ======================================================================== Google Where SkyNet meets Idiocracy ========================================================================

2 2

Re: Compact backing chain (sparsify + compress)
by Markus Armbruster 10 Nov '25

10 Nov '25

Adding cc:s. Christopher Pereira <kripper(a)imatronix.cl> writes: > Hi, > > I would like to revisit this old thread from 2016 with a special use case that I believe should be a standard `virsh` command: > https://lists.gnu.org/archive/html/qemu-devel/2016-12/msg03571.html > > **Summary:** > > Given this QEMU backing chain: > `base <- snap1 <- snap2 <- snap3 (active)` > > We want to merge `base <- snap1 <- snap2` into a new snapshot `collapsed-base` that is: > 1. Sparsified (`virt-sparsify`) > 2. Compressed > > The resulting backing chain would be: > `collapsed-base <- snap3 (active)` > > **Motivation:** > > - We perform daily backup snapshots and never modify existing files (too dangerous). We only rebase. > - We collapse older chains into a new `collapsed-base` snapshot to limit chain size and avoid performance degradation. > > We have been doing this successfully for over 10 years using: > > - `qemu-img convert` > - `virt-sparsify` > - `virsh save` > - `qemu-img rebase` > - `virsh resume` > > **Problems:** > > - There is a small downtime due to `virsh save`/`resume`. > - In recent QEMU versions, `virsh` adds a `backingStore` tag to the XML even when using the `--no-metadata` option. This causes inconsistencies after `qemu-img rebase`. > > We didn’t use QMP because it didn’t support sparsify + compression in the past. > > **Questions:** > > - Is there now a better way to achieve this? > - Could this feature be implemented or supported directly in `virsh`? > > In my opinion, this would be the ideal backup solution: we could travel in time, sync immutable snapshots to a remote backup server, and maintain performance.

2 1

Co-stop with non-VMware virtualization?
by Troels Arvin 04 Nov '25

04 Nov '25

Hello, How important is it to consider "co-stop" with non-VMWare virtualization such as KVM? I haven't been able to find anything about this for KVM, but there's some material about it for VMWare (albeit typically rather old material). Based on VMWare material, by "co-stop" I mean the following situation: A VM called "x" has been assigned quite a few vCPUs, e.g. 10, on a hypervisor with e.g. 20 physical cores. The hypervisor is hosting many other VMs, and the many VMs take turn running on the hardware. Now, if it's often the case that, e.g., only 7 physical threads are available when it's x's turn to run, the hypervisor needs to postpone running x till all 10 cores can be allocated at the same time. During this waiting time, x is stopped (co-stop). Is my understanding correct? Or will KVM allow x to run on (e.g.) 7 cores, even though the VM thinks it has 10 vCPUs available? It's my understanding that with KVM, the co-stopped situation is reflected in the VM's "steal time" metric in a tool like "top". Does hyperthreading in either the hypervisor and/or the guest impact the risk of co-stop? -- Regards, Troels Arvin

3 2

[FOSDEM] Call for participation: Virtualization and Cloud infrastructure Room at FOSDEM 2026
by Piotr Kliczewski 28 Oct '25

28 Oct '25

We are excited to announce that the call for proposals is now open for the Virtualization and Cloud infrastructure devroom at the upcoming FOSDEM 2026, to be hosted on 31st of January. This devroom is a collaborative effort, and is organized by dedicated folks from projects such as OpenStack, Xen Project, KubeVirt, QEMU, KVM, and Foreman. We invite everyone involved in these fields to submit your proposals by 5th December 2025. About the Devroom The Virtualization & IaaS devroom will feature session topics such as open source hypervisors or virtual machine managers such as Xen Project, KVM, bhyve and VirtualBox as well as Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, OpenStack, QEMU and OpenNebula. This devroom will host presentations that focus on topics of shared interest, such as KVM, libvirt, shared storage, virtualized networking, cloud security, clustering and high availability, interfacing with multiple hypervisors, hyperconverged deployments and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Important Dates Submission deadline: 5th December 2025 Acceptance notifications: 10th December 2025 Final schedule announcement: 15th of December 2025 Devroom: 31st of January Submit Your Proposal During submission [1] please make sure to select Virtualization and Cloud infrastructure from the Track list. Please provide a meaningful abstract and description of your proposed session. Submission Guidelines We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 30 minutes, with 20 minutes planned for presentations, and 10 minutes for Q&A. All presentations will be recorded and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, Piotr Kliczewski and Tal Nisan In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend FOSDEM and deliver your presentation. We will not consider proposals from prospective speakers who are unsure whether they will be able to secure funds for travel and lodging to attend FOSDEM. (Sadly, we are not able to offer travel funding for prospective speakers.) Code of Conduct Following the release of the updated code of conduct for FOSDEM[2], we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Questions? If you have any questions about this devroom, please send your questions to our devroom mailing list. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] https://fosdem.org/submit [2] https://fosdem.org/2026/practical/conduct/

1 0

Gueat with secure boot & PXE ?
by lejeczek 22 Oct '25

22 Oct '25

Hi guys. I'm trying to boot securely a guest - ultimately will be Windows, I hear only secure boot for win11 - via PXE but I fail to figure it out - my first foray into it. VM fails with: iPXE initialising devices... autoexec. ipxe... Not found (https:// ipxe .org/2d12618e iPXE 1.21.1+ (g5c49e) -- Open Source Network Boot Firmware —- https://ipxe.org Features: DNS HITP iSCSI TETP ULAN SRP AoE EFI Menu net@: 02:2d:7a:34:9f:90 using virtio-net on 0000:01:00.0 (Ethernet) [open] ULink:up, T:@ TKE:1 RX:@ RXE:0] ITKE: 1 x "Netuork unreachable (https://ipxe .org/28086090) "] Configuring (net 02:2d:7a:34:9F:90) ...... ok netO: 10.3.1.14/255.255.252.0 gu 10.3.1.254 netO: fe80::2d: Taff: fe34:9£90/64 Next server: 10.3.1.99 Filenane: ipxe-shinx64-ef i t£tp://10.3.1.99/ ipxe-shimx64-ef i... ok ipxe-shinx64.efi : 961448 bytes [EFI] Fetching Netboot Inage ipxe-efi Nalforned binary after Attribute Certificate Table datasize: 4194304 SunOfBytesHashed: 1044480 SecDir->Size: 1536 hashsize: 3148288 SecDir->VirtualAddress: 0x000FFO00 Failed to load image: Invalid Paraneter start_imageQ returned Invalid Paraneter, falling back to default loader Fetching Netboot Inage ipxe-efi Nalforned binary after Attribute Certificate Table datasize: 4194304 SunOfBytesHashed: 1044480 SecDir->Size: 1536 hashsize: 3148288 SecDir-VirtualAddress: 0x000FFO00 Failed to load inage: Invalid Paraneter start_imageQ returned Invalid Paraneter Guest domain is like so: ... <firmware> <feature enabled='no' name='enrolled-keys'/> <feature enabled='no' name='secure-boot'/> </firmware> <loader readonly='yes' type='pflash' format='raw'>/usr/share/edk2/ovmf/OVMF_CODE.fd</loader> <nvram template='/usr/share/edk2/ovmf/OVMF_VARS.fd' templateFormat='raw' format='raw'>/var/lib/libvirt/qemu/nvram/dzien-win-secbot_VARS.fd</nvram> ... Here boot is not secure secure - but when is secure, also fails - so I could capture pxe process which is more verbose here, as opposed to secure which pop-ups with blue screen with only a short message. I'm presuming I sign something - bootloaders |& efi vars store - wrong? I'm on centos 9 with biners up-to-today. Any/all thoughts are much appreciated. many thanks, L.

1 0

download certificate issue
by daan.hoogland＠gmail.com 20 Oct '25

20 Oct '25

we (apache/cloudstack) are seeing issues downloading libvirt java 0.5.3 lately. It seems to be due to certificates errors on downloads.libvirt.org . I am not sure what the appropriate way to report this is, so asking here first. regards, Daan Hoogland

2 1

Re: domain not getting IP address
by Pavel Mores 22 Sep '25

22 Sep '25

On Thu, Sep 18, 2025 at 11:29 AM Pavel Mores <pmores(a)redhat.com> wrote: > On Thu, Sep 18, 2025 at 10:25 AM Martin Kletzander <mkletzan(a)redhat.com> > wrote: > >> On Wed, Sep 17, 2025 at 04:02:12PM +0200, Pavel Mores wrote: >> >On Wed, Sep 17, 2025 at 3:05 PM Martin Kletzander <mkletzan(a)redhat.com> >> >wrote: >> > >> >> On Wed, Sep 17, 2025 at 02:14:51PM +0200, Pavel Mores via Users wrote: >> >> >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> >> >> > >> >> >> >> This is standard. >> >> >> >> >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> >> >> > >> >> >> >> This looks fine. >> >> >> >> >The domain is running but apparently without an IP address: >> >> > >> >> ># virsh domifaddr podvm-podsandbox-totok-8f10756a >> >> > Name MAC address Protocol Address >> >> >> >> >> >------------------------------------------------------------------------------- >> >> > >> >> >> >> This shows that libvirt does not know about any IP address. Does >> adding >> >> "--source agent", "--source arp" or "--source lease" change anything? >> >> >> > >> >'arp' and 'lease' don't but >> > >> ># virsh domifaddr --source agent podvm-podsandbox-totok-8f10756a >> >error: Failed to query for interfaces addresses >> >error: argument unsupported: QEMU guest agent is not configured >> > >> >This is surprising to me since this is a peer pods setup where the domain >> >in question is a podvm running an image which I was told does have >> >the qemu agent running. >> > >> >However the agent shouldn't be necessary for IP address acquisition I >> guess, >> >right? >> > >> >>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. >> >> > >> >> >> >> When this happens to me sometimes, it's most often a firewall issue and >> >> the VM does not get any IP address or cannot communicate outside its >> >> network. >> >> >> > >> >I've seen a firewall suggested as a possible culprit, yes, however I >> don't >> >quite >> >know what it should look like. iptables appear unconfigured: >> > >> ># iptables -L -v -n >> >Chain INPUT (policy ACCEPT 0 packets, 0 bytes) >> > pkts bytes target prot opt in out source >> >destination >> > >> >Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) >> > pkts bytes target prot opt in out source >> >destination >> > >> >Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) >> > pkts bytes target prot opt in out source >> >destination >> > >> >`nft list ruleset` lists only rules that look managed by libvirt >> >itself(*). At any >> >rate the host machine has no specific hand-configured firewall that I >> know >> >of. >> > >> > >> >> What it can be here is that there are some access issues to the dnsmasq >> >> lease file. >> >> >> >> What's in your /var/lib/libvirt/dnsmasq/virbr0.status file on the host? >> >> >> > >> >It's empty. >> > >> >Thanks Martin! >> >pvl >> > >> >(*) # nft list ruleset >> >table ip libvirt_network { >> >chain forward { >> >type filter hook forward priority filter; policy accept; >> >counter packets 85854914 bytes 398726525237 jump guest_cross >> >counter packets 85854914 bytes 398726525237 jump guest_input >> >counter packets 34777368 bytes 3386943972 jump guest_output >> >} >> > >> >chain guest_output { >> >ip saddr 192.168.122.0/24 iif "virbr0" counter packets 0 bytes 0 accept >> >> This suggests there were no incoming packets from an IP address in the >> range on the bridge. >> >> >iif "virbr0" counter packets 0 bytes 0 reject >> >> And no packets from outside of that range that would fall through to >> this above rule. >> >> [...] >> >> >} >> > >> >chain guest_input { >> >> [...] >> >> >oif "virbr0" ip daddr 192.168.122.0/24 ct state established,related >> counter >> >packets 0 bytes 0 accept >> >> No packets sent to the address range on the bridge, but >> >> >oif "virbr0" counter packets 0 bytes 0 reject >> >> basically no packets sent at all. >> >> >} >> > >> >chain guest_cross { >> >iif "openshift-412" oif "openshift-412" counter packets 0 bytes 0 accept >> >iif "openshift-419" oif "openshift-419" counter packets 0 bytes 0 accept >> >iif "openshift-416" oif "openshift-416" counter packets 0 bytes 0 accept >> >iif "openshift-415" oif "openshift-415" counter packets 0 bytes 0 accept >> >iif "openshift-413" oif "openshift-413" counter packets 0 bytes 0 accept >> >iif "virbr0" oif "virbr0" counter packets 0 bytes 0 accept >> >> No intra-network communication >> >> [...] >> >> >chain guest_nat { >> >type nat hook postrouting priority srcnat; policy accept; >> >> [...] >> >> >ip saddr 192.168.122.0/24 ip daddr 224.0.0.0/24 counter packets 50 bytes >> >3676 return >> >> There were some IPv4 multicast packets, but these could've originated >> from the host. >> >> >ip saddr 192.168.122.0/24 ip daddr 255.255.255.255 counter packets 0 >> bytes >> >0 return >> >> And no broadcast packets from the address space. >> >> >meta l4proto tcp ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 >> >counter packets 0 bytes 0 masquerade to :1024-65535 >> >meta l4proto udp ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 >> >counter packets 0 bytes 0 masquerade to :1024-65535 >> >ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 >> >bytes 0 masquerade >> >> No NAT, anything. >> >> [...] >> >ip saddr 192.168.14.0/24 ip daddr 224.0.0.0/24 counter packets 50 bytes >> >3675 return >> >> These counters on another range are the same, so I would say all the >> multicast packets on the range we are interested in are just the same, >> hence having nothing to do with the guest. >> >> >} >> >} >> >table ip6 libvirt_network { >> >chain forward { >> >type filter hook forward priority filter; policy accept; >> >counter packets 0 bytes 0 jump guest_cross >> >counter packets 0 bytes 0 jump guest_input >> >counter packets 0 bytes 0 jump guest_output >> >> And totally nothing with IPv6. >> > > As a bit of context, this is a virtlab machine whose primary purpose is to > run > kcli-based openshift clusters whose nodes are libvirt domains. Those are > the > "openshift-41[1-9]" networks and bridges. They are unrelated to the setup > I'm > looking into and most of them are actually obsolete (it's been years now > since > a 4.11 cluster last ran on the host :-)). > > My "guess" would be that the guest did not even get an IP address, maybe >> did not eve try DHCP. Are you sure the guest booted? >> > > I think it is, based on > > # virsh list > Id Name State > ------------------------------------------------- > [...] > 20 podvm-podsandbox-totok-8f10756a running > > But now that you mention it, I'm not positively sure that it tried DHCP. > The zero > traffic on the virbr0 bridge you mention above is overall explainable by > the domain > not having an address *but* if it did try DHCP those packets would show up > in the > virbr0 stats I guess? > > I did check out previously the DHCP leases on the 'default' network: > > # virsh net-dhcp-leases default > Expiry Time MAC address Protocol IP address Hostname Client ID > or DUID > > ----------------------------------------------------------------------------------- > > and there are none but that doesn't rule out any other failure in DHCP. > > The domain runs a peer pods podvm image which I don't have any control > over and > frankly am not familiar with. I assume that it does do DHCP to configure > its interfaces > but as the guest agent example shows my information about the image might > not be > always accurate. > I verified that the VM does do DHCP (there actually doesn't seem to be any other means for a podvm to get its network configured in peer pods). pvl > Is there a way to check if the domain attempts DHCP purely from the > libvirt side, just > using libvirt means? > > Thanks! > pvl >

2 2

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