Starting VMs on qcow2 format with base images in level three fails

Thank you for taking the time to file this report and helping to make Ubuntu better.

The information in the description shows that level3.img is owned by root:root, and that the reason for not being able to use level3.img was due to permission being denied. Could you chown libvirt-qemu:kvm /tmp/level*.img, and try again?

Note: since libvirt chowns the files before using them, it actually seems more likely that level2.img or level1.img would be the problem. I can devise one or two sequence of events and experiments which would cause one of the base image files to be inaccessible to libvirt. That might be a real bug worth bringing up upstream.

Sorry, I'd missed the very start of your description. I see that's what you're actually reporting.

I think this is a valid bug with the dac security driver.

Looking at the libvirt source code, the chowning of the files to root:root rather than your own credentials is not a bug, but a not-yet-implemented feature (marked by the comment '/* XXX record previous ownership */').

Nevertheless, I assume (hope) that level1.img and level2.img do not get chowned to root:root when level3.img was used as the disk image. So long as that is the case, as a workingaround you should be able to initially chown all three files to libvirt-qemu:qemu. After each session is closed libvirt will chown level3.img to root:root, but not touch the other two. On next startup, level1 and level2 are owned by the right user, and level3 will get chowned.

Please reply and let us know if that is not the case.

A-ha! It's not the dac driver. It's the apparmor driver. 'grep apparmor /var/log/syslog | tail' gives me a bunch of:

Jan 3 19:04:06 localhost kernel: [11904.438804] type=1400 audit(1294103046.071:33): apparmor="DENIED" operation="open" parent=1 profile="libvirt-e58d045d-d4ed-39eb-09d2-c884173ff64c" name="/tmp/level1.img" pid=15084 comm="kvm" requested_mask="r" denied_mask="r" fsuid=117 ouid=117

The apparmor libvirt driver isn't writing policy to allow access to level1.img.

This is probably a bug in virDomainDiskDefForeachPath(), as used by get_files() in virt-aa-helper.c and SELinuxSetSecurityImageLabel() in security_selinux.c. virDomainDiskDefForeachPath() is used to enumerate the disk images to add to the dynamic policy for the security drivers.

A workaround is to add the missing path to /etc/apparmor.d/libvirt/libvirt-<uuid> for the VM in question (but not the dynamically generated /etc/apparmor.d/libvirt/libvirt-<uuid>.files). Obviously this has to be down manually on a per machine basis.

This issue still exist at ubuntu12.04...
@Jamie Strandboge (jdstrand)
what should i to add in /etc/apparmor.d/libivrt/libvirt-<uuid>.files ?
thx a lot ~

My workarround is to add this to the end of /etc/apparmor.d/abstractions/libvirt-qemu

# Work around for bug 696318 in KVM
/var/lib/libvirt/images/** r,

It works for me on ubuntu precise 12.04

workarount from comment #9 works for me too.
Thanks David :)

ubuntu 13.10

#9 works perfectly but will this ever be pushed into the distro?
I am adding it manually and have to do so continually as new updates arrive that update the file.

The approach in comment #9 is not acceptable, as it allows all VM guests to access all other VM guests's data. It also would not suffice. For instance the example in the Description uses /tmp rather than /var/lib/libvirt/images, and would not be fixed.

What we need is for virt-aa-helper to be extended to calculate the files to which access is needed.

If someone is familier with the best way for libvirt code to determine the full chain of backing stores for a particular file, then the patch should be quite simple.

As it turns out, this is actually a user error.

When creating the level2.img and level3.img, you must specify the backing store type, because libvirt won't automatically detect those for safety reasons. So you should do:

qemu-img create -f qcow2 -o backing_fmt=qcow2 -b level1.img level2.img
qemu-img create -f qcow2 -o backing_fmt=qcow2 -b level2.img level3.img

After doing that, boot succeeds on my laptop.