qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs
Date: Tue, 4 Apr 2017 16:04:39 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0


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?

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

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).

Paolo

> 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.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]