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

[Peter Krempa]

On Mon, Apr 03, 2017 at 15:00:41 +0200, Kevin Wolf wrote:
> 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.

Yes, exactly. libvirt starts the NBD server on the destination of
the migration. Until then the VM did not ever run yet. The VM will run
once the memory migration finishes, so the guest front-end will not
write anything at that point.

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

Yes, this would be desired to avoid a regression. Libvirt then tears
down the mirror prior to resuming the VM (afaik).

signature.asc
Description: PGP signature