nova interface-attach fails

[James Page]

=====================================
SRU Justification:
Impact: nova attach-interface fails
Test Case: nova attach-interface
Regression potential: this only allows virt-aa-helper to detect whether vhost-net needs to be accessible to qemu. It should not regress anything which was previously working.
=====================================
Performing a nova interface-attach on a running instance fails; looks like apparmor is blocking access to /dev/vhost-net:

May 23 10:30:43 caipora kernel: [70013.846910] device tapce18fa24-d3 entered promiscuous mode
May 23 10:30:43 caipora kernel: [70013.867013] qbrce18fa24-d3: port 2(tapce18fa24-d3) entered forwarding state
May 23 10:30:43 caipora kernel: [70013.867019] qbrce18fa24-d3: port 2(tapce18fa24-d3) entered forwarding state
May 23 10:30:43 caipora kernel: [70013.884964] type=1400 audit(1400841043.894:48): apparmor="DENIED" operation="file_receive" profile="libvirt-bc92e7cf-e67e-4fe3-b1bd-b95b1f1438eb" name="/dev/vhost-net" pid=54982 comm="qemu-system-x86" requested_mask="rw" denied_mask="rw" fsuid=109 ouid=0
May 23 10:30:43 caipora kernel: [70013.889005] qbrce18fa24-d3: port 2(tapce18fa24-d3) entered disabled state
May 23 10:30:43 caipora kernel: [70013.889640] device tapce18fa24-d3 left promiscuous mode
May 23 10:30:43 caipora kernel: [70013.889661] qbrce18fa24-d3: port 2(tapce18fa24-d3) entered disabled state
May 23 10:30:43 caipora kernel: [70013.951703] qbrce18fa24-d3: port 1(qvbce18fa24-d3) entered disabled state

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: libvirt-bin 1.2.2-0ubuntu13.1
ProcVersionSignature: User Name 3.13.0-24.46-generic 3.13.9
Uname: Linux 3.13.0-24-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
Date: Fri May 23 10:31:05 2014
ProcEnviron:
 TERM=screen-bce
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: libvirt
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.default.libvirt.bin: [modified]
modified.conffile..etc.libvirt.libvirtd.conf: [modified]
modified.conffile..etc.libvirt.qemu.conf: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/qemu.conf']
mtime.conffile..etc.default.libvirt.bin: 2014-05-22T15:07:14.068622
mtime.conffile..etc.libvirt.libvirtd.conf: 2014-05-22T15:07:13.472920

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Liam Young (gnuoy)]

Patching /etc/apparmor.d/abstractions/libvirt-qemu with

=== modified file 'libvirt-qemu'
--- libvirt-qemu 2014-05-23 14:09:17 +0000
+++ libvirt-qemu 2014-05-23 14:10:27 +0000
@@ -25,6 +25,7 @@
   /dev/kvm rw,
   /dev/ptmx rw,
   /dev/kqemu rw,
+ /dev/vhost-net rw,
   @{PROC}/*/status r,
   owner @{PROC}/*/auxv r,
   @{PROC}/sys/vm/overcommit_memory r,

fixes the issue.

[Jamie Strandboge (jdstrand)]

Adding /dev/vhost-net to the libvirt-qemu abstraction means that all VMs have access to this file, but I don't think that is what we want to do. Better would be to adjust virt-aa-helper to add this to only VMs that need it, like we do for most all other accesses.

[Serge Hallyn (serge-hallyn)]

Does anyone know offhand which conditions mean we'll need /dev/vhost-net access (that we can check for in virt-aa-helper)?

(If not I'll have to track it down)

[Serge Hallyn (serge-hallyn)]

(I suppose something analogous to this is the right check:

actualType == VIR_DOMAIN_NET_TYPE_NETWORK ||
        actualType == VIR_DOMAIN_NET_TYPE_BRIDGE ||
        actualType == VIR_DOMAIN_NET_TYPE_ETHERNET ||
        actualType == VIR_DOMAIN_NET_TYPE_DIRECT
)

[Launchpad Janitor (janitor)]

This bug was fixed in the package libvirt - 1.2.5-0ubuntu3

---------------
libvirt (1.2.5-0ubuntu3) utopic; urgency=medium

  * d/p/virt-aa-helper-vhost.patch: allow access to /dev/vhost-net if domain
    needs it (LP: #1322568)
 -- Serge Hallyn <email address hidden> Tue, 17 Jun 2014 22:01:49 -0500

[Tero Marttila (terom)]

Any chance of getting this fix into trusty?

Fixing this up by hand via /etc/apparmor.d/libvirt/TEMPLATE is possible for pre-existing domain profiles, but involves shutting down the domain etc. Is there any better way?

  virsh shutdown foobar
  sudo /usr/lib/libvirt/virt-aa-helper --delete --uuid libvirt-$(virsh domuuid foobar)
  virsh dumpxml foobar | sudo /usr/lib/libvirt/virt-aa-helper --create --uuid libvirt-$(virsh domuuid foobar)
  virsh start foobar

[Serge Hallyn (serge-hallyn)]

It's marked as 'affecting trusty' meaning we intend to SRU it there. Unfortunately there is another pending SRU which will need to clear before we can push this.

[Chris J Arges (arges)]

Hello James, or anyone else affected,

Accepted libvirt into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/libvirt/1.2.2-0ubuntu13.1.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Chris J Arges (arges)]

Hello James, or anyone else affected,

Accepted libvirt into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/libvirt/1.2.2-0ubuntu13.1.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Jens Rosenboom (frickler)]

Just verified that http://launchpad.net/ubuntu/+source/libvirt/1.2.2-0ubuntu13.1.4 fixes the original issue, i.e. running
nova interface-attach works again after updating libvirt.

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for libvirt has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libvirt - 1.2.2-0ubuntu13.1.4

---------------
libvirt (1.2.2-0ubuntu13.1.4) trusty-proposed; urgency=medium

  * debian/apparmor/usr.sbin.libvirtd - add cap-sys-resource to fully
    fix (LP: #1276719)

libvirt (1.2.2-0ubuntu13.1.3) trusty-proposed; urgency=medium

  * 9026-fix-apparmor-profile-for-vfio-pci-passthrough - allow VFIO passthrough
    (LP: #1276719)
  * 9027-virt-aa-helper-allow-access-to-vhost-net - allow access to
    /dev/vhost-net if domain needs it (LP: #1322568)
 -- Serge Hallyn <email address hidden> Thu, 07 Aug 2014 12:46:22 -0500