From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39670) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWlsJ-00012X-K8 for qemu-devel@nongnu.org; Fri, 19 Feb 2016 09:17:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWlsI-0004kv-M8 for qemu-devel@nongnu.org; Fri, 19 Feb 2016 09:17:39 -0500 Date: Fri, 19 Feb 2016 15:17:31 +0100 From: Kevin Wolf Message-ID: <20160219141731.GE5228@noname.redhat.com> References: <1453307106-28330-1-git-send-email-kwolf@redhat.com> <1453307106-28330-9-git-send-email-kwolf@redhat.com> <56C5EB3A.90303@redhat.com> <20160219091748.GB5228@noname.redhat.com> <56C6F04F.1080403@redhat.com> <20160219134756.GD5228@noname.redhat.com> <56C72286.4040508@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56C72286.4040508@redhat.com> Subject: Re: [Qemu-devel] [PULL 08/17] block: Assert no write requests under BDRV_O_INCOMING List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Laurent Vivier , qemu-devel@nongnu.org, qemu-block@nongnu.org Am 19.02.2016 um 15:11 hat Paolo Bonzini geschrieben: > On 19/02/2016 14:47, Kevin Wolf wrote: > > > The problem seems coming from "snapshot=on". > > Aha. The combination of migration with snapshot=on is obvious nonsense > > (because on the destination the disk state would be reverted while the > > guest OS thinks the disk is unchanged), > > Not really, on the destination the disk state will not be _further > updated_, but no reversion happens. Right, I started writing a patch when I noticed that that wasn't quite right and -snapshot on the destination is somewhat unusual, but not in all cases wrong. > Migration with "snapshot=on" makes sense if you are resuming a VM from a > saved checkpoint ("-incoming exec"). You can use it to debug a > migration load, for example, because you want the resumed guest to > always start with the same disk contents. It's somewhat weird, but it > definitely has its uses. A blocker would be a pain in the ass... My other thinko was that a blocker would help. In reality, blockers are on the source host. They would make a little more sense than forbidding -snapshot with -incoming, but we don't know how you migrate storage. If you don't use shared storage but mirroring, then it could be okay again (but probably even weirder than the other case). Kevin