From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44873) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJMN1-00005I-6v for qemu-devel@nongnu.org; Wed, 13 Jan 2016 09:25:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJMN0-0005pD-4D for qemu-devel@nongnu.org; Wed, 13 Jan 2016 09:25:55 -0500 Date: Wed, 13 Jan 2016 15:25:45 +0100 From: Kevin Wolf Message-ID: <20160113142545.GB4356@noname.redhat.com> References: <1450802786-20893-1-git-send-email-kwolf@redhat.com> <1450802786-20893-6-git-send-email-kwolf@redhat.com> <5679B5DE.5070205@redhat.com> <568C25CB.7050808@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <568C25CB.7050808@redhat.com> Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 05/10] block: Inactivate BDS when migration completes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, mreitz@redhat.com 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