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. >
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
