[libvirt-users] qemu-img snapshots with backing stores?

[Sean Abbott]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20120606/f0909bbb/attachment.htm>