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

[ciprian . barbu]

Hi,

On 03.04.2017 22:44, Eric Blake wrote:
> 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

Sounds reasonable enough, I guess we didn't look at it this way.

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

Ok, this sounds like you are saying that there isn't much reasoning 
behind this usecase, and also we might be the only ones complaining 
about new qemu not working with an old libvirt.

I think we could do with a 'clean' (as clean as it gets) workaround, 
since it might be very difficult to bump libvirt in our Openstack 
environment, skipping one major versions and several minors. But we 
would be willing to do it as long as there are good chances it should 
work ok. In the mean time we are using a less clean workaround and we 
rely on you guys to help us find a good solution.

Thanks and regards,
/Ciprian