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

[Kevin Wolf <kwolf@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]

Am 03.04.2017 um 14:39 hat Max Reitz geschrieben:
> On 03.04.2017 10:15, Kevin Wolf wrote:
> > Am 31.03.2017 um 19:43 hat Max Reitz geschrieben:
> 
> [...]
> 
> >> So in theory all that's necessary is to set share-rw=on for the device
> >> in the management layer. But I'm not sure whether that's practical.
> > 
> > Yes, libvirt needs to provide this option if the guest supports sharing.
> > If it doesn't support sharing, rejecting a read-write NBD client seems
> > correct to me.
> > 
> > Peter, Eric, what is the status on the libvirt side here?
> > 
> >> 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).

If I understand correctly, this is a case of incoming live migration,
i.e. the virtio-blk device which is blocking the writes to the image
doesn't really belong to a running guest yet.

So if we need to make an exception (and actually reading the context
makes it appear so), I guess it would have to be that devices actually
can share the write permission during incoming migration, but not any
more later (unless the share-rw flag is set).

Kevin

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]