Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 694196 - RHEL 6.1 qemu-kvm: Specifying ipv6 addresses breaks migration
RHEL 6.1 qemu-kvm: Specifying ipv6 addresses breaks migration
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
6.1
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Juan Quintela
Virtualization Bugs
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-06 13:33 EDT by Lucas Meneghel Rodrigues
Modified: 2015-10-18 18:41 EDT (History)
9 users (show)

See Also:
Fixed In Version: qemu-kvm-0.12.1.2-2.156.el6
Doc Type: Bug Fix
Doc Text:
[NOTE: it is a fix to a bug introduced after 6.0 so the bug was never present on a RHEL release] Cause: getaddrinfo() changes introduced in the migration code post-RHEL-6.0were incomplete. Consequence: using a IPv6 address as migration target (e.g. if 'localhost' has an IPv6 address on /etc/hosts) could fail. Fix: getaddrinfo() changes reverted to the RHEL 6.0 code (that doesn't have the ability to do live migration through IPv6). Result: migration to 'localhost' will use the IPv4 address even if it had an associated IPv6 address in addition to IPv4 addresses, making migration work again.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-19 07:22:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:0534 normal SHIPPED_LIVE Important: qemu-kvm security, bug fix, and enhancement update 2011-05-19 07:20:36 EDT

  None (edit)
Description Lucas Meneghel Rodrigues 2011-04-06 13:33:54 EDT
Description of problem: When trying to do migration referencing ipv6 addresses in RHEL 6.1 (such as localhost), migration will fail.

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

gpxe-roms-qemu.noarch 0:0.9.7-6.7.el6
qemu-img.x86_64 2:0.12.1.2-2.155.el6
qemu-kvm.x86_64 2:0.12.1.2-2.155.el6
qemu-kvm-tools.x86_64 2:0.12.1.2-2.155.el6
seabios.x86_64 0:0.6.1.2-3.el6
spice-server.x86_64 0:0.8.0-1.el6
vgabios.noarch 0:0.6b-3.5.el6
kernel-2.6.32-128.el6.x86_64

How reproducible: Always

Steps to Reproduce:
1. Start qemu-kvm source VM

/usr/local/autotest/tests/kvm/qemu -name 'vm1' -monitor unix:'/tmp/monitor-humanmonitor1-20110406-080942-JLHW',server,nowait -qmp unix:'/tmp/monitor-qmpmonitor1-20110406-080942-JLHW',server,nowait -serial unix:'/tmp/serial-20110406-080942-JLHW',server,nowait -drive file='/tmp/kvm_autotest_root/images/rhel6-64.qcow2',index=0,if=virtio,cache=none -device virtio-net-pci,netdev=idTaumhN,mac='9a:d8:60:23:c5:98',id='idN6l85e' -netdev tap,id=idTaumhN,ifname='t0-080942-JLHW',script='/usr/local/autotest/tests/kvm/scripts/qemu-ifup',downscript='no' -m 2048 -smp 2 -vnc :0

2. Start vm with -incoming as the destination VM
3. Migrate using qemu monitor

04/06 08:10:18 DEBUG|kvm_monito:0243| (human monitor humanmonitor1) - cmd 'migrate -d tcp:localhost4:5200'
  
Actual results: Qemu monitor will respond 

04/06 07:55:12 DEBUG|kvm_monito:0260| (human monitor humanmonitor1) - response to cmd 'info migrate': 'Migration status: failed'

Expected results: Qemu will migrate the VM:

04/06 08:10:20 DEBUG|kvm_monito:0260| (human monitor humanmonitor1) - response to cmd 'info migrate': 'Migration status: active
transferred ram: 902084 kbytes
remaining ram: 1212344 kbytes
total ram: 2113920 kbytes'

Additional info: We have a lead of the problem, it's a naming resolution issue. Looking at /etc/hosts:

[root@virtlab105 debug]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

If we change the reference from localhost to localhost4 the migration will work fine.
Comment 1 Lucas Meneghel Rodrigues 2011-04-06 13:46:42 EDT
It is important to note that this is a regression from RHEL 6.0. No such problem happens under 6.0.
Comment 2 Lucas Meneghel Rodrigues 2011-04-06 13:50:37 EDT
Correction - on the steps, where I wrote

04/06 08:10:18 DEBUG|kvm_monito:0243| (human monitor humanmonitor1) - cmd
'migrate -d tcp:localhost4:5200'

Should be


04/06 08:10:18 DEBUG|kvm_monito:0243| (human monitor humanmonitor1) - cmd
'migrate -d tcp:localhost:5200'

cut and paste and rushing... sorry.
Comment 7 Mike Cao 2011-04-11 02:09:49 EDT
(In reply to comment #1)
> It is important to note that this is a regression from RHEL 6.0. No such
> problem happens under 6.0.

FYI.I think this one is dup of Bug #680356

# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

The patch include ipv6 support .but "localhost" was used both on ipv4 address (127.0.0.1   localhost)and ipv6 address(::1         localhost) in /etc/hosts .When we use localhost in migration,qemu-kvm parsed to ipv6 address ,it should be same as I tested in bug 680356 which is failedQA .

same thing happened if we add a alias in /etc/hosts on both ipv4 and ipv6 at the same time ,it also failed.
eg: 
# cat /etc/hosts
::1        mike
127.0.0.1  mike
then (qemu)migrate -d tcp:mike:5888 ,it also failed.

workaround :
change /etc/hosts to 
# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost_TT localhost.localdomain localhost6 localhost6.localdomain6

then (qemi) migrate -d tcp:localhost:5888 ,it will work fine
Comment 8 Mike Cao 2011-04-11 06:26:08 EDT
Reproduced the issue described in qemu-kvm-0.12.1.2-2.154.el6.

Verified this issue on qemu-kvm-0.12.1.2-2.156.el6 

steps:
1.start VM 
2.start listening port at the same host
3(qemu) migrate -d tcp:localhost:5888

Actual Results: 
with qemu-kvm-0.12.1.2-2.154.el6 ,migrate failed
with qemu-kvm-0.12.1.2-2.156.el6 ,migrate success


Based on above ,this issue has been fixed.
Comment 9 Eduardo Habkost 2011-04-11 09:59:07 EDT
(In reply to comment #7)
> (In reply to comment #1)
> > It is important to note that this is a regression from RHEL 6.0. No such
> > problem happens under 6.0.
> 
> FYI.I think this one is dup of Bug #680356

It is not a duplicate, it is a regression caused by the fix to Bug #680356 (that was reverted now). Bug #680356 is about not having any ipv6 support, this one was about a problem found after we have added ipv6 support.
Comment 10 Mike Cao 2011-04-14 04:21:01 EDT
Base on comment #8 ,change status to VERIFIED.
Comment 11 Eduardo Habkost 2011-05-05 08:23:00 EDT
    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:
[NOTE: it is a fix to a bug introduced after 6.0 so the bug was never present on a RHEL release]

Cause: getaddrinfo() changes introduced in the migration code post-RHEL-6.0were incomplete.

Consequence: using a IPv6 address as migration target (e.g. if 'localhost' has an IPv6 address on /etc/hosts) could fail.

Fix: getaddrinfo() changes reverted to the RHEL 6.0 code (that doesn't have the ability to do live migration through IPv6).

Result: migration to 'localhost' will use the IPv4 address even if it had an associated IPv6 address in addition to IPv4 addresses, making migration work again.
Comment 12 errata-xmlrpc 2011-05-19 07:22:03 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0534.html
Comment 13 errata-xmlrpc 2011-05-19 09:02:38 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0534.html

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