From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38257) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWlmO-0004vN-8t for qemu-devel@nongnu.org; Fri, 19 Feb 2016 09:11:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWlmN-0003KJ-9t for qemu-devel@nongnu.org; Fri, 19 Feb 2016 09:11:32 -0500 Sender: Paolo Bonzini 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> From: Paolo Bonzini Message-ID: <56C72286.4040508@redhat.com> Date: Fri, 19 Feb 2016 15:11:18 +0100 MIME-Version: 1.0 In-Reply-To: <20160219134756.GD5228@noname.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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: Kevin Wolf , Laurent Vivier Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org 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. 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... Paolo