On 08/23/2011 09:35 AM, Stefan Hajnoczi wrote:
On Tue, Aug 23, 2011 at 4:18 PM, Eric Blake<eblake@xxxxxxxxxx> 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@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list