Am 28.03.2017 um 12:55 hat Dr. David Alan Gilbert geschrieben:
* Kevin Wolf (address@hidden) 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 <address@hidden>
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.