Libguestfs - Oct 2012 - Support for qemu snapshot=on drives in libvirt

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.

(b) It sets the backing file of the temporary disk to the real disk.

(c) When running, writes to the disk go to the temporary overlay, and
not to the real disk.

(d) I believe it also lets you commit changes from the temporary disk
to the backing file using a monitor command ("commit"?
"save"?).
However we don't need or use this feature.

(e) When qemu exits, the temporary qcow2 disk is deleted.

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.

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.  XML might look like this:

  <snapshot [tmp=...] />

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?

Any thoughts on this before I implement something ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

Reading back over the archives, I see there was a proposal to add a
<disk ... persistent="no"> attribute.  I don't think that
was ever
adopted.

http://www.redhat.com/archives/libvir-list/2011-July/msg00649.html

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v

Il 05/10/2012 13:40, Richard W.M. Jones ha scritto:
> 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.
qemu-img create is a thin wrapper for bdrv_create that would be done
anyway by QEMU.  So there is no difference apart from the cost of
loading the binary.

Paolo

And looking even more closely, I see disk->transient (not
implemented in the qemu driver ... why?)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

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 at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 617 bytes
Desc: OpenPGP digital signature
URL:
<http://listman.redhat.com/archives/libguestfs/attachments/20121005/30104b72/attachment.sig>

On Fri, Oct 05, 2012 at 06:28:32AM -0600, Eric Blake
wrote:
> On 10/05/2012 05:40 AM, Richard W.M. Jones wrote:
> > 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.
[...]
> 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.
Actually, libvirt(d) is not sane at the moment.  It picks the $TMPDIR
that happens to have been in the environment when virConnectOpen was
first called, and uses it for all following calls until libvirtd is
restarted.  (However you can override this using <qemu:env> although
apparently we shouldn't do that).

This especially matters for libguestfs non-root tests, because we set
$TMPDIR and old $TMPDIR's get deleted which used to cause qemu to fail
to start, until I started to use <qemu:env>.
> 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.
I'll take a look at why qemu-img is so slow.  Half a second isn't
acceptable.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

On Fri, Oct 05, 2012 at 12:40:39PM +0100, 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.
We really need to ask QEMU guys to add a config parameter to specify
the location of the snapshot disks. It is nuts to rely on TMPDIR for
this purpose.

No problem implementing the rest of the libvirt support in the
meantime though. We'll just add another XML attribute to configure
the snapshot location once QEMU is suitably functional


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 :|