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
pgpVwQy8pbzq1.pgp
Description: PGP signature
