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

Re: [libvirt] RFCv2: virDomainSnapshotCreateXML enhancements

On 08/23/2011 03:52 AM, Stefan Hajnoczi wrote:
On Wed, Aug 10, 2011 at 11:08 PM, Eric Blake<eblake 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   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]