Description of problem: When a suspended VM is saved and later restored, virsh list shows it as paused, but the VM is actually running Version-Release number of selected component (if applicable): 0.6.3-11 How reproducible: Create a KVM virtual machine, suspend it, save it, restore it, run virt-viewer on it. Steps to Reproduce: 1. Start a task in a KVM virtual machine, e.g. seq 1 10000000 2. Suspend the virtual machine: virsh suspend EXAMPLE 3. virsh save EXAMPLE test.qemu 4. virsh restore test.qemu 5. virt-viewer EXAMPLE Actual results: Numbers keep scrolling on the VM Expected results: Numbers should not scroll in the VM Additional info: libvirt actually believes the domain is paused, so that you need "virsh resume EXAMPLE && virsh suspend EXAMPLE" to really pause it. Saving a suspended VM does not work at all for Xen.
The Xen bug, for the record, is bug 504910. This bug is a bit more severe though, IMO (doing nothing is worse than doing it wrong).
Hum, this is coming a bit late in the game for Update 4, we have no patch yet, it's not a very common scenario, and probably not very crucial, the resume/suspend after restore is not ideal but probably workable in most cases. So I suggest to retarget it for update 5 at this point, thanks for raising the issue though we need to get this fixed upstream, my assumption is that we don't look at the suspended information when restoring the domain at some low level while libvirt is aware of it. Daniel
This isn't a libvirt problem. This is a bug in QEMU/KVM. After the 'migrate' command finishes it should *not* be starting execution of the CPUs. Resuming execution is a policy decision for the management tool to make. libvirt explicitly starts the VM with '-S' for stopped, and QEMU should not override this and start the VM after migrate when this is the case.
Created attachment 351586 [details] qemu patch to fix the bug I submitted this patch upstream.
Created attachment 355681 [details] patch matching upstream This patch includes an additional fix from Glauber Costa.
*** This bug has been marked as a duplicate of bug 503367 ***