[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Kevin Wolf
Subject: Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs
Date: Mon, 3 Apr 2017 15:00:41 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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


Attachment: pgpd1ce0tpEKS.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]