Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs

[Eric Blake]

On 04/03/2017 07:39 AM, Max Reitz wrote:
>>> As for just allowing the NBD server write access to the device... To me
>>> that appears pretty difficult from an implementation perspective. We
>>> assert that nobody can write without having requested write access and
>>> we make sure that nobody can request write access without it being
>>> allowed. Making an exception for NBD seems very difficult and would
>>> probably mean we'd have to drop the assertion for write accesses altogether.
>>
>> Making an exception would simply be wrong.
> 
> Indeed. That is why it would be so difficult.
> 
> The question remains whether it is practical not to make an exception.
> As far as I know, libvirt is only guaranteed to support older qemu
> versions, not necessarily future ones. So we should be allowed to break
> existing use cases here until libvirt is updated (assuming it is
> possible for libvirt to express "guest device allows shared writes" as
> an option for its next release).

In general, we support:

old qemu, old libvirt (well, as long as those versions are supported)
old qemu, new libvirt
new qemu, new libvirt

but we do NOT make any guarantees of supporting

new qemu, old libvirt

In other words, this may be a failure where new qemu requires extra care
and thus a new libvirt for it to be useful.  It's not nice to break qemu
back-compat if any other solution is possible (new qemu and old libvirt
should work more often than not), but it is the one scenario that no one
supports (whether here, upstream libvirt, or in downstream backports).

Or, put another way, it's perfectly fine if we require that the use of
qemu 2.9 requires that you also use libvirt 3.3.0 or newer (since we
missed the boat on fixing libvirt 3.2 to pass shared-rw or any other
handshaking we come up with), although it's also nice if we figure out
how to make qemu work with what existing libvirt wants to do (the NBD
export needs to be writable by the source pre-migration, and by the
destination post-migration; so there is that aspect of two clients both
wanting to write - but the destination doesn't need to write until after
the source no longer has anything to write, so if we have a clean way to
turn writes off for the source, then turn writes on for the destination,
all before migrating which host is writing, that would be even cleaner).

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

signature.asc
Description: OpenPGP digital signature