When live migrating a domain from one server to another, Virtual Machine Manager incorrectly shows the migrated domain state as "Paused" on the receiving server after live migration. if the receiving server does not already have a definition for the domain. However, if the receiving server already had a definition for the domain, Virtual Machine Manager correctly displays the domain state as "Running" after live migration. In either case, checking the domain's state via "virsh -c qemu://${recipient}/system list" correctly shows the domain as "running". Likewise, disconnecting and reconnecting to the receiving host will correct the domain's displayed state. Additionally, even when the domain is displayed in Virtual Machine Manager as paused opening the domain will connect to the "running" domain. This leads me to believe that Virtual Machine Manager is simply missing the state change when the receiving host does not have a domain definition. ===== Management laptop monitoring both primary and secondary VM server using virt-manager. Connected to both servers over both qemu+tls and qemu+ssh. Live migrate domain from primary to secondary VM server using either the Virtual Machine Manager interface or the following command: virsh \ -c qemu:///system \ migrate \ --live \ --persistent \ --p2p \ --tunneled \ --verbose \ ${DOMAIN} qemu+tls://${SECONDARY}/system All machines are running Arch Linux. Domains are backed by CEPH RDB volumes. management laptop $ yaourt -Q libvirt virt-manager community/libvirt 2.4.0-2 community/virt-manager 1.4.0-2 primary VM server $ yaourt -Q qemu libvirt qemu-block-rbd extra/qemu 2.8.0-1 community/libvirt 2.4.0-2 extra/qemu-block-rbd 2.8.0-1 secondary VM server $ yaourt -Q qemu libvirt qemu-block-rbd extra/qemu 2.8.0-1 community/libvirt 2.4.0-2 extra/qemu-block-rbd 2.8.0-1
The above migration command should have been: virsh \ -c qemu:///system \ migrate \ --live \ --persistent \ --p2p \ --tunneled \ --verbose \ ${DOMAIN} \ qemu+tls://${SECONDARY}/system
It's been a while, any update?
Sorry for the delay. Please provide virt-manager --debug output, from app startup to app shutdown, when reproducing the issue
Created attachment 1311854 [details] requested virt-manager output Here's the requested virt-manger output.
Thanks for the info. Tough to tell from the log if this is a libvirt issue or virt-manager issue. I'll need to get a setup to reproduce
I can gather more information and run whatever tests you need. Just let me know.
I am seeing something similar, though not related to migration. If a domain is defined and then immediately started (through some other libvirt API client, not from virt-manager), virt-manager shows the newly created guest is Paused. From my virt-manager debug logs I see: (connection:788) domain lifecycle event: domain=example event=0 reason=0 (connection:788) domain lifecycle event: domain=example event=4 reason=0 (connection:788) domain lifecycle event: domain=example event=2 reason=0 (connection:1196) domain=example status=Paused added (connection:1190) New domain=example requested, but it's already tracked. (connection:1190) New domain=example requested, but it's already tracked. Those three events are defined, resumed, started. If I put a small delay between the point where the domain is defined and it is started, virt-manager seems happier: (connection:788) domain lifecycle event: domain=example event=0 reason=0 (connection:1196) domain=example status=Shutoff added (connection:788) domain lifecycle event: domain=example event=4 reason=0 (connection:788) domain lifecycle event: domain=example event=2 reason=0 It looks to me like virt-manager gets the domain state when it sees it being defined, and this can race against the domain's state transitions (though I'm not sure why that would end up with status=Paused...).
*** Bug 1247593 has been marked as a duplicate of this bug. ***
*** Bug 1388403 has been marked as a duplicate of this bug. ***
Thanks Michael for the details. Indeed after going over the code there's a few race conditions here for sure, I couldn't reproduce through regular activity but I can manually trigger them by adding some hacks into the code. Fixing them in an efficient manner is not trivial though, but it's on my todo list for the next release
(In reply to Cole Robinson from comment #10) > Thanks Michael for the details. Indeed after going over the code there's a > few race conditions here for sure, I couldn't reproduce through regular > activity but I can manually trigger them by adding some hacks into the code. > Fixing them in an efficient manner is not trivial though, but it's on my > todo list for the next release It might be worth trying to add some latency on your connection; it's not too unusual for me to get this type of failure with live-migration related things; but I do tend to have a ~150ms latency to the host with the VMs.
I have this issue as well. VMM 1.4.3 on Fedora 27. Migrating results in VMM showing the VM as paused, but it is still running and can be accessed through the console fine. Temporary migration to a new host shows it as paused, migrating back to original host shows it as running. A "persistent" migration will show paused as well. But closing and opening VMM will show it as running (this also works with the temp migration). I attached some debug logs from VMM.
Created attachment 1477371 [details] VMM migrate logs
Been a while and virt-manager internals have changed quite a lot since then. Is anybody still reproducing this issue?