libvirtd group not automatically created when libvirt

[Nur Hussein]

When I upgraded from Artful Aardvark to Bionic Beaver, I couldn't run KVM virtual machines that were running fine previously.

I fixed it by adding the libvirtd group manually and adding myself to it.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: libvirt-daemon-system 4.0.0-1ubuntu8
ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
Uname: Linux 4.15.0-20-generic x86_64
ApportVersion: 2.20.9-0ubuntu7
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Sat May 5 03:16:32 2018
InstallationDate: Installed on 2017-07-13 (295 days ago)
InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
SourcePackage: libvirt
UpgradeStatus: Upgraded to bionic on 2018-04-28 (6 days ago)
modified.conffile..etc.libvirt.nwfilter.allow-arp.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/allow-arp.xml']
modified.conffile..etc.libvirt.nwfilter.allow-dhcp-server.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/allow-dhcp-server.xml']
modified.conffile..etc.libvirt.nwfilter.allow-dhcp.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/allow-dhcp.xml']
modified.conffile..etc.libvirt.nwfilter.allow-incoming-ipv4.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/allow-incoming-ipv4.xml']
modified.conffile..etc.libvirt.nwfilter.allow-ipv4.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/allow-ipv4.xml']
modified.conffile..etc.libvirt.nwfilter.clean-traffic.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/clean-traffic.xml']
modified.conffile..etc.libvirt.nwfilter.no-arp-ip-spoofing.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-arp-ip-spoofing.xml']
modified.conffile..etc.libvirt.nwfilter.no-arp-mac-spoofing.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-arp-mac-spoofing.xml']
modified.conffile..etc.libvirt.nwfilter.no-arp-spoofing.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-arp-spoofing.xml']
modified.conffile..etc.libvirt.nwfilter.no-ip-multicast.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-ip-multicast.xml']
modified.conffile..etc.libvirt.nwfilter.no-ip-spoofing.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-ip-spoofing.xml']
modified.conffile..etc.libvirt.nwfilter.no-mac-broadcast.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-mac-broadcast.xml']
modified.conffile..etc.libvirt.nwfilter.no-mac-spoofing.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-mac-spoofing.xml']
modified.conffile..etc.libvirt.nwfilter.no-other-l2-traffic.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-other-l2-traffic.xml']
modified.conffile..etc.libvirt.nwfilter.no-other-rarp-traffic.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-other-rarp-traffic.xml']
modified.conffile..etc.libvirt.nwfilter.qemu-announce-self-rarp.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/qemu-announce-self-rarp.xml']
modified.conffile..etc.libvirt.nwfilter.qemu-announce-self.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/qemu-announce-self.xml']
modified.conffile..etc.libvirt.qemu.conf: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/qemu.conf']
modified.conffile..etc.libvirt.qemu.networks.default.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/qemu/networks/default.xml']

[Christian Ehrhardt  (paelzer)]

Hi Nur,
that is odd the handling is as following.

In the past there was a group libvirtd - new packaging in Debian and Ubuntu renamed that to libvirt but the install handles that.

In case of a new install you would have those groups for libvirt:
libvirt:x:132:paelzer
libvirt-qemu:x:64055:libvirt-qemu

But if you are on an upgrade form an older version to properly work with old filed created under the old user you'd get:
libvirtd:x:132:paelzer
libvirt:x:132:paelzer
libvirt-qemu:x:64055:libvirt-qemu

The GID is the same, and therefore both names are essentially the same group.

The snippet for that is in libvirt-daemon-system.postinst and I don't see yet how that would "remove" the libvirtd group.
     if ! getent group libvirt >/dev/null; then
        if getent group libvirtd >/dev/null; then
            gid=`getent group libvirtd | getent group libvirtd | cut -d: -f3`
            groupadd --system --non-unique --gid "$gid" libvirt
        else
            addgroup --quiet --system libvirt
        fi
     fi

This is this way since yakkety (16.10) and so far was not an issue.

