Re: [PATCH 4/9] qemu: blockjob: Register disk->mirror with a job only when required

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

 



On Wed, Jul 24, 2019 at 17:02:46 -0500, Eric Blake wrote:
> On 7/24/19 4:07 PM, Peter Krempa wrote:
> > Commit job for example references existing storage in the <mirror>
> > subelement thus tracking it separately could lead into problems.
> 
> Grammar is hard to parse, maybe:
> 
> The <mirror> subelement is used in two ways: in a commit job to point to
> existing storage, and in a block-copy job to point to additional
> storage. We need a way to track only the distinct storage.
> 
> > 
> > This patch introduces qemuBlockJobDiskRegisterMirror which registers the
> > mirror chain separately only for job which require it. This also comes
> 
> for jobs which
> 
> > with remembering that in the status XML.
> > 
> > Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx>
> > ---
> 
> > +++ b/src/qemu/qemu_blockjob.c
> > @@ -126,6 +126,9 @@ qemuBlockJobDataNew(qemuBlockJobType type,
> >   *
> >   * This function registers @job with @disk and @vm and records it into the status
> >   * xml (if @savestatus is true).
> > + *
> > + * Note that if @job also references a separate chain e.g. for disk mirroring
> > + * qemuBlockJobDiskRegisterMirror should be used.
> 
> a separate chain, e.g. for disk mirroring, then qemuBlock...
> 
> > +++ b/src/qemu/qemu_domain.c
> > @@ -2367,7 +2367,10 @@ qemuDomainObjPrivateXMLFormatBlockjobIterator(void *payload,
> >      virBufferEscapeString(&childBuf, "<errmsg>%s</errmsg>", job->errmsg);
> > 
> >      if (job->disk) {
> > -        virBufferEscapeString(&childBuf, "<disk dst='%s'/>\n", job->disk->dst);
> > +        virBufferEscapeString(&childBuf, "<disk dst='%s'", job->disk->dst);
> > +        if (job->mirrorChain)
> > +            virBufferAddLit(&childBuf, " mirror='yes'");
> 
> Is there any RNG grammar tweak needed to permit this? Or is the private
> XML block internal only (if the user can never see it via
> virXYZGetXMLDesc, then they have no reason to submit it during
> virXYZCreate, so we have no reason to teach the RNG validation to ignore
> it).

The users can't see it (unless poking into internal files) and for some
weird reason we never implemented RNG for the status XML part.
I ran with it for consistency.

Attachment: signature.asc
Description: PGP signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux