Bug 728603

Summary:	guest may remain in existence on dst host if src libvirtd stopped during tunneled migration
Product:	[Community] Virtualization Tools	Reporter:	Dave Allan <dallan>
Component:	libvirt	Assignee:	Libvirt Maintainers <libvirt-maint>
Status:	CLOSED DEFERRED	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	crobinso, cwei, dyuan, fjin, jdenemar, libvirt-maint, mzhan, weizhan
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-11-03 16:30:58 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Dave Allan 2011-08-05 18:35:43 UTC

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.

Comment 1 Dave Allan 2011-08-05 18:39:05 UTC

One additional datapoint: the src libvirtd should be stopped and started after a few seconds, not restarted.  It seems to make a difference.

Comment 3 Jiri Denemark 2011-08-12 21:10:55 UTC

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.

Comment 8 Cole Robinson 2016-03-23 13:08:33 UTC

Has anyone verified this is still an issue? It hasn't been materially updated for over 4 years

Comment 12 Daniel Berrangé 2020-11-03 16:30:58 UTC

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.