apparmor blocks migration

Bug Description

Trying to perform a migration results in the following on the destination:
[ 990.435799] type=1503 audit(1256595461.009:24): operation="socket_create" pid=4181 parent=1 profile="/usr/sbin/libvirtd" family="inet" sock_type="dgram" protocol=0
[ 990.435826] type=1503 audit(1256595461.009:25): operation="socket_create" pid=4181 parent=1 profile="/usr/sbin/libvirtd" family="inet" sock_type="dgram" protocol=0
[ 1039.321832] type=1503 audit(1256595509.899:26): operation="socket_create" pid=4181 parent=1 profile="/usr/sbin/libvirtd" family="inet" sock_type="dgram" protocol=0
[ 1039.321851] type=1503 audit(1256595509.899:27): operation="socket_create" pid=4181 parent=1 profile="/usr/sbin/libvirtd" family="inet" sock_type="dgram" protocol=0

Need to add the following to /etc/apparmor.d/usr.sbin.libvirt:
network inet dgram,

Then perform:
$ sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.libvirtd

Note that there are other migration issues as detailed in https://bugzilla.redhat.com/show_bug.cgi?id=499750, however, once hostnames are setup right, then migration should hopefully work in 9.10 (after the profile is updated).

As for hostnames it works perfectly for jaunty, not for karmic.

In Jaunty live migration worked with:
listen_tls = 0
listen_tcp = 1
auth_tcp = "none"
in /etc/libvirt/libvirtd.conf

Worked in Jaunty:
# virsh --connect=qemu+tcp://node1/system migrate --live vm1 qemu+tcp://node2/system

hostnames node1 and node2 should be in /etc/hosts or setuped any other way.
vm1 guest is in running state.

Here is a few changes i made in profiles to test migration in karmic.
To bind libvirtd (libvirtd_opts should be with -l key to /etc/default/libvirt-bin) add to /etc/apparmor.d/usr.sbin.libvirtd:
network inet dgram,
network inet6 stream,
network inet6 dgram,

I also added my nfs share to save and restore domains out of $home in /etc/apparmor.d/abstractions/libvirt-qemu:
/mnt/nfs/save/** rw,

Worked in karmic:
# virsh --connect=qemu+tcp://node1/system save vm1 /mnt/nfs/save/vm1
# virsh --connect=qemu+tcp://node1/system restore /mnt/nfs/save/vm1
I suggest there's enough permissions for migration. or not?

Also tried migration under karmic, too:
# virsh --connect=qemu+tcp://node1/system migrate --live vm1 qemu+tcp://node2/system
Tried to test when vm1 guest is in running state (in suspended state the same result).
It seems to pass right, but guest hangs after migration (but in virsh list it correctly shows it running on destination host after migration even if vm1 was suspended before migration). But if i suspend and resume guest it became working like if guest was paused before migration:

# virsh --connect=qemu+tcp://node2/system suspend vm1
# virsh --connect=qemu+tcp://node2/system resume vm1

But such live migration not a _live_ migration as it should be for running vm1 guest. There's a non-zero downtime between suspend and resume. :(

I think problem is not only in apparmor profilies (tried to turn off at all).
Any ideas?

PS. Sorry for terrible English.

This bug is for the apparmor problem. There is another bug for qemu+tcp:// being blocked by apparmor. Please file a new bug regarding migration issues not related to apparmor (note, you may want to look at the aforementioned redhat bug).

Just found a Bug #448674 with my situation. Posted there how to reproduce.

SRU

Impact: migratino no longer works

Bug is addressed in Lucid by adding 'inet dgram' to the usr.sbin.libvirtd profile

See comment #2

The regression potential is considered extremely low. It only allows additional access the the profile previously denied.

This bug was fixed in the package libvirt - 0.7.0-1ubuntu14

---------------
libvirt (0.7.0-1ubuntu14) lucid; urgency=low

* debian/patches/9093-lp460271.patch: require absolute path for dynamic
added files (LP: #460271)
* debian/patches/9094-lp453335.patch: suppress confusing and misleading
apparmor denied message when kvm/qemu tries to open a libvirt specified
readonly file (such as a cdrom) with write permissions. libvirt uses the
readonly attribute for the security driver only, and has no way of telling
kvm/qemu that the device should be opened readonly. (LP: #453335)
* debian/apparmor/usr.sbin.libvirtd: allow 'inet dgram' for migration to
work (LP: #461528)
* debian/apparmor/usr.sbin.libvirtd: properly support qemu+tcp:// by
allowing 'inet6 stream' and 'inet6 dgram' (LP: #462000)
-- Jamie Strandboge <email address hidden> 2009年11月09日 17:11:05 -0600

Accepted libvirt into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

This now works in 0.7.0-1ubuntu13.1:

$ virsh list
Connecting to uri: qemu:///system
Id Name State
----------------------------------
1 testqemu-migrate running

$ ssh 192.168.122.3 virsh list
Connecting to uri: qemu:///system
Id Name State
----------------------------------

$ virsh migrate --live testqemu-migrate qemu+ssh://192.168.122.3/system
Connecting to uri: qemu:///system

$ virsh list
Connecting to uri: qemu:///system
Id Name State
----------------------------------

$ ssh 192.168.122.3 virsh list
Id Name State
----------------------------------
1 testqemu-migrate running

This bug was fixed in the package libvirt - 0.7.0-1ubuntu13.1

---------------
libvirt (0.7.0-1ubuntu13.1) karmic-proposed; urgency=low

* debian/patches/9093-lp460271.patch: require absolute path for dynamic
added files (LP: #460271)
* debian/patches/9094-lp453335.patch: suppress confusing and misleading
apparmor denied message when kvm/qemu tries to open a libvirt specified
readonly file (such as a cdrom) with write permissions. libvirt uses the
readonly attribute for the security driver only, and has no way of telling
kvm/qemu that the device should be opened readonly. (LP: #453335)
* debian/apparmor/usr.sbin.libvirtd: allow 'inet dgram' for migration to
work (LP: #461528)
* debian/apparmor/usr.sbin.libvirtd: properly support qemu+tcp:// by
allowing 'inet6 stream' and 'inet6 dgram' (LP: #462000)
-- Jamie Strandboge <email address hidden> 2009年11月09日 17:12:32 -0600