7:22 a.m.
On Thu, Aug 25, 2011 at 3:06 PM, Eric Blake <eblake(a)redhat.com> wrote:
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.
The virsh commands you have described sound good. That's the level at
which I imagine third-party tools and custom scripts would want to
work with snapshots. For special cases the low-level APIs are
necessary.
A virsh snapshot-create libvirt API would be good so that non-virsh
apps using libvirt do not need to duplicate its behavior.
Back to QEMU support, here's what I see missing:
1. merge_blkdev to flatten a COW file into its backing file snapshot.
This undoes the effect of snapshot_blkdev. Can be used to "delete" a
snapshot.
2. Dirty block API
3. Reading snapshot contents of live image. My focus is on the disk
snapshot case and not on savevm internal snapshots, but it could still
be useful.
A backup workflow involves taking consistent snapshots periodically
(e.g. once a day). Therefore it is important to keep the backing file
chain at a fixed length and we need the merge_blkdev command in QEMU.
This looks like the next QEMU task to tackle, I'll try to propose
something next week in order to get start on merge_blkdev.
Stefan