Yeah, apparmor's not really installed despite the /etc/apparmor.d directory being there on account of libvirt adding it (I guess).

Hmm....


On 06/06/2012 05:23 PM, Eric Blake wrote:
On 06/06/2012 10:55 AM, Sean Abbott wrote:
So, I was attempting to use qemu snapshots with backing stores.  The
QEMU docs (http://wiki.qemu.org/Documentation/CreateSnapshot) make it
sound like you simply point your qemu at the snapshot after it's
creation, and you're golden.

When attempting this with libvirt, though, it fails.
Libvirt definitely supports this, as I use it for my guests, so let's
figure out where you went wrong.  By the way, libvirt can create qcow2
files itself, rather than forcing you to hand-create it with qemu-img,
although support for this could probably be improved with more APIs and
documentation.  Patches welcome.

I created a snapshot using the above tutorial.  the resulting file is
disk.0, and a qmeu-img info on it returns:

image: disk.0
file format: qcow2
virtual size: 29G (31457280000 bytes)
disk size: 140K
cluster_size: 65536
backing file: /var/lib/one/public/lin_client_current.qcow2 (actual path:
/var/lib/one/public/lin_client_current.qcow2)

So that all looks groovy, right?
Unfortunately, 'qemu-img info' output doesn't say whether you properly
populated the backing_fmt property, but I will assume that is not your
issue (do note, however, that failure to use the backing_fmt property is
a security hole - it means libvirt and/or qemu will autoprobe the format
from the backing file itself, but if the backing file is supposed to be
raw, the guest can manipulate the backing file into looking non-raw, and
cause your host to hand over control of files to the guest that should
not normally be accessible to the guest).

Then, I created (via opennebula) an xml deployment file like so: 
http://paste.ubuntu.com/1027145/
which included:

		<disk type='file' device='disk'>
			<source file='/var/lib/one/vm/56/images/disk.0'/>
			<target dev='hda' bus='virtio'/>
			<driver name='qemu' type='qcow2' cache='none'/>

and that looked correct to me.

When I attempt to do a virsh create, I get the following errors:

virsh # create deployment.0
error: Failed to create domain from deployment.0
error: internal error process exited while connecting to monitor:
file=/var/lib/one/vm/56/images/disk.0,if=none,id=drive-virtio-disk0,boot=on,format=qcow2,cache=none
qemu-kvm: boot=on|off is deprecated and will be ignored. Future versions
will reject this parameter. Please update your scripts.
This warning is not the real problem, but a patch to libvirt to avoid it
might be nice, if it hasn't already been patched in newer libvirt.

qemu-system-x86_64: -drive
file=/var/lib/one/vm/56/images/disk.0,if=none,id=drive-virtio-disk0,boot=on,format=qcow2,cache=none,boot=on:
could not open disk image /var/lib/one/vm/56/images/disk.0: Invalid argument
You mentioned Ubuntu - do you have appArmor running?  This could be a
case of the apparmor settings on your machine preventing qemu from
opening the backing file.  I don't have Ubuntu experience myself to tell
you how to resolve it (I tend to work with SELinux on Fedora as my
security mechanism), but suspect that it might be a failure along the
lines of an over-strict security policy.

So...something isn't working. Is it possible to do this, or should I
give up on this path?
Libvirt definitely supports what you want to do, but I don't know what
to suggest to help you get further.