[libvirt] [patch 0/4] checkpoint functionality

[Daniel P. Berrange]

On Tue, Mar 10, 2009 at 05:18:54PM +0100, Daniel Veillard wrote:
> On Mon, Mar 09, 2009 at 11:14:56PM +0900, Matt McCowan wrote:
> > OK. Another run at producing a function that helps the likes of me
> > backup my kvm Windows servers.
> > 'virsh checkpoint domain file [script]' is what the following patch set
> > (against cvs) enables. Modelled on the virDomainSave function it takes
> > an optional script which it will execute (and pass the name of the
> > domain as an argument) while the domain is paused, then resume the
> > domain.
> 
>   Okay, I quickly looked at the patch and the new API, so no stylistic
> review at this point but more a general feedback. I appreciate the
> completeness of the patch (only bit missing is filling up the virsh
> man page with the new option)
>   I think this can help administrators in a controlled situation,
> but I'm hoping a real snapshotting API will be possible at some point
> where libvirt goes though the list of storage resources used by the
> domain and properly make a snapshot using a storage API or return
> an error if that's not possible.
>   This looks more as a script extension to virDomainSave/Restore
> than really a snapshotting API as I would like libvirt to get at some
> point. To me it doesn't implement snapshotting, it implement running a
> script on a frozen domain. There is a lot of issues with that:
>   - the script need to be in place and there is no hint of what
>     it may contain
>   - what the script does is unbounded, there is a potential very
>     serious security issue there
>   - this does not garantee sucess of the operation and in case of
>     failure the script can't even propagate back an error code and
>     description

Also this kind of API means that all applications using the API need
to know what script to use with what storage in order to take a disk
snapshot. This is quite a burden for apps, and means that most of 
them won't be able to use this snapshot capability in general case.

>   In my opinion this is a bit too ad-hoc to be turned into a full API
> maintained forever, and I'm worried about remote execution capabilities
> this opens up. I really hope we will have one day a real checkpointing
> API in libvirt, but that requires making more progresses on the storage
> management side.

In terms of API I think I'd like to see snapshotting available as part
of a more generic save/restore API. I tend to think of the current API
as providing 'unmanaged save/restore', in so much as libvirt / users
of libvirt have no way of knowing whether there is a saved image for 
the guest available currently.  As an example of why this is a problem,
consider the often requested ability to save/restore guests across
host reboot.

When libvirtd starts, it looks at the autostart flag for a guest, and
decides may thus automatically boot the guest at that time. libvirtd
has no way of knowing whether there was an existing saved image of the
guest available to restore, since it doesn't track saved images.

Thus I think the first step towards a general snapshot facility would
be to provide an API for 'managed save/restore' where we explicitly
track saved images.


- To save a guest:

    enum {
       VIR_DOMAIN_SAVE_LIVE, /* Don't shutdown guest after saving */
    } virDomainSaveFlags;

    virDomainCreateSaveImage(virDomainPtr dom,
                             const char *imagename,
                             unsigned int flags);

  By default, imagename would be NULL, and flags would be zero. In this
  case we'd simply be saving to

      /var/lib/libvirt/saved/qemu/$VMNAME.img

  Providing equivalence to current virDomainSave(dom, filename), but
  with libvirt deciding the actual filename used.

  Now to do snapshots in this scenario, you'd pass a 'imagename' for
  the snapshot - give each snapshot you take some meaningful name as
  you desire. And if VIR_DOMAIN_SAVE_LIVE is set then the guest will
  be allowed to continue running after the snapshot is saved.
 
  Obviously this capability would require some way to take a snapshot
  of the storage, as well as the memory image. We could allow a script
  to do this, or implement it directly for a handful of storage types
  we know can do this (eg, LVM, qcow2).

 - Next, we'd need a way to list saved images
       
        virDomainListSaveImages(virDomainPtr dom,
                                const char **imagenames,
                                unsigned int *numimagenames);

   This would just give back a list of all known imagenames for
   the VM.

 - Then a way to restore from an image

        enum {
           VIR_DOMAIN_RESTORE_DELETE
        } virDomainRestoreFlags;

        virDomainRestoreSaveImage(virDomainPtr dom,
                                  const char *imagename,
                                  unsigned int flags);

    This would restore from the named image. If the VIR_DOMAIN_RESTORE_DELETE
    flag was given, the named image would be deleted after restore (eg to 
    prevent accidental duplicated restore attempts)

 - Perhaps also need a way to delete saved imaged


         virDomainDeleteSaveImage(virDomainPtr dom,
                                  const char *imagename);

  If VIR_DOMAIN_SAVE_LIVE is set, the guest won't be shutdown after
  saving its state. 


 - Perhaps also need a wa yto get more metaata about the save image

           struct virDomainSaveImageInfo {
                 int savedDate;
                 unsigned long long imageSize;
           };
           virDomainGetSaveImgeInfo(virDomainptr dom,
                                    const char *imagename,
                                    virDomainSaveImageInfoPtr info);

   Then again, perhaps the virDomainListSaveImages should just return
   a list of virDomainSaveImageInfoPtr instances directly, instead of
   requiring this extra API call - it'd be faster for remote usage
   in particular because it'd have less round-trips.

With this, you could configure libvirtd, so that when starting up, it
used virDomainListSaveImages to see if the guest was suspended before
the previous host shutdown, and if so, then restore from that saved
image automatically. Or make it skip autostart completely, if any save
images exist, and allow an admin defined initscript to do auto restore
from the save image.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|