* Kevin Wolf (kw...@redhat.com) wrote: > Am 07.03.2017 um 10:59 hat Vladimir Sementsov-Ogievskiy geschrieben: > > 07.03.2017 12:53, Kevin Wolf 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. > > > > Yes, I mean on the source. It may not be migration for "mirgration", > > but for dumping state to file. In that case it seems not wrong to > > make a snapshot on source. > > Yes, resuming on the source is definitely valid. I'm only questioning if > 'savevm' (and by extension, any other command that modifies the VM or > its images) should automagically regain control of the VM, or whether > that should be more explicit.
How many things other than 'cont' and 'savevm' are there? We should definitely fix it so a savevm there doesn't assert, but I'm also unsure if it's worth a separate explicit command. Dave > Kevin -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
