Am 03.04.2017 um 15:50 hat Peter Krempa geschrieben:
> On Mon, Apr 03, 2017 at 15:00:41 +0200, Kevin Wolf wrote:
> > 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).

Now the big question is how to implement this. Just not requesting the
write permission initially if runstate_check(RUN_STATE_INMIGRATE) is
easy. But we need to find a place to actually request it later, after
the mirror has completed, and before the VM is running.

My first thought was that we could add a VMChangeStateHandler and just
request the permission in there. However, requesting the permission can
fail (e.g. because the NBD server hasn't been shut down) and we can't
let a state transition fail from a VMChangeStateHandler.

Maybe the next best thing we could do is to have a BlockDevOps callback
for invalidate_cache/inactivate and get the permissions there. This one
could return an error, which would be passed up the stack and eventually
cause qmp_cont() to fail (i.e. it would refuse to resume the VM). This
sounds workable to me.

Any comments on this approach, or maybe other ideas?

Kevin