From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33526) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNnZa-0001Tz-SF for qemu-devel@nongnu.org; Tue, 17 Feb 2015 14:12:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YNnZW-0008JI-RJ for qemu-devel@nongnu.org; Tue, 17 Feb 2015 14:12:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33395) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNnZW-0008JA-Ku for qemu-devel@nongnu.org; Tue, 17 Feb 2015 14:12:38 -0500 Message-ID: <54E392A1.5030604@redhat.com> Date: Tue, 17 Feb 2015 12:12:33 -0700 From: Eric Blake MIME-Version: 1.0 References: <1422356197-5285-1-git-send-email-vsementsov@parallels.com> <1422356197-5285-9-git-send-email-vsementsov@parallels.com> <54DA793C.9020707@redhat.com> <54DDB398.3010907@parallels.com> <54DE5D0F.5080304@redhat.com> <54E1DD49.3050102@parallels.com> <54E23477.9040801@redhat.com> <54E301CD.9070806@parallels.com> <54E38C4B.5040702@redhat.com> In-Reply-To: <54E38C4B.5040702@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fMBWPuNH1bjh0Acrvlt5qkpUvNVUIU0on" Subject: Re: [Qemu-devel] [PATCH RFC v2 8/8] migration: add migration/dirty-bitmap.c List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow , Vladimir Sementsov-Ogievskiy , qemu-devel@nongnu.org Cc: kwolf@redhat.com, Peter Maydell , "Juan quin >> Juan Jose Quintela Carreira" , "Dr. David Alan Gilbert" , stefanha@redhat.com, pbonzini@redhat.com, amit Shah , den@openvz.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fMBWPuNH1bjh0Acrvlt5qkpUvNVUIU0on Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/17/2015 11:45 AM, John Snow wrote: >>> >> Hmm.. No? bitmap is attached using bdrv_lookup_bs(name, name, errp), >> which can find device with this name. qemu option -drive >> file=3D...,id=3Ddisk creates blk named 'disk' and attached node with n= o name. >> >> >=20 > Very good point -- We use the device name as a convenience shortcut to > the first node. So the node a bitmap is attached to might in fact not > have a name. Or, if we revisit Jeff's proposal to always auto-name every node, then you'd never have a node without a name. Ultimately, libvirt should be using named nodes, but we're not there yet. >=20 > I see what you mean. >=20 > Hmm. So you propose, on the sending side: >=20 > (1) Use this node's name, if available > (2) Fall back to the backend/"device" name, if present, > (3) Do not send the bitmap if neither names are present (THIS scenario > should be impossible to achieve and should trigger an error.) Seems okay to me. >=20 > What about on the receiving end? To which node(s) do we attach the > bitmap? I assume: >=20 > (1) Try to find a node with this name and attach it there, > (2) Fall back to attaching it to the root node of a device/BB with this= > name > (3) If neither are present, abort. >=20 That would also work. Since node names and device names share the same namespace, it should always resolve to the correct node. > Is that right? If so, it sounds serviceable to me, but keep in mind tha= t > bdrv_lookup_bs() on the receiving end will default to #2 first before #= 1. Except that if a device is named "foo", then no node has that name, so it is unambiguous that you meant the node attached to device "foo". >=20 > Overall, this makes the migration very "fuzzy" in terms of which bitmap= s > will go where, and the onus is really on the user (or management tool) > to keep trees compatibly similar for the purposes of bitmap migration. >=20 > I still wonder if making the exportation of names more explicit in term= s > of a flag ("this name is a node-name", "this name is a backend-name") > might still be of use for providing more rigid and knowable migration > semantics. >=20 > Might as well go ahead with your suggestion for now, and we'll see if > anyone from migration or libvirt groups has a reason not to do it that > way. I don't have any concrete reasons. >=20 > --js >=20 >=20 >=20 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --fMBWPuNH1bjh0Acrvlt5qkpUvNVUIU0on 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/ iQEcBAEBCAAGBQJU45KhAAoJEKeha0olJ0Nq88QIAJ/fhw01JevEu1a07a5ubFFp jv0VWNEBx08x0XAAQlqUOqvUfnA7pB5wgFVMxEzZFwvJn2xGJEFdBrszcs2arvDn 9tHH2IgMko9s5v7uv3By2HbcyakZnJVfObWTcNUIXOkoa1xUqdLwHeqrEHLRbBFu PxpFlBapcWqdpSGej/VzTPqPP9WdocPh309w2lY9vNC0qn3if2OTpr9XFNkp6eGL GA9rGGkWjtVmkpg/zahMq9diA+dVoRmfrQpKRRp9K5IPjKRKAmOPhdtB/gs5P0Hi p+VEJ8wZMYp8KieRHEqKpnOpAGtWmDFP7pjKnqiYl63lo5KGpAlniQ0tnPCh14M= =91pc -----END PGP SIGNATURE----- --fMBWPuNH1bjh0Acrvlt5qkpUvNVUIU0on--