Bug 720269

Summary:	Convert KVM migration to use fd: instead of tcp: protocol
Product:	Red Hat Enterprise Linux 6	Reporter:	Daniel Berrangé <berrange>
Component:	libvirt	Assignee:	Jiri Denemark <jdenemar>
Status:	CLOSED ERRATA	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	high	Docs Contact:
Priority:	high
Version:	6.0	CC:	dallan, dyuan, eblake, mzhan, rwu, weizhan, yimwang
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	libvirt-0.9.4-4.el6	Doc Type:	Bug Fix
Doc Text:	When migrating a QEMU domain, libvirt could report "undefined error" in case source QEMU process was not able to connect to the destination process. With this update, instead of relying on QEMU error messages, libvirt itself creates the connection to destination QEMU process and makes QEMU use this pre-created connection, which allows libvirt to report meaningful errors if the connection attempt fails.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-12-06 11:16:14 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 Daniel Berrangé 2011-07-11 09:54:05 UTC

Description of problem:
QEMU is utterly incapable of providing any useful information when an attempt to initiate migration fails due to incorrect hostname causing failed DNS, or firewall problems breaking the connection attempt. Despite requests upstream to improve error reporting spanning several years, there is no visible sign of progress.

libvirt should thus take QEMU out of the loop, by opening the TCP socket ourselves, and then just passing it to QEMU using the fd: protocol.

Version-Release number of selected component (if applicable):


How reproducible:
libvirt-0.9.3-1.el6

Steps to Reproduce:
1. virsh migrate vm1 qemu+ssh://somehost/system tcp://somebogushost
2.
3.
  
Actual results:
An undefined error has occured

Expected results:
Unable to resolve hostname 'somebogushost'

Or

Unable to connect to 'somebogushost'

Additional info:

See also this KVM bug asking for improved error reporting

https://bugzilla.redhat.com/show_bug.cgi?id=584077

Comment 3 Jiri Denemark 2011-08-15 09:55:41 UTC

Patches were sent upstream: https://www.redhat.com/archives/libvir-list/2011-August/msg00565.html

Comment 4 Jiri Denemark 2011-08-15 13:55:54 UTC

Series sent for review to rhvirt-patches: http://post-office.corp.redhat.com/archives/rhvirt-patches/2011-August/msg00468.html

Comment 6 weizhang 2011-08-16 09:00:11 UTC

verify pass on 
libvirt-0.9.4-4.el6.x86_64

steps:
1. prepare migration environment and a running guest, make sure that the guest can be migrated from source to target host with normal command like
# virsh migrate --live guest qemu+ssh://{target ip}/system

2. do migration with 
# virsh migrate vm1 qemu+ssh://{target ip}/system tcp://1.1.1.1
it will report error like
error: unable to connect to server at '1.1.1.1:49152': No route to host


when do the same steps on libvirt-0.9.4-2, it reports:
error: operation failed: migration job: unexpectedly failed

so the bug is verified.

Comment 7 Osier Yang 2011-09-22 01:40:44 UTC

*** Bug 615941 has been marked as a duplicate of this bug. ***

Comment 8 Jiri Denemark 2011-11-14 14:53:06 UTC

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
When migrating a QEMU domain, libvirt could report "undefined error" in case source QEMU process was not able to connect to the destination process. With this update, instead of relying on QEMU error messages, libvirt itself creates the connection to destination QEMU process and makes QEMU use this pre-created connection, which allows libvirt to report meaningful errors if the connection attempt fails.

Comment 9 errata-xmlrpc 2011-12-06 11:16:14 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1513.html