qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-block] [PATCH v4 for-2.11] QAPI & interop: Clarif


From: Kevin Wolf
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v4 for-2.11] QAPI & interop: Clarify events emitted by 'block-job-cancel'
Date: Mon, 27 Nov 2017 12:50:00 +0100
User-agent: Mutt/1.9.1 (2017-09-22)

Am 21.11.2017 um 10:58 hat Kashyap Chamarthy geschrieben:
> On Fri, Nov 17, 2017 at 07:54:44PM +0100, Kashyap Chamarthy wrote:
> > +So there are two possible actions to take, after a 'mirror' job has
> > +emitted the event ``BLOCK_JOB_READY``, indicating that the source and
> > +target have reached synchronization:
> > +
> > +(1) Issuing the command ``block-job-cancel`` (after it emits the event
> > +    ``BLOCK_JOB_COMPLETED``) will create a point-in-time (which is at
> > +    the time of *triggering* the cancel command) copy of the entire disk
> >      image chain (or only the top-most image, depending on the ``sync``
> > -    mode).
> > +    mode), contained in the target image [E].
> >  
> > -(2) Issuing the command ``block-job-complete`` after it emits the event
> > -    ``BLOCK_JOB_COMPLETED``: will, after completing synchronization of
> > -    the content, adjust the guest device (i.e. live QEMU) to point to
> > -    the target image, and, causing all the new writes from this point on
> > -    to happen there.  One use case for this is live storage migration.
> > +(2) Issuing the command ``block-job-complete`` (after it emits the event
> > +    ``BLOCK_JOB_COMPLETED``) will adjust the guest device (i.e. live
> > +    QEMU) to point to the target image, [E], causing all the new writes
> > +    from this point on to happen there.  One use case for this is live
> > +    storage migration.
> 
> Dave Gilbert pointed out on IRC that last sentence ("One use case for
> this is live storage migration") should apply to point (1) above.  He's
> right, I'll send a v5 with that (and the commit message tweak I noted
> earlier) fix.

This depends completely on what you mean by "live storage migration".
We've never been able to find a non-confusing terminology there.

What Dave is thinking of is probably "live VM migration with non-shared
storage". What the comment implied was probably "move an image somewhere
else while keeping the VM running where it is".

Maybe the best option would be to completely remove this sentence
instead of moving it to (1) where it's still ambiguous.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]