[libvirt] RFCv2: virDomainSnapshotCreateXML enhancements

Eric Blake eblake at redhat.com
Thu Aug 25 14:06:15 UTC 2011


On 08/25/2011 05:54 AM, Stefan Hajnoczi wrote:
> On Tue, Aug 23, 2011 at 4:47 PM, Eric Blake<eblake at redhat.com>  wrote:
>> On 08/23/2011 09:35 AM, Stefan Hajnoczi wrote:
>>>
>>> On Tue, Aug 23, 2011 at 4:18 PM, Eric Blake<eblake at redhat.com>    wrote:
>>>>
>>>> On 08/23/2011 09:12 AM, Stefan Hajnoczi wrote:
>>>   The
>>> kinds of apps I am thinking about cannot make use of this API.
>>
>> What sort of APIs do you need for the apps you are thinking about? Without
>> details of your needs, it's hard to say whether we can build on the
>> framework we have to add the additional features you want.
>
> Take virt-manager and virsh, they should probably provide easy-to-use
> snapshot functionality to users (i.e. snapshot create, snapshot
> revert, snapshot delete, snapshot list).

And to some degree, virsh already has those.  As I've been writing the 
series, I've been adding flags to those existing commands to expose the 
new functionality, but the core concepts remain the same.  The end goal 
is that 'virsh snapshot-revert dom snap' will properly revert for any 
type of snapshot, or else give a sensible error message of why it cannot 
revert by default and how to fix that (such as by acknowledging that the 
revert is risky because the snapshot was created prior to the point in 
time where libvirt stored full domain xml, so adding the --force flag is 
sufficient to promise that your current domain xml is compatible with 
the xml that was in use at the time the snapshot was created).

 >  These tools will need to
> understand the different storage scenarios and special flags required
> depending on the type of snapshot, state of the VM, etc.  These code
> paths need to be duplicated in all clients that want to  use the
> libvirt API.

Yes.  And the libvirt API is already achieving that.  'virsh 
snapshot-create' is a single wrapper that knows how to create system 
checkpoints (qemu savevm) and disk snapshots (qemu snapshot-blkdev), 
without the user having to know the difference between those commands. 
And as more snapshot patterns are added to the API, the user interface 
will still be 'virsh snapshot-create', with the only changes needed 
being to the xml used in <domainsnapshot> to specify whether the 
snapshot is done at the qemu qcow2 layer, or at the lvm layer, or so forth.

>  This is what I'm pointing out.  In other APIs like
> VMware's VIX, the snapshot functionality doesn't leak the special
> cases so doing simple things is simple.

The unadorned use of 'virsh snapshot-create' is already the simplest - 
create a full system checkpoint.  It is only when you want less than a 
full system checkpoint where you have to start being specific.

>
> The particular case I care about is a backup solution that wants to:
> 1. Find out which VMs are running
> 2. Snapshot a set of running or stopped VMs

Yes, 'virsh snapshot-create' works on both running and stopped VMs.

> 3. Copy the snapshot disk contents off-host

Possible with offline internal snapshots using qemu-img, but not yet 
exposed by libvirt.  Not possible with online internal snapshots until 
qemu exposes more functionality.  Possible with offline or online 
external snapshots using cp, but not yet exposed by libvirt.  At any 
rate, yes, we will need to add new libvirt APIs to access this without 
the user having to know whether to use qemu-img, cp, or some other 
means, but we need qemu help for part of this task.

> 4. Perform incremental snapshots and only copy dirty blocks off-host

Not possible with either qemu-img (offline) or qemu (online); again, we 
will need new libvirt API, but we also need hypervisor functionality to 
expose this.

> 5. Be able to completely restore a VM including its configuration and
> disk contents

My pending series just fixed 'virsh snapshot-restore' to properly do this.

> The point I'm trying to make is that an API should provide a
> vocabulary to handle tasks at a certain level of abstraction.  If the
> API is just a pass-through of the underlying primitives, then it
> doesn't provide much gain over doing things without the API.

virDomainSnapshotCreateXML is indeed a higher layer than qemu's 
snapshot_blkdev, but it sounds like you want yet another layer on top of 
virDomainSnapshotCreateXML.

 >  When I
> write an application that uses the snapshot API, I should think in
> terms of snapshot creation, deletion, revert, etc and not in terms of
> "if the underlying storage is X and the VM is current stopped, then I
> have to do this sequence of steps".

And you already have that with virDomainSnapshotCreateXML, for the 
scenarios that we support (admittedly, right now the only scenarios we 
support are qcow2 internal system checkpoints and creation of external 
disk snapshots, but this is extensible to other formats as more code is 
contributed).  The important point is that you _don't_ have to worry 
about issuing the guest-agent freeze command, then the qemu pause 
command, then the individual snapshot_blkdev commands, then the resume 
commands.  Rather, a single virDomainSnapshotCreateXML will do that 
entire sequence in order to create a sane multi-disk snapshot.

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org




More information about the libvir-list mailing list