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).

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