- 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

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