KVM guest will not start with latest version of kernel

pblewis · September 29, 2017, 7:21pm

I have the problem of virtual machines not starting but I know that this only happens when I am using the latest kernel version. With kernel 4.4.87 all works fine.

With kernel 4.13.4 I get the error message:

Error starting domain: internal error: child reported: Kernel does not provide mount namespace: Permission denied

The machine setup is:

zypper se -si kernel libvirt kvm qemu
Loading repository data...
Reading installed packages...

S  | Name                               | Type    | Version             | Arch   | Repository               
---+------------------------------------+---------+---------------------+--------+--------------------------
i+ | kernel-default                     | package | 4.13.4-1.1.g4dec972 | x86_64 | Kernels                  
i+ | kernel-default                     | package | 4.4.87-25.1         | x86_64 | openSUSE-Leap-42.3-Update
i  | kernel-firmware                    | package | 20170530-9.1        | noarch | openSUSE-Leap-42.3-Oss   
i  | kvm_server                         | pattern | 20170518-6.1        | x86_64 | openSUSE-Leap-42.3-Oss   
i+ | libvirt-client                     | package | 3.3.0-4.11          | x86_64 | openSUSE-Leap-42.3-Oss   
i  | libvirt-daemon                     | package | 3.3.0-4.11          | x86_64 | openSUSE-Leap-42.3-Oss   
i  | libvirt-daemon-driver-interface    | package | 3.3.0-4.11          | x86_64 | openSUSE-Leap-42.3-Oss   
i  | libvirt-daemon-driver-network      | package | 3.3.0-4.11          | x86_64 | openSUSE-Leap-42.3-Oss   
i  | libvirt-daemon-driver-nodedev      | package | 3.3.0-4.11          | x86_64 | openSUSE-Leap-42.3-Oss   
i  | libvirt-daemon-driver-nwfilter     | package | 3.3.0-4.11          | x86_64 | openSUSE-Leap-42.3-Oss   
i  | libvirt-daemon-driver-qemu         | package | 3.3.0-4.11          | x86_64 | openSUSE-Leap-42.3-Oss   
i  | libvirt-daemon-driver-secret       | package | 3.3.0-4.11          | x86_64 | openSUSE-Leap-42.3-Oss   
i  | libvirt-daemon-driver-storage-core | package | 3.3.0-4.11          | x86_64 | openSUSE-Leap-42.3-Oss   
i  | libvirt-daemon-qemu                | package | 3.3.0-4.11          | x86_64 | openSUSE-Leap-42.3-Oss   
i  | libvirt-glib-1_0-0                 | package | 0.2.3-3.1           | x86_64 | openSUSE-Leap-42.3-Oss   
i  | libvirt-libs                       | package | 3.3.0-4.11          | x86_64 | openSUSE-Leap-42.3-Oss   
i  | libvirt-python                     | package | 3.3.0-1.2           | x86_64 | openSUSE-Leap-42.3-Oss   
i  | nfs-kernel-server                  | package | 1.3.0-28.1          | x86_64 | openSUSE-Leap-42.3-Oss   
i+ | patterns-openSUSE-kvm_server       | package | 20170518-6.1        | x86_64 | openSUSE-Leap-42.3-Oss   
i  | qemu                               | package | 2.9.0-32.4          | x86_64 | openSUSE-Leap-42.3-Update
i  | qemu-block-curl                    | package | 2.9.0-32.4          | x86_64 | openSUSE-Leap-42.3-Update
i  | qemu-block-rbd                     | package | 2.9.0-32.4          | x86_64 | openSUSE-Leap-42.3-Update
i  | qemu-ipxe                          | package | 1.0.0-32.4          | noarch | openSUSE-Leap-42.3-Update
i  | qemu-ksm                           | package | 2.9.0-32.4          | x86_64 | openSUSE-Leap-42.3-Update
i  | qemu-kvm                           | package | 2.9.0-32.4          | x86_64 | openSUSE-Leap-42.3-Update
i  | qemu-seabios                       | package | 1.10.2-32.4         | noarch | openSUSE-Leap-42.3-Update
i  | qemu-sgabios                       | package | 8-32.4              | noarch | openSUSE-Leap-42.3-Update
i  | qemu-tools                         | package | 2.9.0-32.4          | x86_64 | openSUSE-Leap-42.3-Update
i  | qemu-vgabios                       | package | 1.10.2-32.4         | noarch | openSUSE-Leap-42.3-Update
i  | qemu-x86                           | package | 2.9.0-32.4          | x86_64 | openSUSE-Leap-42.3-Update
i  | typelib-1_0-LibvirtGLib-1_0        | package | 0.2.3-3.1           | x86_64 | openSUSE-Leap-42.3-Oss

