Re: [Qemu-devel] [Patch for-2.5 v2 5/6] qmp: add monitor command to add/remove a child

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3461 bytes --]

On 09/01/2015 07:25 PM, Wen Congyang wrote:
> On 09/01/2015 11:34 PM, Eric Blake wrote:
>> On 08/31/2015 06:55 PM, Wen Congyang wrote:
>>
>>>>> +This command is still a work in progress. It doesn't support all
>>>>> +block drivers. Stay away from it unless you want it to help with
>>>>> +its development.
>>>>
>>>> Maybe we should name it 'x-child-add' for now, so that we aren't baking
>>>> ourselves into a corner.
>>>
>>> Do you mean the command name should be x-child-add? It is OK.
>>
>> Use of the 'x-' prefix means a command is experimental and may change or
>> be withdrawn.  It gives us a way to test if an interface is useful
>> without committing to that interface long term.  We've still got time
>> before 2.5 to get blockdev-add working everywhere, in which case I think
>> we are better off using blockdev-add to create a new unattached BDS and
>> then have this command pass the node name to be made the new child,
>> rather than all the options for opening the child from scratch.
>>
> 
> Good idea. The unattached BDS created by the command blockdev-add always
> have BB. So it may be used by the device created by the command device_add
> later.

We recently discussed (although the current documentation of
BlockdevOptionsBase sounds like it hasn't been merged yet) the idea of
enhancing blockdev-add to control whether a BB is created alongside a BDS.

Remember, blockdev-add can be used to create a chain.  When originally
implemented, we documented that 'id' must be present on the top of the
chain, and absent everywhere else, and that 'node-name' was optional
everywhere.  The 'id' became associated with the BB at the top level,
and the optional node-names allow you to then manipulate other BDS.  But
the proposal at hand is that we would allow 'id' to be optional at the
top level (at which point 'node-name' is required, because we have to
have SOME way to refer to the BDS); and when that happens, we end up
creating a BDS that is not associated with any BB yet.  Similarly, it is
possible to create a BB that does not yet have a BDS yet (think an empty
cdrom drive); so it then becomes possible to associate a BDS to a BB as
a separate step.

[/me goes searching]
Ah - we are waiting for Max's patches to land:
https://lists.gnu.org/archive/html/qemu-devel/2015-07/msg04201.html
in particular patch 02/38:
https://lists.gnu.org/archive/html/qemu-devel/2015-07/msg04204.html

Once we have that, then we can indeed create a BDS without a BB, and it
is then that you can plug your unconnected BDS into a quorum.  So I'd
recommend helping review Max's series, and base your actions on top of
his (I really do think it is a better approach to separate BDS creation
from chain manipulation, and your add/remove a child is about chain
manipulation and does not need to be creating BDS).

> So I think we should have an API to check it. What about the following
> patches?
> http://lists.nongnu.org/archive/html/qemu-devel/2015-07/msg01591.html
> http://lists.nongnu.org/archive/html/qemu-devel/2015-07/msg01590.html

I haven't looked at them yet, but really like Max's approach for
separating BDS from BB by treating BB without BDS as an empty media
case, and BDS without a BB as something that can then be manipulated to
be associated with another BDS or BB.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]