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)
Kevin
--
Best regards,
Vladimir