uname -a
Linux bardsey 4.13.4-1.g4dec972-default #1 SMP PREEMPT Wed Sep 27 14:20:45 UTC 2017 (4dec972) x86_64 x86_64 x86_64 GNU/Linux

zypper lr -d
Repository priorities are without effect. All enabled repositories share the same priority.

#  | Alias                     | Name                                    | Enabled | GPG Check | Refresh | Priority | Type   | URI                                                                                            | Service
---+---------------------------+-----------------------------------------+---------+-----------+---------+----------+--------+------------------------------------------------------------------------------------------------+--------
 1 | Graphics                  | Graphics                                | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://download.opensuse.org/repositories/graphics/openSUSE_Leap_42.3/                         |        
 2 | Kernels                   | Kernels                                 | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://download.opensuse.org/repositories/Kernel:/stable/standard/                             |        
 3 | openSUSE-Leap-42.3-0      | openSUSE-Leap-42.3-0                    | No      | ----      | ----    |   99     | yast2  | hd:///?device=/dev/disk/by-id/usb-Kingston_DataTraveler_3.0_60A44C413980F141C97C02CA-0:0-part2 |        
 4 | packman.inode.at-suse     | Packman Repository                      | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://packman.inode.at/suse/openSUSE_Leap_42.3/                                               |        
 5 | repo-debug                | openSUSE-Leap-42.3-Debug                | No      | ----      | ----    |   99     | NONE   | http://download.opensuse.org/debug/distribution/leap/42.3/repo/oss/                            |        
 6 | repo-debug-non-oss        | openSUSE-Leap-42.3-Debug-Non-Oss        | No      | ----      | ----    |   99     | NONE   | http://download.opensuse.org/debug/distribution/leap/42.3/repo/non-oss/                        |        
 7 | repo-debug-update         | openSUSE-Leap-42.3-Update-Debug         | No      | ----      | ----    |   99     | NONE   | http://download.opensuse.org/debug/update/leap/42.3/oss/                                       |        
 8 | repo-debug-update-non-oss | openSUSE-Leap-42.3-Update-Debug-Non-Oss | No      | ----      | ----    |   99     | NONE   | http://download.opensuse.org/debug/update/leap/42.3/non-oss/                                   |        
 9 | repo-non-oss              | openSUSE-Leap-42.3-Non-Oss              | Yes     | (r ) Yes  | Yes     |   99     | yast2  | http://download.opensuse.org/distribution/leap/42.3/repo/non-oss/                              |        
10 | repo-oss                  | openSUSE-Leap-42.3-Oss                  | Yes     | (r ) Yes  | Yes     |   99     | yast2  | http://download.opensuse.org/distribution/leap/42.3/repo/oss/                                  |        
11 | repo-source               | openSUSE-Leap-42.3-Source               | No      | ----      | ----    |   99     | NONE   | http://download.opensuse.org/source/distribution/leap/42.3/repo/oss/                           |        
12 | repo-source-non-oss       | openSUSE-Leap-42.3-Source-Non-Oss       | No      | ----      | ----    |   99     | NONE   | http://download.opensuse.org/source/distribution/leap/42.3/repo/non-oss/                       |        
13 | repo-update               | openSUSE-Leap-42.3-Update               | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://download.opensuse.org/update/leap/42.3/oss/                                             |        
14 | repo-update-non-oss       | openSUSE-Leap-42.3-Update-Non-Oss       | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://download.opensuse.org/update/leap/42.3/non-oss/                                         |

