Description of problem: If I migrate a domain using: virsh migrate --persistent --undefinesource --tunnelled --p2p --live --desturi 'qemu+ssh://root@hybrid0/system' spice and restart the src libvirtd during the migration, the guest will remained defined but paused on the dst host. Stopping the guest on the dst host causes it to vanish. Migrating without the --persistent flag does not exhibit this behavior. Version-Release number of selected component (if applicable): libvirt-0.9.4-0rc1.2.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. virsh migrate --persistent --undefinesource --tunnelled --p2p --live --desturi 'qemu+ssh://root@hybrid0/system' spice 2. during the migration, restart libvirtd on the src host Actual results: The migration is cancelled but the guest still exists, but is paused on the dst host. Expected results: The migration is cancelled and the guest is running on the src host and does not exist on the dst host.
One additional datapoint: the src libvirtd should be stopped and started after a few seconds, not restarted. It seems to make a difference.
I was able to reproduce this bug with --p2p --tunnelled when source libvirtd crashed after calling Prepare on target but before actually starting to transmit any data. It doesn't reproduce with just --p2p. The difference is that after with --tunnelled, nothing happens after virNetSocketReadWire:910 : End of file while reading data: Input/output error In plain p2p mode, virConnectClose is called, which triggers qemuProcessAutoDestroyRun and the domain is removed.
Has anyone verified this is still an issue? It hasn't been materially updated for over 4 years
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.