4:01 p.m.
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