Re: [Qemu-devel] [PATCH RFC v2 8/8] migration: add migration/dirty-bitmap.c

[John Snow <jsnow@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