From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43087) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9LpD-0007zL-DC for qemu-devel@nongnu.org; Thu, 08 Jan 2015 17:45:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y9Lp9-00058T-6Y for qemu-devel@nongnu.org; Thu, 08 Jan 2015 17:45:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60983) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9Lp8-00057Y-VT for qemu-devel@nongnu.org; Thu, 08 Jan 2015 17:45:03 -0500 Message-ID: <54AF086D.7000106@redhat.com> Date: Thu, 08 Jan 2015 15:45:01 -0700 From: Eric Blake 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> In-Reply-To: <54AF0662.7050303@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RdoaI2Qu5sGXl3vMVPSpLAocgcgIQFk89" 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: Paolo Bonzini , Vladimir Sementsov-Ogievskiy , qemu-devel@nongnu.org Cc: kwolf@redhat.com, den@openvz.org, jsnow@redhat.com, stefanha@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RdoaI2Qu5sGXl3vMVPSpLAocgcgIQFk89 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/08/2015 03:36 PM, Paolo Bonzini wrote: >=20 >=20 > On 11/12/2014 15:17, Vladimir Sementsov-Ogievskiy wrote: >> Just migrate parts of dirty bitmaps, corresponding to the block being >> migrated. Also, skip block migration if it is disabled (blk parameter >> of migrate command is false). >> >> Skipping shared sectors: bitmaps are migrated independently of this, >> just send blk without block data. >=20 > I think dirty bitmaps should be migrated separately from the block > migration. It makes a lot of sense to migrate them even if you are not= > using block migration. >=20 > Compared to new flags, the availability of migration capabilities can b= e > queried via query-migrate-capabilities before actually invoking the > migration. So they are preferred, and you should add a migration > capability instead of a new argument. Good point - we still don't have argument introspection (only command introspection), so turning on bitmap migration with a capability is indeed preferable over having to probe whether attempting an optional parameter will induce failure. >=20 > 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. 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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --RdoaI2Qu5sGXl3vMVPSpLAocgcgIQFk89 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJUrwhtAAoJEKeha0olJ0Nqk2EIAKqZ9nwD2PVjtzILRgqtdxdd DopcAMbiQPZtMtVJtW4M7vrcQTwBoDqUHHeu9xfWqCIHpMIKcQ1zge8uX+rh6kOO TLswY08NjSNi4T1+RQUFX9YhtUOrYAntfa1llp8P+bMRh0mYo+bkI10nL0odX6R3 3m92nL6rY7zHzNSIASs1ljgusWcfIg/+Z67x6TNj8oB20gU06NakZ116XsMSHC5c Ulm08IjlJ1U34Uq8osmiWlqdOMyYAzBW2ZtCuVDhhY1N+7n6QSnHJSLn9XLsABZg NUz+Jg116PS8RrhHnPJnmLoP3+EtXEKaTjyoJ0h9GMn9mdE8SKXOt9qyF/568O4= =LInc -----END PGP SIGNATURE----- --RdoaI2Qu5sGXl3vMVPSpLAocgcgIQFk89--