From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59188) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fHFW2-00028a-4O for qemu-devel@nongnu.org; Fri, 11 May 2018 17:23:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fHFW1-000855-3o for qemu-devel@nongnu.org; Fri, 11 May 2018 17:23:49 -0400 References: <8739e95e-1900-d4e3-7ac8-77e3aa8b927e@virtuozzo.com> From: John Snow Message-ID: <3828666d-c929-de15-9160-4089d237d323@redhat.com> Date: Fri, 11 May 2018 17:23:39 -0400 MIME-Version: 1.0 In-Reply-To: <8739e95e-1900-d4e3-7ac8-77e3aa8b927e@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Restoring bitmaps after failed/cancelled migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladimir Sementsov-Ogievskiy , qemu-devel , qemu block , Kevin Wolf , Max Reitz , Fam Zheng , "gilbert >> Dr. David Alan Gilbert" , "Juan Q >> Juan Jose Quintela Carreira" On 04/18/2018 10:00 AM, Vladimir Sementsov-Ogievskiy wrote: > Hi all. > > We now have the following problem: > > If dirty-bitmaps migration capability is enabled, persistance flag is > dropped for all migrated bitmaps, to prevent their storing to the > storage on inactivate. It works ok, persistence itself is migrated > through the migration channel. But on source, bitmaps becomes not > persistent, so if we, for some reasons, want to continue using source > vm, we'll lose bitmaps on stop/start. > Sorry for not following along more carefully, which kind of migration are we talking about in this case? > It's simple to fix it: just make bitmaps persistent again on invalidate > [1].. But I have some questions. > > 1. What are possible cases? I think about the following: > > a. migration cancel or fail, then invalidate > b. migration success, then qmp cont => invalidate > c. migration success, then stop/start (there was no invalidate, so [1] > will not work) > > > 2. Is it safe at all, saving bitmaps after inactivate, even without > persistence? > > Inactive disk implies, that it may be changed by somebody other, isn't > it? Is it possible, that target will change the disk, and then we return > control to the source? In this case bitmaps will be invalid. So, should > not we drop all the bitmaps on inactivate? >