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:
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
On 06/06/2012 10:55 AM, Sean Abbott wrote: 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.