[libvirt] RFCv2: virDomainSnapshotCreateXML enhancements

[Eric Blake]

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:
>>> I think we simply cannot expose all this complexity to users.  Each
>>> application would have to support the many different cases.  Libvirt
>>> needs to tie this stuff together and present an interface that
>>> applications can use without worrying how to actually get at the
>>> snapshot data.
>>
>> I don't see any problem with exposing the lower layers as a start, then
>> adding higher layers as we go.  There are different classes of users, and
>> both layers are useful in the right context.  But at the same time, I agree
>> with you that what I have done so far is just a start, and by no means the
>> end of snapshot-related libvirt work.
>
> Do you have a user in mind who will be able to use this API?

Yes.  Someone who wants to do a local device migration can do:

start with a domain with a disk backed only by local storage

virDomainSnapshotCreateXML(,DISK_ONLY) with XML that directs qemu to 
convert that disk over to a qcow2 image on shared storage

virDomainBlockPull to copy all the contents of the local file into the 
shared copy

migrate, now that the domain is no longer tied to the local device

delete the snapshot as it is no longer needed



Also, as I have been implementing the series, I have been playing with 
creating snapshots then reverting to them.  This works reliably (I am 
indeed able to rewind disk state), which means it should not be much 
longer in my series before I am able to implement a <transient/> disk 
property for qemu, which auto-rewinds disk state at domain exit.  That 
is, getting the low-level snapshot support working is a stepping stone 
towards several useful features, even if the feature that you are asking 
for, which is remote access to the actual contents of the snapshot, 
still requires third-party tools at the moment rather than being exposed 
via higher-layer libvirt APIs.

>  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.

>
> 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.

>
> Perhaps I'm missing what adding this API enables.  Please share what
> use case you have in mind.
>
> Stefan
>

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