[Top][All Lists]

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

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

From: Kevin Wolf
Subject: Re: [Qemu-block] [PATCH 3/4] savevm: fix savevm after migration
Date: Tue, 28 Mar 2017 13:09:00 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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.


reply via email to

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