libvirt group confusion? 991 vs 135

[oshunluvr]

This is an upgraded KDEneon install from 18.04, currently based on 24.04.

I was deleting a VM using libvirt KVM GUI and for some reason that I could not glean, it would let me delete the VM but not the storage image, claiming I didn't have permission. The VM itself was Kubuntu 24.10 I created a while ago. Looking into the images folder and all the files there are root:root owned and permissions the same. So I deleted the image file manually. Testing with other VMs, no problem deleting any of the other image files from KVM.

Anyway, this lead me to dig a bit deeper to see what I had messed up. I have mucked about with QEMU/KVM a bit in the past but have no recollection of what I changed except to move all the folders out of /var to a separate EXT4 partition so I could avoid using NoCOW and to make the installation file system more compact. I range from 10 to 20 or so VMs off and on, so it uses a lot of drive space.

What I discovered - and the point of this post - is quite a few of the folders and files in the virtual machine storage are set with group 991 but this group doesn't exist on my system. Additionally, there is a libvirt group in my groups but it's group number is 135. Preliminary web searches show that RedHat uses group 991 for libvert.

It seems probable that libvert as group 135 was already on my system before I mucked about with it and somehow along the way, KVM is configured to use 991.

I ran a "find" command to see if any files or folders on my system are group 135 and could find none.

I'm wondering if any other QEMU/KVM users on here are seeing the same as I am. Odd thing is I've had no problem using KVM until this deletion thing today.

I'm thinking I'm going to change the libvirt group number to 991 and adjust my user account if needed.

[claydoh]

I do not believe I have seen this myself. Been using virt-manager/kvm/qemu for a while now.


For me, 991 is systemd-resolve on multiple *buntu systems, and is brltty on KDE Linux,

my libvirt related groups on KDE neon are:
libvirt:125
libvirt-qemu:64055
libvirt-dnsmasq:126


But on Kubuntu 26.04:
libvirt:981
libvirt-qemu:64055
libvirt-dnsmasq:126


And testing some deletions, I forgot to note the file and dir deets.

Here is after adding a new (and running) vm

$ ls -la /mnt/virts/
total 4164
drwxr-xr-x 1 claydoh claydoh 54 Oct 16 06:42 .
drwxr-xr-x 1 claydoh claydoh 66 Jun 29 09:24 ..
-rw------- 1 libvirt-qemu kvm 26847870976 Oct 16 06:42 Kubuntu2604.qcow2
drwxr-x--- 1 root root 36 Oct 16 06:00 .snapshots

And interestingly, if the VM is NOT running it has different ownership.

-rw------- 1 root root 26847870976 Oct 16 07:10 Kubuntu2604.qcow2

[oshunluvr]

I went ahead and made the group number change from 135 to 991 and no adverse effects thus far.

I did a quick check for systemd groups:

systemd-journal:x:101:
systemd-network:x:102:
systemd-resolve:x:103:
systemd-timesync:x:106:
systemd-coredump:x:142:​

Also, the ownership change when the VM is active is normal. I guess it's a security feature. I have seen tutorials on how to install KVM in a way to allow normal user access without superuser rights, but I don't really need that 'cause it's just me.

I launched a Kubuntu 26/04 VM and group 991 is "kvm" but on my machine kvm is group 109 and none of the other related group numbers match up either. Note that this is a VM running in KVM and has KVM itself installed.

libvirt related groups on the Kubuntu 26.04 VM

kvm:x:991:libvirt-qemu
libvirt:x:975:stuart
libvirt-dnsmasq:x:117
libvirt-qemu:64055

So all the groups are different except libvirt-qemu. Also I noticed the systemd groups do not match either.

So at this point, I think the internet was right - it simply was a group set earlier in the life of my system and thus an update or re-install of QEMU or KVM didn't have the ability to change the group by itself. I did once quite awhile ago try a different front end to KVM - AQEMU - but I didn't like it and removed it so maybe that was the source of the group number change??

The odd thing to me is it apparently had zero impact on my ability to use KVM. Seemingly just a left over from a much earlier time, this being an install that has been release-upgraded 3 times.