9:06 a.m.
On 08/25/2011 05:54 AM, Stefan Hajnoczi wrote:
On Tue, Aug 23, 2011 at 4:47 PM, Eric Blake<eblake(a)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(a)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(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org