Re: [libvirt] RFCv2: virDomainSnapshotCreateXML enhancements
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). 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. 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 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
3. Copy the snapshot disk contents off-host
4. Perform incremental snapshots and only copy dirty blocks off-host
5. Be able to completely restore a VM including its configuration and
disk contents
> This is largely because there is no API for accessing snapshot
> contents. But even the snapshot API itself has too many flags/cases
> that require the user to already know exactly what they want to do
> down to a level of detail where I wonder why they would even want to
> use libvirt and not just do, say, LVM snapshots manually.
You _can't_ make a manual LVM snapshot of a running qemu process, and expect
the result to be consistent. But you _can_ use my new API to create an
external qcow2 snapshot, at which point you can then access the backing file
and create an LVM snapshot. That is, the goal of this API series right now
is to add live external snapshot support - exposing the qemu snapshot_blkdev
monitor command - while still leaving the xml flexible enough to later add
further snapshot capabilities.
If you freeze the fs inside the guest then LVM snapshots are fine.
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. 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".
Stefan