Is there some simple solution to this please?

Peter

tsu2 · September 29, 2017, 8:33pm

More info needed.
Use journalctl to find and display the complete error.

TSU

pblewis · September 29, 2017, 9:01pm

journalctl provided this at its tail:

Sep 29 19:59:39 bardsey systemd[1]: Started Virtual machine log manager.
Sep 29 19:59:39 bardsey kernel: tun: Universal TUN/TAP device driver, 1.6
Sep 29 19:59:39 bardsey kernel: br0: port 2(vnet0) entered blocking state
Sep 29 19:59:39 bardsey kernel: br0: port 2(vnet0) entered disabled state
Sep 29 19:59:39 bardsey kernel: device vnet0 entered promiscuous mode
Sep 29 19:59:39 bardsey kernel: br0: port 2(vnet0) entered blocking state
Sep 29 19:59:39 bardsey kernel: br0: port 2(vnet0) entered forwarding state
Sep 29 19:59:39 bardsey dbus[1114]: [system] Activating via systemd: service name='org.freedesktop.machine1' unit='dbus-org.freedesktop.machine1.service'
Sep 29 19:59:39 bardsey systemd[1]: Created slice Virtual Machine and Container Slice.
Sep 29 19:59:39 bardsey systemd[1]: Starting Virtual Machine and Container Registration Service...
Sep 29 19:59:39 bardsey dbus[1114]: [system] Successfully activated service 'org.freedesktop.machine1'
Sep 29 19:59:39 bardsey systemd[1]: Started Virtual Machine and Container Registration Service.
Sep 29 19:59:39 bardsey systemd[1]: Started Virtual Machine qemu-1-win7.
Sep 29 19:59:39 bardsey systemd-machined[4879]: New machine qemu-1-win7.
Sep 29 19:59:39 bardsey kernel: cgroup: cgroup: disabling cgroup2 socket matching due to net_prio or net_cls activation
Sep 29 19:59:39 bardsey libvirtd[1733]: 2017-09-29 18:59:39.781+0000: 1798: info : libvirt version: 3.3.0
Sep 29 19:59:39 bardsey libvirtd[1733]: 2017-09-29 18:59:39.781+0000: 1798: info : hostname: bardsey.cih.avex.co.uk
Sep 29 19:59:39 bardsey libvirtd[1733]: 2017-09-29 18:59:39.781+0000: 1798: error : virProcessRunInMountNamespace:1159 : internal error: child reported: Kernel does not provide mount namespace: Permission denied
Sep 29 19:59:39 bardsey kernel: br0: port 2(vnet0) entered disabled state
Sep 29 19:59:39 bardsey kernel: device vnet0 left promiscuous mode
Sep 29 19:59:39 bardsey kernel: br0: port 2(vnet0) entered disabled state
Sep 29 19:59:39 bardsey systemd-machined[4879]: Machine qemu-1-win7 terminated.

Hope it means something to you.

Peter

malcolmlewis · September 29, 2017, 9:12pm

Hi
Looks like Apparmor, but this is on Tumbleweed…
https://www.redhat.com/archives/libvirt-users/2017-March/msg00031.html

Is there a specific reason your running the 4.13.x kernel?

pblewis · September 29, 2017, 10:26pm

I am running KabyLake on an ASUS board and had problems with graphics. I think it was Wolfi323, seconded by caprus, who suggested using the latest stable kernel and he is quite right it has removed almost all of the tearing and the (I think GTK) dialogues no longer develop black areas.

I am using the built in intel graphics.

You suggested KVM instead of vbox to save the pain of recompiling for the latest kernel.

The original crash problem proved to be a memory fault which was hidden until activity level pushed usage up to the faulty cells. Now solved.

