7:33 a.m.
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 :|