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
signature.asc
Description: OpenPGP digital signature