On 04/03/2017 08:00 AM, Kevin Wolf wrote: >> 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).
That sounds like the right approach - if nbd-server-add can detect that it is being invoked during the window between 'qemu -S' and before 'migrate', and allow the shared-rw at that time, then revoke it at the time the migrate command hits. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
