From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43950) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9Ltb-0000sX-EC for qemu-devel@nongnu.org; Thu, 08 Jan 2015 17:49:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y9LtX-0007M4-3b for qemu-devel@nongnu.org; Thu, 08 Jan 2015 17:49:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42692) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9LtW-0007Lx-RT for qemu-devel@nongnu.org; Thu, 08 Jan 2015 17:49:35 -0500 Message-ID: <54AF0978.2070705@redhat.com> Date: Thu, 08 Jan 2015 23:49:28 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1418307457-25996-1-git-send-email-vsementsov@parallels.com> <1418307457-25996-10-git-send-email-vsementsov@parallels.com> <54AF0662.7050303@redhat.com> <54AF086D.7000106@redhat.com> In-Reply-To: <54AF086D.7000106@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 9/9] block-migration: add named dirty bitmaps migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , Vladimir Sementsov-Ogievskiy , qemu-devel@nongnu.org Cc: kwolf@redhat.com, den@openvz.org, jsnow@redhat.com, stefanha@redhat.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/01/2015 23:45, Eric Blake wrote: >>> The bitmaps are transmitted many times in their entirety, but >>> only the last copy actually means something. The others are >>> lost. This means you should use the non-live interface >>> (register_savevm). This will simplify the code a lot. > If I understand correctly, you are saying that: > > block migration vs. assuming shared storage during migration > > is independent from: > > current behavior of resetting dirty tracking on destination vs. > new one-shot non-live dirty bitmap migration > > and that all four combinations are potentially useful. Yes. For example, you could use drive-mirror to snoop writes to an NBD destination (e.g. to a malware scanner or to a secondary machine if you have fault tolerance). Then you need to migrate the dirty bitmap even if you have shared storage. > Also, by doing dirty bitmap migration as one-shot at the tail end > of migration (in the small window when things are no longer live) > you have a lot less effort, although the window of non-live > activity is now a bit longer if the dirty table migration is not > efficient. As of this series, dirty bitmap migration is not attempting to track the dirtiness of the dirty bitmap itself (you might have to read that twice :)). So there's nothing to lose in terms of efficiency. Paolo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUrwlwAAoJEL/70l94x66DSN4H+gLqqkghOqdkPzduTmf1hzi1 pwLe/TGZv+gNNWu8G2hO2FfasMlmBxEOVtwODFcwGExvPnH2jv1N7/dplIwKqbLS g9Hq5cI3UagxfFQts7fyBhjCxeUrHuaKfIvc/A1kfMMwesn8PPGFUGEXNqIs1NGc I+3qTE5TlcOKWCfL+3zgLDUowvRACbTJngHfveOtoWscVz743yQxhH3NOKPu7jxR 8H5AC9TK7sr3azHrXFgMP53W2qHT0KHTUyLQem+iKagFLsxX6oyOEn0ueMooAndE tzvw+5EiFj8MfAzPAdQWEPYwxQyDBy/oXQizQTCmAQku2TZIlWi+kStJ3K/qEaM= =v5Gj -----END PGP SIGNATURE-----