libvirt: error : Failed to switch root mount into slave mode: Permission denied

English Virtualization
1

Hello,

Approximately since November I get this error message when I attempt to run a virtual machine:

Error starting domain: internal error: Process exited prior to exec: libvirt: error : Failed to switch root mount into slave mode: Permission denied

Traceback (most recent call last):
File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 89, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 125, in tmpcb
callback(*args, **kwargs)
File “/usr/share/virt-manager/virtManager/libvirtobject.py”, line 82, in newfn
ret = fn(self, *args, **kwargs)
File “/usr/share/virt-manager/virtManager/domain.py”, line 1508, in startup
self._backend.create()
File “/usr/lib64/python3.6/site-packages/libvirt.py”, line 1069, in create
if ret == -1: raise libvirtError (‘virDomainCreate() failed’, dom=self)
libvirt.libvirtError: internal error: Process exited prior to exec: libvirt: error : Failed to switch root mount into slave mode: Permission denied

Beforehand as a temporary workaround I just stopped apparmor whenever I wanted to use my VM. But nowadays this workaround stopped working – approximately since the appearance of the last few kernels with the PTI fix.

Currently, if I set namespaces = ] in qemu.conf I can start and use the VM, but there is no way to shut it down properly, the shutdown process hangs at the very end, and even the host crashes at host shutdown with blinking caps lock. (This was the case beforehand too, if apparmor was not stopped.)

Currently I’m on Tumbleweed 20180110-1.2.

What could be the fix for this problem?

Thanks in advance.

2

What virtualization are you running, xen, kvm, lxc or something else?
(Might be relevant, maybe not…)

And, have your “zypper dup” reccently to get latest packages?

TSU

3

A quick Internet search of your problem returns only two hits in Oct and Dec 2017 (very recently as of this post) on a Debian and a RHEL system.
In both cases there was speculation that the problem is somehow AppArmor related but I don’t actually see the basis for their speculation. That said, I see your own AppArmor workarounds.
And, in both cases it looks like the discussions were unresolved (The Debian bug is marked MOREINFO NEEDED).

Luckily,
We in openSUSE can test that speculation easily by modifying the existing AppArmor profile from “enforced” to “complain” mode so that if there really is an AppArmor violation, it won’t have to block functionality, and at least initially you have a YaST tool instead of having to dig through and modify text files.

Using YaST, section 23.4.2 (or disable AppArmor completely in the previous section)
https://doc.opensuse.org/documentation/leap/security/html/book.security/cha.apparmor.yast.html#sec.apparmor.yast.manage

If you want to take it a step further and configure AppArmor more granularly,
I’d recommend searching for, and reading or following the instructions for the keyword “complain” in the next AppArmor documentation
https://doc.opensuse.org/documentation/leap/security/html/book.security/cha.apparmor.commandline.html

You should be able to confirm or disprove quickly whether your problem is related to AppArmoer before deciding next what to do.

HTH,
TSU

4

TSU,

  1. KVM

  2. The way I keep up to date my system is:
    zypper dist-upgrade --no-allow-vendor-change --auto-agree-with-licenses

  3. After disabling AppArmor in YaST and rebooting the host the VM can start and shutdown properly.

Beforehand the way it worked for me was:
systemctl stop apparmor
service libvirtd restart

  1. Finally I enabled AppArmor in YaST and set the complain mode for libvirtd in a way described here:
    https://askubuntu.com/questions/490328/virsh-snapshot-create-as-gives-unable-to-execute-qemu-command-transaction

Now I can use again my VM.

Is this complain mode thing a proper fix or it is some kind of provisional messy workaround?

TSU, thanks for pointing me in the proper direction.

5

Neither. Complain mode completely disables apparmor protection and is only used to create profile for your application. You can examine apparmor logs to add missing information to profile.

6

As this went wrong without any contribution on my part, will this eventually fixed in the same way?

7

Best is to note the detailed output in “complain mode” and include in a bug report.

As I described at first,
This problem apparently has been noticed before but no one provided enough information to get this fixed.
With your additional contribution, someone can take a closer look at exactly what might need to be fixed in the Apparmoer profile.

As described,
"Complain mode’ decreases the security of Apparmor by not enforcing rules, and is meant to be a temporary tool to identify what needs to be fixed.

TSU

8

You can try to find the file : /etc/apparmor.d/usr.sbin.libvirtd, if it was modify, you can replace it with the old one.
usr.lib.libvirt.virt-aa-helper is also.

I hope it can help you.