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