Re: [Qemu-devel] [Qemu-block] [PATCH 05/10] block: Inactivate BDS when migration completes

[Kevin Wolf]

Am 05.01.2016 um 21:21 hat John Snow geschrieben:
> 
> 
> On 12/22/2015 03:43 PM, Eric Blake wrote:
> > On 12/22/2015 09:46 AM, Kevin Wolf wrote:
> >> So far, live migration with shared storage meant that the image is in a
> >> not-really-ready don't-touch-me state on the destination while the
> >> source is still actively using it, but after completing the migration,
> >> the image was fully opened on both sides. This is bad.
> >>
> >> This patch adds a block driver callback to inactivate images on the
> >> source before completing the migration. Inactivation means that it goes
> >> to a state as if it was just live migrated to the qemu instance on the
> >> source (i.e. BDRV_O_INCOMING is set). You're then supposed to continue
> >> either on the source or on the destination, which takes ownership of the
> >> image.
> >>
> >> A typical migration looks like this now with respect to disk images:
> >>
> >> 1. Destination qemu is started, the image is opened with
> >>    BDRV_O_INCOMING. The image is fully opened on the source.
> >>
> >> 2. Migration is about to complete. The source flushes the image and
> >>    inactivates it. Now both sides have the image opened with
> >>    BDRV_O_INCOMING and are expecting the other side to still modify it.
> > 
> > The name BDRV_O_INCOMING now doesn't quite match semantics on the
> > source, but I don't have any better suggestions.  BDRV_O_LIMITED_USE?
> > BDRV_O_HANDOFF?  At any rate, I fully agree with your logic of locking
> > things down on the source to mark that the destination is about to take
> > over write access to the file.
> > 
> 
> INCOMING is handy as it keeps the code simple, even if it's weird to
> read. Is it worth adding the extra ifs/case statements everywhere to add
> in BDRV_O_HANDOFF? Maybe in the future someone will use BDRV_O_INCOMING
> to mean something more specific (data is incoming, not just in the
> process of being handed off) that could cause problems.
> 
> Maybe even just renaming BDRV_O_INCOMING right now to be BDRV_O_HANDOFF
> would accomplish the semantics we want on both source and destination
> without needing two flags.
> 
> Follow your dreams, Go with what you feel.

How about renaming BDRV_O_INCOMING to BDRV_O_INACTIVE?

Kevin