Bug 706955

Summary:	libvirt spice client migration tries to migrate to wrong host
Product:	[Community] Virtualization Tools	Reporter:	Alexey Sharapov <nekoth>
Component:	libvirt	Assignee:	Libvirt Maintainers <libvirt-maint>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	berrange, crobinso, xen-maint
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-03-23 12:50:36 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Alexey Sharapov 2011-05-23 15:12:46 UTC

Description of problem:
libvirt spice migration sends wrong cookie to spice client. When I try to migrate from Host1 to Host2 qemu migrates correctly, but libvirt sends spice client cookie to connect to Host1 instead of Host2.
I looked through source code of doNativeMigrate and it seems than cookie object "mig" that is passed to qemuDomainMigrateGraphicsRelocate has local information, not the remote. 
qemuMigrationEatCookie returnes local info (from Host1), it doesn't parse incoming cookie and get new host name to migrate spice client to. There is only sanity check inside, so relocation failes, because it tries to migrate spice client to wrong host.

Version-Release number of selected component (if applicable):
libvirt-0.9.1-6bae93d

How reproducible:
Migrate from Host1 to Host2 while connected with spice client to Host1


Steps to Reproduce:
1. Start virtual machine on Host1
2. Connect to Host1 via spice client
3. Request live migration from Host1 to Host2
  
Actual results:
Virtual machine migrated from Host1 to Host2, spice client disconnected, because it tried to reconnect to Host1 after migration.


Expected results:
Virtual machine migrated from Host1 to Host2, spice client reconnected from Host1 to Host2 after migration.

Additional info:
Don't know, it is simply not finished code, or I don't understand the idea behind it.

Comment 2 Daniel Berrangé 2011-05-24 14:01:03 UTC

libvirt-0.9.1-6bae93d is not a version that is shipped in RHEL-6. Please file bugs in upstream libvirt, against the 'Virtualization Tools' product, not RHEL

Comment 3 Dave Allan 2011-05-24 15:31:38 UTC

I changed it to RHEL, it was originally reported against upstream.

Comment 4 Daniel Berrangé 2011-05-24 15:54:12 UTC

The code was not correctly distinguishing local from remote hostnames. A posted patch attempts to resolve that

http://www.redhat.com/archives/libvir-list/2011-May/msg01513.html

Comment 5 Alexey Sharapov 2011-05-30 14:24:48 UTC

(In reply to comment #4)
> The code was not correctly distinguishing local from remote hostnames. A posted
> patch attempts to resolve that
> 
> http://www.redhat.com/archives/libvir-list/2011-May/msg01513.html
Tried git build 80d2038 with this patch inside. Now it seems to try to connect to correct host, not the original one, but seems it does it too soon, before qemu is started on target machine, so I get "failed to connect" from spicec. Although if I try to manually connect to new address with spicec - it connects flawlessly.
Should I write to spice developers or wait for some fix in libvirt?

Comment 6 Daniel Berrangé 2011-05-31 09:02:46 UTC

> Tried git build 80d2038 with this patch inside. Now it seems to try to connect
> to correct host, not the original one, but seems it does it too soon, before
> qemu is started on target machine, so I get "failed to connect" from spicec.

QEMU on the target must be running when SPICE relocation takes place, because QEMU is required for migration to have been performed at all. My test with spicy work (spicy is the spice-gtk client).

Comment 7 Cole Robinson 2016-03-23 12:50:36 UTC

Sounds like the original issue was fixed, so closing