From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59303) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxGA1-0000SL-3G for qemu-devel@nongnu.org; Tue, 26 May 2015 10:48:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YxG9w-0002JP-CY for qemu-devel@nongnu.org; Tue, 26 May 2015 10:48:53 -0400 Received: from relay.parallels.com ([195.214.232.42]:48374) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxG9w-0002Is-3U for qemu-devel@nongnu.org; Tue, 26 May 2015 10:48:48 -0400 Message-ID: <556487BF.2000809@openvz.org> Date: Tue, 26 May 2015 17:48:31 +0300 From: "Denis V. Lunev" MIME-Version: 1.0 References: <1431531007-10269-1-git-send-email-vsementsov@parallels.com> <555DE2D7.2020200@parallels.com> <555DE431.60703@openvz.org> <555E0B5D.5060302@redhat.com> In-Reply-To: <555E0B5D.5060302@redhat.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 00/12] Dirty bitmaps migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow , dgilbert@redhat.com Cc: kwolf@redhat.com, peter.maydell@linaro.org, quintela@redhat.com, qemu-devel@nongnu.org, Vladimir Sementsov-Ogievskiy , stefanha@redhat.com, amit.shah@redhat.com, pbonzini@redhat.com On 21/05/15 19:44, John Snow wrote: > > On 05/21/2015 09:57 AM, Denis V. Lunev wrote: >> On 21/05/15 16:51, Vladimir Sementsov-Ogievskiy wrote: >>> Hi all. >>> >>> Hmm. There is an interesting suggestion from Denis Lunev (in CC) about >>> how to drop meta bitmaps and make things easer. >>> >>> method: >>> >>>> start migration >>> disk and memory are migrated, but not dirty bitmaps. >>>> stop vm >>> create all necessary bitmaps in destination vm (empty, but with same >>> names and granularities and enabled flag) >>>> start destination vm >>> empty bitmaps are tracking now >>>> start migrating dirty bitmaps. merge them to corresponding bitmaps >>> in destination >>> while bitmaps are migrating, they should be in some kind of >>> 'inconsistent' state. >>> so, we can't start backup or other migration while bitmaps are >>> migrating, but vm is already _running_ on destination. >>> >>> what do you think about it? >>> >> the description is a bit incorrect >> >> - start migration process, perform memory and disk migration >> as usual. VM is still executed at source >> - start VM on target. VM on source should be on pause as usual, >> do not finish migration process. Running VM on target "writes" >> normally setting dirty bits as usual >> - copy active dirty bitmaps from source to target. This is safe >> as VM on source is not running >> - "OR" copied bitmaps with ones running on target >> - finish migration process (stop source VM). >> >> Downtime will not be increased due to dirty bitmaps with this >> approach, migration process is very simple - plain data copy. >> >> Regards, >> Den >> > I was actually just discussing the live migration approach a little bit > ago with Stefan, trying to decide on the "right" packet format (The only > two patches I haven't ACKed yet are ones in which we need to choose a > send size) and we decided that 1KiB chunk sends would be appropriate for > live migration. > > I think I'm okay with that method, but obviously this approach outlined > here would also work very well and would avoid meta bitmaps, chunk > sizes, migration tuning, convergence questions, etc etc etc. > > You'd need to add a new status to the bitmap on the target (maybe > "INCOMPLETE" or "MIGRATING") that prevents it from being used for a > backup operation without preventing it from recording new writes. > > My only concern is how easy it will be to work this into the migration > workflow. > > It would require some sort of "post-migration" ternary phase, I suppose, > for devices/data that can be transferred after the VM starts -- and I > suspect we'll be the only use of that phase for now. > > David, what are your thoughts, here? Would you prefer Vladimir and I > push forward on the live migration approach, or add a new post-hoc > phase? This approach might be simpler on the block layer, but I would be > rather upset if he scrapped his entire series for the second time for > another approach that also didn't get accepted. > > --js hmmm.... It looks like we should proceed with this to fit 2.4 dates. There is not much interest at the moment. I think that we could implement this later in 2.5 etc... Regards, Den