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

Re: [libvirt] RFC: mirrored live block migration in libvirt 0.9.11

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.
> 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. :)


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