On 07/29/2014 07:03 AM, Peter Krempa wrote:
> On 07/29/14 06:20, Eric Blake wrote:
>> A future patch is going to wire up qemu active block commit jobs;
>> but as they have similar events and are canceled/pivoted in the
>> same way as block copy jobs, it is easiest to track all bookkeeping
>> for the commit job by reusing the <mirror> element. This patch
>> adds domain XML to track which job was responsible for creating a
>> mirroring situation, and adds a job='copy' attribute to all
>> existing uses of <mirror>. Along the way, it also massages the
>> qemu monitor backend to read the new field in order to generate
>> the correct type of libvirt job (even though it requires a
>> future patch to actually cause a qemu event that can be reported
>> as an active commit). It also prepares to update persistent XML
>> to match changes made to live XML when a copy completes.
>>
>> @@ -1025,6 +1026,9 @@ qemuProcessHandleBlockJob(qemuMonitorPtr mon ATTRIBUTE_UNUSED,
>> if (disk) {
>> /* Have to generate two variants of the event for old vs. new
>> * client callbacks */
>> + if (type == VIR_DOMAIN_BLOCK_JOB_TYPE_COMMIT &&
>> + disk->mirrorJob == VIR_DOMAIN_BLOCK_JOB_TYPE_ACTIVE_COMMIT)
>> + type = disk->mirrorJob;
>
> Hmm, looks like this would be better of in the next patch but one of the
> tests probably wouldn't work without this.
Maybe, but then the next commit doesn't look so deceptively simple, and
I _did_ mention it in the commit message :)
>> if (disk->mirrorState == VIR_DOMAIN_DISK_MIRROR_PIVOT) {
>> + if (vm->newDef) {
>> + int indx = virDomainDiskIndexByName(vm->newDef, disk->dst,
>> + false);
>> + if (copy) {
>> + virStorageSourceFree(persistDisk->src);
>> + persistDisk->src = copy;
>> + }
>> + }
>
> Won't this allow us to enable block copy on persistent domains?
It's part of the effort. The other half is actually being able to
restart a blockcopy operation across qemu restarts (not available in
qemu 2.1, it requires a persistent bitmap; but might be available in
qemu 2.2). The reason that active commit can be done on a persistent
domain is that you don't lose progress - if you spend 4 minutes getting
80% of the way, then the guest shuts down, then you restart qemu and
restart the commit operation, then you only need 1 more minute for the
remaining 20%. That is, aborting a commit job is not expensive. On the
other hand, aborting a copy job at 80% progress, and then starting a new
one, will end up copying all 100% of the file (5 more minutes, for a
total of 9 instead of 5), because without a persistent bitmap, qemu
loses track of how much of the copy has already been made. So for now,
I'm still going to require transient domain for blockcopy.
That, and I _really_ need a new API that lets you target a <disk> XML
element as the copy destination (I ran out of time for 1.2.7, but 1.2.8
is looking good). Plus we need a way to expose qemu's drive-backup
operation; the existing blockcopy code is crammed into
virDomainBlockRebase where we don't have good exposure for pre- vs.
post- snapshot; but a new virDomainBlockCopy() with an XML destination
and proper flags would be better for it. For those less familiar with
the difference between the two qemu commands, here's a timeline:
A B C
+----------------------------------------------------------
^ ^ ^
request drive-mirror | |
sync ready
request complete/pivot
the copy taken by drive-mirror is consistent at point C, which may be
several minutes after the user actually requested the copy. So whatever
the guest saw at point A may be long gone by the time the copy is
actually finalized; planning for user point-in-time snapshots requires
forethought to actually get a mirror up and running long before the user
has a need for the snapshot. However, with that planning, the time
between declaring the snapshot complete and actually having the snapshot
to work with is nearly instant.
A B
+------------------------------------------
^ ^
request drive-backup |
backup complete
the copy taken by drive-backup is not consistent until point B, but its
contents match what the guest saw at point A. This is much nicer for
point-in-time semantics, although it does mean that the user has to wait
from the time they requested a backup until it is actually ready for
them to use.
>
> ACK, although this patch an the next one are a bit borderline now that
> libvirt is frozen for the next release.
I'll wait for a third-party opinion, then (maybe DV or danpb will weigh
in before DV tries to cut rc2 in the next 24 hours...)
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list