So the behavior should be:
- new installs since >=Yakkety, you have just group "libvirt"
- upgrade <=Xenial have libvirtd, and you get libvirtd AND libvirt on the same GID

Nur, could you please outline:
- what exact the error was that made your system need the libvirtd group?
- a scenario how you'd ever have had a libvirtd group given that you Started with 17.04 after the changes I referred to?

If this is a 3rd party automation/script you'd have to adapt to the new group name for new installs. As mentioned upgrades will be handled - but all of this is true since >=16.10.

Waiting for your reply ...

[Christian Ehrhardt  (paelzer)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Since there isn't enough information in your report to differentiate between a local configuration problem and a bug in Ubuntu, I'm marking this bug as Incomplete.

If indeed this is a local configuration problem, you can find pointers to get help for this sort of problem here: http://www.ubuntu.com/support/community

Or if you believe that this is really a bug, then you may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem, explain why you believe this is a bug in Ubuntu rather than a problem specific to your system, and then change the bug status back to New.

[Launchpad Janitor (janitor)]

[Expired for libvirt (Ubuntu) because there has been no activity for 60 days.]

[Ken Hillier (wolftales)]

I just started an install of KVM to support minikube on Ubuntu 18.04.3.

I can second the behavior noted here in this bug report. And as of today it is still an issue.

Here is console log of the issue as I am seeing it:

ken@docker:~$ grep -E --color 'vmx|svm' /proc/cpuinfo
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc cpuid pni pclmulqdq vmx ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm pti ssbd ibrs ibpb stibp tpr_shadow vnmi ept vpid tsc_adjust arat md_clear flush_l1d arch_capabilities
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc cpuid pni pclmulqdq vmx ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm pti ssbd ibrs ibpb stibp tpr_shadow vnmi ept vpid tsc_adjust arat md_clear flush_l1d arch_capabilities
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc cpuid pni pclmulqdq vmx ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm pti ssbd ibrs ibpb stibp tpr_shadow vnmi ept vpid tsc_adjust arat md_clear flush_l1d arch_capabilities
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc cpuid pni pclmulqdq vmx ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm pti ssbd ibrs ibpb stibp tpr_shadow vnmi ept vpid tsc_adjust arat md_clear flush_l1d arch_capabilities
ken@docker:~$ egrep -c '(vmx|svm)' /proc/cpuinfo
4
ken@docker:~$ sudo cat /sys/hypervisor/properties/capabilities
cat: /sys/hypervisor/properties/capabilities: No such file or directory
ken@docker:~$ sudo kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used
ken@docker:~$ egrep -c ' lm ' /proc/cpuinfo
4
ken@docker:~$ uname -m
x86_64
ken@docker:~$ sudo apt install -y qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  augeas-lenses ebtables ibverbs-providers ipxe-qemu ipxe-qemu-256k-compat-efi-roms
  libaio1 libaugeas0 libcacard0 libfdt1 libibverbs1 libiscsi7 libnetcf1
  libnl-route-3-200 librados2 librbd1 librdmacm1 libsdl1.2debian libspice-server1
  libusbredirparser1 libvirt-daemon libvirt-daemon-driver-storage-rbd libvirt0
  libxen-4.9 libxenstore3.0 libxml2-utils qemu-block-extra qemu-system-common
  qemu-system-x86 qemu-utils seabios sharutils
Suggested packages:
  augeas-doc augeas-tools libvirt-daemon-driver-storage-gluster
  libvirt-daemon-driver-storage-sheepdog libvirt-daemon-driver-storage-zfs numad
  radvd auditd systemtap nfs-common zfsutils pm-utils s...

[Ken Hillier (wolftales)]

Here is a bit more background as there may be some confusion for me based on the documentation I'm following:

https://help.ubuntu.com/community/KVM/Installation

I'm running 18.04.3 as I said. And it appears that there is some differences based on 18.10 and 9.10

I;m proceeding forward with libvirt and using the 18.10+ instructions.