Re: [Qemu-devel] [PATCH 04/21] block: Add bdrv_close_all() handlers

[Max Reitz <mreitz@redhat.com>]

On 2015-01-28 at 17:05, Eric Blake wrote:
> On 01/26/2015 02:22 PM, Paolo Bonzini wrote:
>>
>> On 26/01/2015 22:13, Max Reitz wrote:
>>>> An eject blocker would also break backwards-compatibility though.  What
>>>> about an eject notifier?  Would that concept make sense?
>>> It does make sense (in that it is the way I would implement "just do
>>> what we always did"), but I just don't like it for the fact that it
>>> makes NBD a special snowflake. I can live with it, though.
>> Yes, it's weird.  But this is just the backwards-compatible solution.
>>
>> I'm okay with implementing only the new solution, but:
>>
>> - the old QMP (and HMP?) commands must be removed
> Back-compat is a bear to figure out. From libvirt's perspective, it is
> okay to require a newer libvirt in order to drive newer qemu (the new
> libvirt knowing how to probe whether old or new commands exist, and use
> the right one); but it is still awkward any time upgrading qemu without
> libvirt causes things to break gratuitously.
>
>> - the new command probably must not reuse the same BB as the guest, and
>> I am not sure that this is possible.
> We've had that design goal in the back of our minds for some time
> (sharing a single BDS among multiple devices) - but I don't think it has
> actually happened yet, so if this is the first time we make it happen,
> there may be lots of details to get right.  But it makes the most sense
> (exporting and NBD disk is a form of creating a _new_ BB - distinct from
> a guest-visible device, but both uses are definitely backends; and
> sharing the same BDS among both backends makes total sense, so that the
> drive visible to the guest can change medium without invalidating the
> NBD serving up the old contents).

Well, I've looked up the discussion Markus, Kevin and me were having; 
our result was that some users may find it useful to have an own BB for 
an NBD server, while others may want to re-use an existing BB. The 
former would be requested by creating an NBD server on a node-name 
instead of giving a device name; if given a device name, NBD will reuse 
that BB, and will detach itself on eject.

Somehow I lost track of that final detail (I blame Christmas and New 
Year), so that's indeed what we decided upon. I will implement it in v2 
(an eject notifier for BBs, which is then used by NBD).

For the sake of completeness: Currently, it is impossible to have 
multiple BBs per BDS, so we cannot yet implement having a separate BB 
for the NBD server. This issue is however unrelated to this series, so 
we should be fine for now.

Max