[libvirt] Support for qemu snapshot=on drives in libvirt

Richard W.M. Jones rjones at redhat.com
Fri Oct 5 11:40:39 UTC 2012


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




More information about the libvir-list mailing list