On Sat, Jul 21, 2012 at 07:29:00PM +0100, Richard W.M. Jones wrote: > > Partly following up this message: > https://www.redhat.com/archives/libvirt-users/2011-October/msg00142.html > > > > And what about qemu's option "snapshot=on" ? > > > > Unreliable. It won't work with SELinux (since qemu tries to create the > > snapshot on /tmp), and it makes your guest unmigratable. I think that > > it is easier to have libvirt use qemu-img to create a qcow2 wrapper > > prior to booting the guest, at which point the solution is easier to > > control from an sVirt perspective, and is more likely to allow us to > > figure out a way to make things work with migration (at least, I'm > > hoping I can figure out how to migrate a guest with a transient disk). > > Lack of this feature is pretty annoying, particularly since > (a) libguestfs needs it and (b) it's a trivial patch to add > snapshot=on to the qemu driver. So to concentrate on the two > objections above: > > - Why is SELinux concerned about qemu creating and using a file in > /tmp? Obviously it should stop qemu opening and reading random > files from /tmp but that would be a different rule surely? Default labelling of files that are created is done based on the directory label. Since /tmp is a shared directory, this is suboptimal. We want snapshot files to go in a directory which is private to QEMU. More critically in Fedora 18, /tmp is tmpfs so you don't want to be using that for arbitrarily large guest disk files. I agree with the quoted text that libvirt should define a directory to use for the transient disks under /var/lib/libvirt/images perhaps, and just use 'qemu-img create' to create that, and the unlink it once QEMU has started up, so we can auto-cleanup on QEMU shutdown. > - The documentation actually states that using <transient/> may make > your guest unable to migrate, and in any case we don't care. I don't see what's wrong with the docs warning you about this. > > But if you want to use qemu's snapshot=on in the meantime, you can > > use the <qemu:commandline> namespace XML to add it. > > Is there an example how to do this? It seems like it might be > possible using a global qemu '-set device.<id>.snapshot=on' parameter, > but how can I know what <id> libvirt will give to a '-drive' > parameter? (I found from experimentation that it's something like > "drive-virtio-disk0", but I can't track down the bit of code that > produces this string yet ...) Yes, you can use the -set option as you describe. The ID values are produced by produced by qemuAssignDeviceAliases in qemu_command.c Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list