Ubuntu
libvirt package

libvirt error Invalid value '+cpu' for 'cgroup.subtree_control'

Bug #1845562 reported by Simon
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
libvirt (Debian)
Fix Released
Unknown
libvirt (Ubuntu)
Incomplete
Undecided
Unassigned

Bug Description

virt-manager -> start VM

Error starting domain: Invalid value '+cpu' for 'cgroup.subtree_control': Invalid argument

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 66, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1400, in startup
    self._backend.create()
  File "/usr/lib/python3/dist-packages/libvirt.py", line 1080, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirt.libvirtError: Invalid value '+cpu' for 'cgroup.subtree_control': Invalid argument

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: libvirt-daemon 5.0.0-1ubuntu2.5
ProcVersionSignature: Ubuntu 5.0.0-29.31-generic 5.0.21
Uname: Linux 5.0.0-29-generic x86_64
ApportVersion: 2.20.10-0ubuntu27.1
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Fri Sep 27 01:12:11 2019
InstallationDate: Installed on 2018-01-05 (629 days ago)
InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release amd64 (20170801)
SourcePackage: libvirt
UpgradeStatus: Upgraded to disco on 2019-06-29 (89 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-gateway.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/clean-traffic-gateway.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']

Revision history for this message
Simon (sam-ua) wrote :
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi,
on my end I rechecked and can start a guest with virt-manager just fine.
So we would need to find what is different on your configuration.

Usual good data is:
1. the guest XML representation (virsh dumpxml ...)
2. a list of installed packages (apport would have provided that, but it seems you skipped)
3. dmesg (in case there are apparmor denials)

Related to the error I found was some cgroupv2 code that isn't ready in 19.04 yet and should not be used. Actually it shouldn't be in there. Other people have ran into similar [1] and only with libvirt >=5.5 [2] I'd expect that to work which would mean Ubuntu 20.04.

Have you enabled/configured/tested cgroupv2 to maybe trigger this?

[1]: https://unix.stackexchange.com/questions/525498/libvirt-will-not-start-vms-with-error-invalid-value-cpu-for-cgroup-subtree
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1727149

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

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

Since it seems likely to me that this is a local configuration problem, rather than 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.

Changed in libvirt (Ubuntu):
status: New → Incomplete
Revision history for this message
Simon (sam-ua) wrote :

Hi

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931243

>Found in versions libvirt/5.0.0-4, libvirt/5.2.0-2
>Fixed in version libvirt/5.6.0-1

Revision history for this message
Simon (sam-ua) wrote :

files

Revision history for this message
Simon (sam-ua) wrote :
Revision history for this message
Simon (sam-ua) wrote :
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Yep that Debian bug confirms my assumption cgroupv2 only works well with the newer libvirt >5.5.

Could you outline how you got to a case that is affected by this so that we can try backporting fixes (not the full cgroupv2 feature, just if there is something that easily makes this skipping the bad part).

Revision history for this message
Simon (sam-ua) wrote :

I constantly use virtual machines. And this bug appeared after a regular update, about 3 weeks ago.

I think this happened after the update libvirt on 5.0.0-1ubuntu2.4 or 5.0.0-1ubuntu2.5

On my PC
~ $ sudo apt-cache policy libvirt-daemon
libvirt-daemon:
  Installed: 5.0.0-1ubuntu2.5
  Candidate: 5.0.0-1ubuntu2.5
  Version table:
 *** 5.0.0-1ubuntu2.5 500
        500 http://archive.ubuntu.com/ubuntu disco-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     5.0.0-1ubuntu2.4 500
        500 http://archive.ubuntu.com/ubuntu disco-security/main amd64 Packages
     5.0.0-1ubuntu2 500
        500 http://archive.ubuntu.com/ubuntu disco/main amd64 Packages

Bug Watch Updater (bug-watch-updater)
Changed in libvirt (Debian):
status: Unknown → Fix Released
Revision history for this message
Simon (sam-ua) wrote :

You can not fix this error in the current release?

Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :

Hello Simon,

The fix for the current release can be made, but, in order for that to happen, we need an exact way how to make the error to happen, and what was your use case. Reading Debian bug and this bug, it appears that you've enabled cgroupv2, correct ?

You likely enabled:

systemd.unified_cgroup_hierarchy
           When specified without an argument or with a true argument, enables the usage of
           unified cgroup hierarchy[8] (a.k.a. cgroups-v2). When specified with a false argument,
           fall back to hybrid or full legacy cgroup hierarchy.

in cmd line, right ? And your error happened because a cpu controller cannot be added to cgroupsv2 if there is a realtime process.

Could you explain what is the realtime process, if you are aware of, and why you need cgroups v2 enabled ? With that, perhaps we can backport a specific fix for libvirt 5.0.0-1ubuntu2.5 (or later) and fix this behavior.

Have you also tried removing rtkit package as a workaround ? Did it work ?

Revision history for this message
Doug Smythies (dsmythies) wrote :

I had this error today.
It was on a 20.04 development test server, upon which I was trying to start a freshly installed 20.04 server guest.
The error occurred because I had this on my grub command line:

cgroup_no_v1=all

Once I removed it, the VM started fine.
Note that I do not use virt-manager, I was using "virsh start serv-dev".

Why did I originally have "cgroup_no_v1=all"?
Well, I forgot to get rid of it, after debugging problems with the schedutil governor for either the intel_cpufreq (intel_pstate in passive mode) or acpi-cpufreq CPU frequency scaling drivers for mainline kernel 5.4, where it gets busted due to "UCLAMP_TASK_GROUP=Y"in the Ubuntu kernel configuration.

I was using kernel 5.3.0-18-generic today.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.