From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNn9X-0003GP-L7 for qemu-devel@nongnu.org; Tue, 17 Feb 2015 13:45:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YNn9Q-0006Rt-3Q for qemu-devel@nongnu.org; Tue, 17 Feb 2015 13:45:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36386) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNn9P-0006RG-Rk for qemu-devel@nongnu.org; Tue, 17 Feb 2015 13:45:40 -0500 Message-ID: <54E38C4B.5040702@redhat.com> Date: Tue, 17 Feb 2015 13:45:31 -0500 From: John Snow 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> In-Reply-To: <54E301CD.9070806@parallels.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: 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, den@openvz.org, amit Shah , pbonzini@redhat.com On 02/17/2015 03:54 AM, Vladimir Sementsov-Ogievskiy wrote: > On 16.02.2015 21:18, John Snow wrote: >> >> >> On 02/16/2015 07:06 AM, Vladimir Sementsov-Ogievskiy wrote: >>> On 13.02.2015 23:22, John Snow wrote: >>>> >>>> >>>> On 02/13/2015 03:19 AM, Vladimir Sementsov-Ogievskiy wrote: >>>>> On 11.02.2015 00:33, John Snow wrote: > >>>>> So in summary: >>>>> using device names is probably fine for now, as it matches the current >>>>> use case of bitmaps as well as drive migration; but using node names >>>>> may give us more power and precision later. >>>>> >>>>> I talked to Max about it, and he is leaning towards using device names >>>>> for now and switching to node names if we decide we want that power. >>>>> >>>>> (...I wonder if we could use a flag, for now, that says we're >>>>> including DEVICE names. Later, we could add a flag that says we're >>>>> using NODE names and add an option to toggle as the usage case sees >>>>> fit.) >>>>> >>>>> >>>>> Are you confused yet? :D >>> O, thanks for the explanation). Are we really need this flag? As Markus >>> wrote, nodes and devices are sharing namespaces.. We can use >>> bdrv_lookup_bs(name, name, errp).. >> >> what 'name' are you using here, though? It looked to me like in your >> backup routine we got a list of BDS entries and get the name *from* >> the BDS, so we still have to think about how we want to /get/ the name. >> >>> >>> Also, we can, for example, send bitmaps as follows: >>> >>> if node has name - send bitmap with this name >>> if node is root, but hasn't name - send it with blk name >>> otherwise - don't send the bitmap >> >> The node a bitmap is attached to should always have a name -- it would >> not be possible via the existing interface to attach it to a node >> without a name. >> >> I *think* the root node should always have a name, but I am actually >> less sure of that. >> > Hmm.. No? bitmap is attached using bdrv_lookup_bs(name, name, errp), > which can find device with this name. qemu option -drive > file=...,id=disk creates blk named 'disk' and attached node with no name. > > 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. I see what you mean. Hmm. So you propose, on the sending side: (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.) What about on the receiving end? To which node(s) do we attach the bitmap? I assume: (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. Is that right? If so, it sounds serviceable to me, but keep in mind that bdrv_lookup_bs() on the receiving end will default to #2 first before #1. Overall, this makes the migration very "fuzzy" in terms of which bitmaps 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. I still wonder if making the exportation of names more explicit in terms 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. 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. --js