+++ This bug was initially created as a clone of Bug #503367 +++

Description of problem:

After migration to a paused VM is completed successfully - the VM on destination is running instead of remaining in paused.

--- Additional comment from danken on 2009-06-08 16:21:58 EDT ---

I hope the summary is clearer now, and that it's clearer it is a qemu-kvm issue: qemu-kvm forgets it "paused" status after migrating.

--- Additional comment from ykaul on 2009-06-23 10:47:50 EDT ---

If it's paused because of lack of storage, isn't that dangerous?

--- Additional comment from danken on 2009-06-23 15:55:18 EDT ---

(In reply to comment #2)
> If it's paused because of lack of storage, isn't that dangerous?  

I don't think so. At worse, the retried write() would fail (and stopped) as the first one.

--- Additional comment from pbonzini on 2009-08-04 07:22:27 EDT ---

The bug is a dup of 510459.  This one has the flags, that one has the patches.  Which one should be closed?

--- Additional comment from dlaor on 2009-08-04 08:00:20 EDT ---

*** Bug 510459 has been marked as a duplicate of this bug. ***

--- Additional comment from pbonzini on 2009-08-13 08:51:02 EDT ---

Created an attachment (id=357312)
updated patch

--- Additional comment from danken on 2009-08-13 10:13:09 EDT ---

what happens if the vm paused after migration has started? Why cannot this bit of information (cpu paused/running) be transferred within the migration protocol? In my opinion, this is a (n important) part of machine state.

--- Additional comment from pbonzini on 2009-08-13 11:21:50 EDT ---

QEMU's state does not include whether the CPU is running.  libvirt has to fake it.

I'll open soon a clone of this bug because there are some migration-related libvirt parts (the patch I attached so far is enough for save/restore, but not for migration), but still I'd rather avoid changes to the libvirt protocol, and these would be required to transmit the running/paused state at the end of migration.  The reason is that there is currently no way for libvirt's Perform Migration step (running on the source) to pass information to the Finish Migration step (running on the destination after Perform has finished).

--- Additional comment from danken on 2009-08-13 11:33:04 EDT ---

(In reply to comment #8)
> QEMU's state does not include whether the CPU is running.  libvirt has to fake
> it.

I know, and I think this is the real bug here.

--- Additional comment from pbonzini on 2009-08-13 11:36:29 EDT ---

Actually I agree, but I think the simpler implementation picking up the state at the beginning would be good enough.  After all it would only affect live migration, and I'm not sure why you'd migrate live if you plan to suspend the VM.

What if you opened the libvirt clone for this, so we can discuss there whether it's okay to change the protocol?

--- Additional comment from berrange on 2009-08-13 11:49:14 EDT ---

There is no problem in libvirt at this time, since it does not allow the user to pause a VM after migration starts. libvirt merely requires QEMU to actually honour the '-S' flag that was given on the command line.

--- Additional comment from pbonzini on 2009-08-13 12:11:09 EDT ---

There is definitely in libvirt a problem that "cont" is executed unconditionally during the Finish step on the remote VM.  While the qemu patch here is enough for save/restore, libvirt needs more care as well.

I haven't experimented whether it's possible to suspend a VM concurrently to live migration, though it was on my testing todo list after Dan's comment.

--- Additional comment from danken on 2009-08-17 07:02:21 EDT ---

(In reply to comment #12)

> I haven't experimented whether it's possible to suspend a VM concurrently to
> live migration.

with -drive ...,werror=stop qemu can suspend its guest whenever it is doing io.