Peter

malcolmlewis · September 29, 2017, 10:47pm

Hi
What about the backports kernel module (drm-kmp-default), no luck with that? Else what about Apparmor in the link?

pblewis · September 29, 2017, 11:41pm

I will try to remove the drm-kmp-default to see if that helps this KVM problem, but I do not see why.

Is there any way to reduce the function of apparmor or should I just turn it off?

Peter

malcolmlewis · September 29, 2017, 11:46pm

Hi
No, that would be to support your KabyLake with the standard Leap kernel…

FrankyU2 · September 30, 2017, 1:06am

Dude yes, there is a simple solution

edit /etc/libvirt/qemu.conf
after around line 752 add a line

namespaces = ]
save and exit

restart libvirtd daemon as root with

service libvirtd restart

should be be running with kernel 4.13.3-1 now.

tsu2 · September 30, 2017, 4:59am

Hopefully the above post by @FrankyU2 works, that the problem is a simple config error where a namespaces statement is missing.

If that doesn’t work, then I’d recommend you try creating a new bridge device by any means (YaST, vm manager, whatever).
Luckily, br0 is a fairly well known configuration if you created it using YaST when you first installed Virtualization… It’s a simple networking device that enables Guests to access the physical network like any other physical machine.

If you have any problems creating a new bridge device, post here again describing what you attempted.

TSU

arvidjaar · September 30, 2017, 8:43am

This is apparently due to kernel 4.13 changes: https://www.redhat.com/archives/libvir-list/2017-September/msg00546.html

tsu2 · October 1, 2017, 12:16am

Yes,
Looks like it’s likely related.

Another example why it’s generally inadvisable to ever choose TW as your HostOS (unless you don’t mind something breaking and non-functional for some time).
IMO a bad roll-out of a security feature. I’m sure better fine-grained controls are generally a good idea but when first rolling out, the policy should be lax to minimize immediate impact. That is, unless there is a recognized immediate threat being addressed.

IMO,
TSU

malcolmlewis · October 1, 2017, 12:44am

Hi
The OP is running openSUSE Leap 42.3 (and thread prefix) with the TW kernel…

pblewis · October 1, 2017, 11:08am

This solved the problem and the windows guest is able to start in the virtual machine.

Thank you to all who contributed.

Peter

ZeroG · October 5, 2017, 11:54am

In AppArmor just configure the /usr/sbin/libvirtd in complain mode.
This is it.

user · October 27, 2017, 5:46pm

After updating from 42.2 to 42.3 today I had the exact same problem as the OP and this fixed it.
Could you please explain why this works and what exactly it does? IOW - why is it necessary to do it after updating to 42.3

tsu2 · October 27, 2017, 7:08pm

As I posted above,
This bug appears to be a missing namespace statement in a config file…

Something this simple hopefully should be fixed almost quickly…
Looks like a bug has already been submitted

https://bugzilla.opensuse.org/show_bug.cgi?id=1063653

I doubt this has much to do with 42.3, it’s more likely associated with the libvirt version and you got the more recent version when you upgraded.

TSU

user · October 27, 2017, 7:47pm

Thanks TSU.
Hm. That bug links to another one:

https://bugzilla.opensuse.org/show_bug.cgi?id=1062966

which says it is already fixed. How come it is not?

tsu2 · October 27, 2017, 8:15pm

IMO
Not the same. The apparmor fix in the above bug was considered to be a proper fix and was not recognized as simply a workaround which is what was described in this Forum thread.

In this Forum thread, you’ll notice that the AppArmor “fix” was only to relax so problems are “complained” and not <enforced>. When AppArmor is set this way, then certain bugs won’t prevent functionality whereas “enforced” would block.

imo,
TSU

user · October 28, 2017, 1:22am

But if it is considered a duplicate of that bug and the duplicate is fixed - it means it won’t be fixed?
Why don’t you report it with more details (as I am not as familiar with the intricacies as you)?