[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).
Kevin
pgpd1ce0tpEKS.pgp
Description: PGP signature
- Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs, Kevin Wolf, 2017/04/03
- Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs, Max Reitz, 2017/04/03
- Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs,
Kevin Wolf <=
- Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs, Peter Krempa, 2017/04/03
- Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs, Kevin Wolf, 2017/04/04
- Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs, Eric Blake, 2017/04/04
- Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs, Paolo Bonzini, 2017/04/04
- Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs, Kevin Wolf, 2017/04/04
- Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs, Paolo Bonzini, 2017/04/04
- Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs, Kevin Wolf, 2017/04/05
- Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs, Paolo Bonzini, 2017/04/05
- Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs, Kevin Wolf, 2017/04/06
- Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs, Kevin Wolf, 2017/04/06