[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 3/4] savevm: fix savevm after migration

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-devel] [PATCH 3/4] savevm: fix savevm after migration
Date: Tue, 28 Mar 2017 16:16:37 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

28.03.2017 15:09, Kevin Wolf wrote:
Am 28.03.2017 um 13:13 hat Dr. David Alan Gilbert geschrieben:
* Kevin Wolf (address@hidden) wrote:
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

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)


Best regards,

reply via email to

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