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 ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
