Bug 1348565

What libvirt and qemu version are running there?

Oh totally missed that one:

#libvirtd --version

libvirtd (libvirt) 1.3.1

#qemu-system-x86_64 --version

QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.2), Copyright (c) 2003-2008 Fabrice Bellard

Confirmed, it looks some apparmore issue, since if I do 'sudo aa-complain /etc/apparmor.d/libvirt/*' after the VM has started up, the next connection attempt succeeds.

The reason is that virt-manager is now trying to use the opengraphicsfd API to get a direct graphical connection to qemu via socket FD passing... this is currently required for spice GL support, and gives better performance anyways. But the libvirt apparmor support probably needs to be adjusted to handle this somehow.

There's a similar sounding old bug on the selinux side: https://bugzilla.redhat.com/show_bug.cgi?id=731243

And it looks like the libvirt support tries to label the socket FD with the internal virSecurityManagerSetSocketLabel call, so maybe that gives a hint as to what needs to be fixed in the libvirt apparmor support (or ubuntu apparmor policy? not really sure how it works).

I'll move this bug to libvirt upstream tracker, but I suggest filing a bug with ubuntu libvirt devs to get more attention as well

And CCing some devs who have done apparmor bug fixes

Hi Cole,
sorry for the delay. I just checked on Debian with apparmor and libvirt 2.0.0 and don't see this problem. Also tried the test from the libvirt-test-API

https://libvirt.org/git/?p=libvirt-test-API.git;a=blob;f=repos/domain/open_graphicsfd.py;h=4725d1022af8c062455ae036f304abd71c212c65;hb=58f628fe7be3650f17068eccaff0f4e9fd0d2828

I didn't check over which socket the fd is passed but we fixed some issues with apparmor access to sockets before 1.3.3, so this might be related to the reporter using 1.3.1. I didn' spot anything obvious in Ubuntu's Apparmor profiles that would trigger this either.

Bent, is there a way you can use a newer libvirt version?

Sounds like this is fixed in libvirt 2.0+, so closing

(In reply to Cole Robinson from comment #3)
> Confirmed, it looks some apparmore issue, since if I do 'sudo aa-complain
> /etc/apparmor.d/libvirt/*' after the VM has started up, the next connection
> attempt succeeds.
> 
> The reason is that virt-manager is now trying to use the opengraphicsfd API
> to get a direct graphical connection to qemu via socket FD passing... this
> is currently required for spice GL support, and gives better performance
> anyways. But the libvirt apparmor support probably needs to be adjusted to
> handle this somehow.
> 
> There's a similar sounding old bug on the selinux side:
> https://bugzilla.redhat.com/show_bug.cgi?id=731243
> 
> And it looks like the libvirt support tries to label the socket FD with the
> internal virSecurityManagerSetSocketLabel call, so maybe that gives a hint
> as to what needs to be fixed in the libvirt apparmor support (or ubuntu
> apparmor policy? not really sure how it works).
> 
> I'll move this bug to libvirt upstream tracker, but I suggest filing a bug
> with ubuntu libvirt devs to get more attention as well
> 
> And CCing some devs who have done apparmor bug fixes

For Ubuntu 16.10,

Just confirming that :
- libvirt 2.0+ is NOT fixing this bug
- applying the workaround described above IS fixing the issue.

Have a nice day.

Reopening, looks like there's another patch attempt:

http://www.redhat.com/archives/libvir-list/2017-February/msg01597.html

Eventually fixed by:

commit 1262cbf3a07f361f4417ccd9076d98b13f4cd223
Author: Christian Ehrhardt <christian.ehrhardt>
Date:   Mon Aug 13 15:58:06 2018 +0200

    apparmor: allow openGraphicsFD for virt manager >1.4