On 28/03/2017 15:16, Vladimir Sementsov-Ogievskiy wrote: > 28.03.2017 15:09, Kevin Wolf wrote: >> Am 28.03.2017 um 13:13 hat Dr. David Alan Gilbert geschrieben: >>> * Kevin Wolf (kw...@redhat.com) wrote: >>>> Am 28.03.2017 um 12:55 hat Dr. David Alan Gilbert geschrieben: >>>>> * Kevin Wolf (kw...@redhat.com) wrote: >>>>>> Am 25.02.2017 um 20:31 hat Vladimir Sementsov-Ogievskiy geschrieben: >>>>>>> After migration all drives are inactive and savevm will fail with >>>>>>> >>>>>>> qemu-kvm: block/io.c:1406: bdrv_co_do_pwritev: >>>>>>> Assertion `!(bs->open_flags & 0x0800)' failed. >>>>>>> >>>>>>> Signed-off-by: Vladimir Sementsov-Ogievskiy >>>>>>> <vsement...@virtuozzo.com> >>>>>> What's the exact state you're in? I tried to reproduce this, but just >>>>>> doing a live migration and then savevm on the destination works >>>>>> fine for >>>>>> me. >>>>>> >>>>>> Hm... Or do you mean on the source? In that case, I think the >>>>>> operation >>>>>> must fail, but of course more gracefully than now. >>>>>> >>>>>> Actually, the question that you're asking implicitly here is how the >>>>>> source qemu process should be "reactivated" after a failed migration. >>>>>> Currently, as far as I know, this is only with issuing a "cont" >>>>>> command. >>>>>> It might make sense to provide a way to get control without >>>>>> resuming the >>>>>> VM, but I doubt that adding automatic resume to every QMP command >>>>>> is the >>>>>> right way to achieve it. >>>>>> >>>>>> Dave, Juan, what do you think? >>>>> I'd only ever really thought of 'cont' or retrying the migration. >>>>> However, it does make sense to me that you might want to do a savevm >>>>> instead; if you can't migrate then perhaps a savevm is the best you >>>>> can do before your machine dies. Are there any other things that >>>>> should be allowed? >>>> I think we need to ask the other way round: Any reason _not_ to allow >>>> certain operations that you can normally perform on a stopped VM? >>>> >>>>> We would want to be careful not to accidentally reactivate the disks >>>>> on the source after what was actually a succesful migration. >>>> Yes, that's exactly my concern, even with savevm. That's why I >>>> suggested >>>> we could have a 'cont'-like thing that just gets back control of the >>>> images and moves into the normal paused state, but doesn't immediately >>>> resume the actual VM. >>> OK, lets say we had that block-reactivate (for want of a better name), >>> how would we stop everything asserting if the user tried to do it >>> before they'd run block-reactivate? >> We would have to add checks to the monitor commands that assume that the >> image is activated and error out if it isn't. >> >> Maybe just adding the check to blk_is_available() would be enough, but >> we'd have to check carefully whether it covers all cases and causes no >> false positives. >> >> By the way, I wouldn't call this 'block-reactivate' because I don't >> think this should be a block-specific command. It's a VM lifecycle >> command that switches from a postmigrate state (that assumes we have no >> control over the VM's resources any more) to a paused state (where we do >> have this control). Maybe something like 'migration-abort'. > > 'abort' is not very good too I think. migration is completed, nothing to > abort.. (may be successful migration to file for suspend, some kind of > vm cloning, etc)
There is already migrate_cancel. Does it make sense to make it reactivate fds if migration is completed? Paolo
