Comment 9 for bug 470636

I looked into this quite a bit, and the problem is that libvirt is unaware of the pristine cow/snapshot that the disk file is referencing. All that is in the machine definition is the <disk> entry, which points only to the snapshot/cow, not the underlying image. I can't (and won't) fix this because the only way to do that is to make libvirt peek into the disk file and see what its backing store is. This would allow an avenue for an attacker to escape the VM, or at least read/overwrite arbitrary files on the host. If the VM is compromised, the attacker has write access to the disk file, which could be modified to point to another file on the disk. Simply put, libvirt should not be looking at an attacker controlled file for determining access controls.

The support that was added in 0.6.0 that Olivier mentioned is for '<backingstore>', which can be used as a part of a volume definition in a storage pool. This also does not work right now, but I plan to fix it for Lucid, and possibly do an SRU for Karmic if the changes aren't too drastic (I'm hoping they won't be).

In the meantime, as a workaround, people can do one of two things:
1. modify /etc/apparmor.d/libvirt-<uuid> for the additional file. This will maintain guest isolation (ie, one VM cannot access files of another VM). This also needs to be done for each VM that uses a cow/snapshot file.
2. modify /etc/apparmor.d/abstractions/libvirt-qemu to allow access to all files in a particular directory, and put all your backing store files in that directory. This breaks guest isolation (ie, one VM can read/write to all of the files in this directory), but it does maintain host protection.

See /usr/share/doc/libvirt-bin/README.Debian.gz for details on the architecture of the sVirt AppArmor driver and how to customize it for your environment.