Il 14/03/2012 10:38, Eric Blake ha scritto:
2) in case the snapshotting is aborted early for any reason, oVirt has to do a rebase operation manually. This is currently O(size-of-disk), not O(changes-in-the-last-image), so it wastes both disk space and time.
I don't follow the argument for this. It may be a valid complaint, but I'm not yet seeing why you think oVirt has to do a rebase operation manually, or why that operation will cost O(disk) rather than O(changes). If I have:
base <- snap1
and request a snapshot that mirrors to snap2 in two locations, but abort half-way through, then I can just call virDomainSnapshotDelete(VIR_DOMAIN_SNAPSHOT_DELETE_METADATA) which makes libvirt forget that it attempted to take a snapshot, but without losing the XML that says that the disk is now based on snap2. That means restarting the domain would use:
base <- snap1 <- snap2
as its backing file, and virDomainBlockRebase can be used to initiate a 'block_stream' to collapse it back to a shorter backing chain.
Yeah, but that's O(changes in snap1), not O(changes in snap2). In the worst case it's O(changes in base).
virDomainBlockCopy(dom, "disk", "/dst/disk.img", "/src/base.img", bandwidth, flags)
Yes, a new API would ultimately be nicer, [...] but it goes against my stated goal of implementing a first-cut working solution for oVirt that [...] doesn't require a .so bump
I think you also need VIR_DOMAIN_SNAPSHOT_DELETE_REMOVE_MIRROR, to be used in case of abort so that the domain can actually be started. Or it could be an event MIRROR_DROPPED or something like that.
Good call. VIR_DOMAIN_SNAPSHOT_DELETE_METADATA_ONLY says to drop libvirt's notion of the snapshot object, but it won't stop qemu from mirroring; so an additional flag that tells libvirt to 'drive-reopen' back to the source to discard any mirroring would be handy. [...] it does point out that I should probably either prevent the use of a <domainsnapshot> with <mirror> on persistent domains
Yes, that makes sense. And perhaps do that downstream only. :) Paolo