Bug 720269 - Convert KVM migration to use fd: instead of tcp: protocol
Summary: Convert KVM migration to use fd: instead of tcp: protocol
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Jiri Denemark
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 615941 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-11 09:54 UTC by Daniel Berrangé
Modified: 2011-12-06 11:16 UTC (History)
7 users (show)

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.
Clone Of:
Environment:
Last Closed: 2011-12-06 11:16:14 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1513 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2011-12-06 01:23:30 UTC

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


Note You need to log in before you can comment on or make changes to this bug.