[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] RFCv2: virDomainSnapshotCreateXML enhancements

On 08/23/2011 09:35 AM, Stefan Hajnoczi wrote:
On Tue, Aug 23, 2011 at 4:18 PM, Eric Blake<eblake 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.

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.


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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]