On 08/23/2011 03:52 AM, Stefan Hajnoczi wrote:
On Wed, Aug 10, 2011 at 11:08 PM, Eric Blake<ebl...@redhat.com> wrote:
disk snapshot: the state of a virtual disk used at a given time; once a
snapshot exists, then it is possible to track a delta of changes that have
happened since that time.
Did you go into details of the delta API anywhere? I don't see it.
It's not available yet, because qemu doesn't provide anything yet. I
think that APIs to inspect the actual delta disk contents between the
current state and a prior snapshot will be similar to block pull, but we
can't implement anything without support from the underlying tools.
My general feedback is that you are trying to map all supported
semantics which becomes very complex. However, I'm a little concerned
that this API will require users to become experts in
snapshots/checkpoints. You've mentioned quite a few exceptions where
a force flag is needed or other action is required. Does it make
sense to cut this down to a common abstraction that mortals can use?
Hopefully I'm making the error messages specific enough in the cases
where a revert is rejected but would succeed with a force flag. And as
I haven't actually implemented the force flag yet, I may still end up
tweaking things a bit compared to the original RFC when I actually get
into coding things.
Regarding LVM, btrfs, etc support: eventually it would be nice to
support these storage systems as well as storage appliances (various
SAN and NAS boxes that have their own APIs). If you lay down an
interface that must be implemented in order to enable snapshots on a
given storage system, then others can contribute the actual drivers
for storage systems they care about.
Yes, there's still quite a bit of refactoring to be done to move the
snapshot work out of the qemu driver an into the storage volume driver,
with enough of an expressive interface that the qemu driver can then
make several calls to probe the snapshot capabilities of each storage
volume. But one step at a time, and the first thing to get working is
proving that the xml changes are sufficient for qemu to do qcow2
snapshots, and that the xml remains flexible enough to later extend (it
isn't locking us into a qcow2-only solution).
--
Eric Blake ebl...@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
