[libvirt] Problem with version 5.5.x
Hello Folks! The distro I use (Guix System) has updated it's libvirt version from 5.4.x to 5.5.x, few days ago. After the update, there is this following error: "libvirt.libvirtError: Unable to read from '/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or directory". It appears that libvirt is searching "/sys/fs/cgroup/unified/machine/cgroup.controllers" path, instead of "/sys/fs/cgroup/unified/cgroup.controllers" path; as the directory "machine" does not actually exist. The libvirt was working just fine before the update. So it seems like a critical bug with version 5.5.x that needs to be patched ASAP. Thank you! Regards, RG.
IN CONTINUATION TO MY PREVIOUS EMAIL IN THIS THREAD: The virt-manager gives out the following error: Unable to complete install: 'Unable to read from '/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or directory' Traceback (most recent call last): File "/gnu/store/r2l62bg0ayh22pkgs0jm9ig8q8n7daql-virt-manager- 2.1.0/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/gnu/store/r2l62bg0ayh22pkgs0jm9ig8q8n7daql-virt-manager- 2.1.0/share/virt-manager/virtManager/create.py", line 2122, in _do_async_install guest.installer_instance.start_install(guest, meter=meter) File "/gnu/store/r2l62bg0ayh22pkgs0jm9ig8q8n7daql-virt-manager- 2.1.0/share/virt-manager/virtinst/installer.py", line 415, in start_install doboot, transient) File "/gnu/store/r2l62bg0ayh22pkgs0jm9ig8q8n7daql-virt-manager- 2.1.0/share/virt-manager/virtinst/installer.py", line 358, in _create_guest domain = self.conn.createXML(install_xml or final_xml, 0) File "/gnu/store/kcdnna2613in9xfm9gxjqvkisdns911v-python-libvirt- 5.5.0/lib/python3.7/site-packages/libvirt.py", line 3840, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirt.libvirtError: Unable to read from '/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or directory
[Cc'ing Pavel in case he already has a hunch as to whether it's fixed or not] Did one of the latest fixes [1] help in any way? If yes, then it's going to be in the next release. If not, then in order to figure out where the issue is, we at least need some debug logs [2]. [1] https://www.redhat.com/archives/libvir-list/2019-July/msg01266.html [2] https://wiki.libvirt.org/page/DebugLogs On Sun, Jul 21, 2019 at 06:51:05PM -0400, Raghav Gururajan wrote:
IN CONTINUATION TO MY PREVIOUS EMAIL IN THIS THREAD:
The virt-manager gives out the following error:
Unable to complete install: 'Unable to read from '/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or directory'
Traceback (most recent call last): File "/gnu/store/r2l62bg0ayh22pkgs0jm9ig8q8n7daql-virt-manager- 2.1.0/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/gnu/store/r2l62bg0ayh22pkgs0jm9ig8q8n7daql-virt-manager- 2.1.0/share/virt-manager/virtManager/create.py", line 2122, in _do_async_install guest.installer_instance.start_install(guest, meter=meter) File "/gnu/store/r2l62bg0ayh22pkgs0jm9ig8q8n7daql-virt-manager- 2.1.0/share/virt-manager/virtinst/installer.py", line 415, in start_install doboot, transient) File "/gnu/store/r2l62bg0ayh22pkgs0jm9ig8q8n7daql-virt-manager- 2.1.0/share/virt-manager/virtinst/installer.py", line 358, in _create_guest domain = self.conn.createXML(install_xml or final_xml, 0) File "/gnu/store/kcdnna2613in9xfm9gxjqvkisdns911v-python-libvirt- 5.5.0/lib/python3.7/site-packages/libvirt.py", line 3840, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirt.libvirtError: Unable to read from '/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or directory
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Jul 24, 2019 at 12:27:58PM +0200, Martin Kletzander wrote:
[Cc'ing Pavel in case he already has a hunch as to whether it's fixed or not]
Did one of the latest fixes [1] help in any way?
Unfortunately no, this will require one more fix. I managed to reproduce it on my gentoo testing machine.
If yes, then it's going to be in the next release. If not, then in order to figure out where the issue is, we at least need some debug logs [2].
No need for the debug logs, I've tracked down the issue and working on a fix, thanks for reporting it. Pavel
participants (3)
-
Martin Kletzander -
Pavel Hrdina -
Raghav Gururajan