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

[Kevin Wolf]

Am 04.04.2017 um 16:04 hat Paolo Bonzini geschrieben:
> On 04/04/2017 14:16, Kevin Wolf wrote:
> > 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.
> 
> Isn't there already a bdrv_invalidate_cache_all or something like that
> called when the VM is started?

bdrv_invalidate_cache_all() is different in two aspects.

First, it starts at the BDS level and propagates down to children, but
not up to the parents, where the permissions are set.

Second, bdrv_invalidate_cache_all() is called immediately when migration
completes. This is before the NBD server is shut down, so we can't
actually request write permissions at this point yet.

> Having to touch all devices would be ugly.  Maybe some permissions could
> be marked as "deferred".

Yes, BlockDevOps for it wasn't that great an idea.

We have a common function blkconf_apply_backend_options() that sets the
permissions for any devices that we care about with storage migration.
This function can be changed not to do this during incoming migration,
and then we would need a way to find the BlockConf later when trying to
resume the VM. Failing that, we could try to make it register a notifier
or something.

Or we could mark BlockBackends as "enforce permissions only after
migration has completed" and do this for all BlockBackends of devices.

> The big question is how this fits into release management.  We have
> another important regression from the op blocker work and only a week
> to go before the last rc.  Are we going to delay 2.9 arbitrarily?  Are
> we going to shorten the 2.10 development period correspondingly?  (I
> vote yes and yes, FWIW).

Which is the other regression?

Kevin

pgp4TcX89wjEa.pgp
Description: PGP signature