
On 10/05/2012 05:40 AM, Richard W.M. Jones wrote:
I notice that the qemu driver doesn't support snapshot drives (-drive file=foo,snapshot=on). This is important for libguestfs.
Currently libguestfs hacks this using <qemu:arg>. That works fine for static disks in the libvirt XML, but lack of direct support in libvirt is a blocker for adding hotplugging to libguestfs.
In qemu, the snapshot=on feature does several things:
(a) It creates a temporary qcow2 disk in $TMPDIR.
Which makes the guest non-migrateable.
(e) When qemu exits, the temporary qcow2 disk is deleted.
That's the whole intent of the existing <transient/> tag.
So note that when you use snapshot=on there is an implicit dependency on the $TMPDIR environment variable. I don't know of a way to create the snapshot in another directory (at least, not using snapshot=on .. possibly one can do it by creating an explicit overlay disk in libvirt).
A simple implementation therefore would be to add a <snapshot/> element to <disk>. It would just add snapshot=on and ignore concerns about $TMPDIR.
Or reuse the <readonly/> flag? Note that these disks are writable.
The <transient/> tag sounds better than a new <snapshot/> tag or abuse of the <readonly/> tag.
A more complex implementation would create an explicit overlay disk in libvirt and clean it up afterwards. This would let us control where the temporary disk is created.
Yes, that's my goal with the <transient/> tag.
XML might look like this:
<snapshot [tmp=...] />
Ah, so making <transient> take optional attributes (and/or subelements) to further refine HOW the temporary file is created; but if not present, then libvirt defaults to as sane as possible.
I'm also concerned about the time is takes to run the external 'qemu-img create' command, which is non-trivial in some versions of qemu. In libguestfs, every millisecond counts.
$ time qemu-img create -f qcow2 test.qcow2 10M Formatting 'test.qcow2', fmt=qcow2 size=10485760 encryption=off cluster_size=65536
real 0m0.610s user 0m0.022s sys 0m0.009s
Or, can this be done using existing libvirt features?
Existing libvirt has a way to create qcow2 files within a storage pool, but does so by calling out to qemu-img. As for why qcow2 creation is slow, I don't know what we can do about it.
Any thoughts on this before I implement something ...
We definitely need to tie it into the XML that has already been designated for this purpose: <transient/>. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org