Bug 1454362

Summary: QEMU fails to report error when requesting migration bind to "::" when ipv6 disabled
Product: Red Hat Enterprise Linux 7 Reporter: Daniel Berrange <berrange>
Component: qemu-kvm-rhevAssignee: Eric Blake <eblake>
Status: CLOSED ERRATA QA Contact: xianwang <xianwang>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.4CC: areis, chayang, eblake, juzhang, knoel, michen, mrezanin, mtessun, qzhang, virt-maint, xianwang
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: qemu-kvm-rhev-2.10.0-1.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-11 00:19:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Daniel Berrange 2017-05-22 14:39:49 UTC
Description of problem:

Consider the following migration arg:

$ qemu-system-x86_64 -incoming tcp:[::]:9000,ipv4

which requests binding to a IPv6 address "::", but also requests IPv4 access only. This is a nonsensical combination and should report an error message. Indeed, other QEMU backends (VNC, chardev, etc) do report an error in this scenario, but the migration code does not, due to a bug in inet_parse

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

How reproducible:

Steps to Reproduce:
1. $ qemu-system-x86_64 -incoming tcp:[::]:9000,ipv4

Actual results:
QEMU listens on "::"

Expected results:
Exits with error message such as 

qemu-system-x86_64: -incoming tcp:[::]:9000,ipv4: address resolution failed for :::9000: Address family for hostname not supported

Comment 2 Daniel Berrange 2017-05-22 14:41:07 UTC
This is fixed by patch 2 in this small series


Comment 3 Eric Blake 2017-06-11 03:33:28 UTC
Dan's series is now at v3:

Depending on urgency and timing deadlines, we may want to port those patches downstream without waiting for an upstream pull request to land.

Comment 6 Eric Blake 2017-07-17 16:43:56 UTC
Will be picked up for 7.5 via rebase, because it is included in upstream 2.10:

commit 4dc5d815c43b0138e5d6753e788343f6e2cb6b5f
Author: Daniel P. Berrange <berrange@redhat.com>
Date:   Wed May 17 18:35:40 2017 +0100

    sockets: don't block IPv4 clients when listening on "::"
    When inet_parse() parses the hostname, it is forcing the
    has_ipv6 && ipv6 flags if the address contains a ":". This
    means that if the user had set the ipv4=on flag, to try to
    restrict the listener to just ipv4, an error would not have
    been raised.  eg
       -incoming tcp:[::]:9000,ipv4
    should have raised an error because listening for IPv4
    on "::" is a non-sensical combination. With this removed,
    we now call getaddrinfo() on "::" passing PF_INET and
    so getaddrinfo reports an error about the hostname being
    incompatible with the requested protocol:
     qemu-system-x86_64: -incoming tcp:[::]:9000,ipv4: address resolution
        failed for :::9000: Address family for hostname not supported
    Likewise it is explicitly setting the has_ipv4 & ipv4
    flags when the address contains only digits + '.'. This
    has no ill-effect, but also has no benefit, so is removed.
    Acked-by: Gerd Hoffmann <kraxel@gmail.com>
    Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
    Reviewed-by: Eric Blake <eblake@redhat.com>
    Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

Comment 12 Qunfang Zhang 2017-11-27 07:44:32 UTC
Reproduced on qemu-kvm-rhev-2.9.0-16.el7_4.12.ppc64le:

]# /usr/libexec/qemu-kvm -incoming tcp:[::]:9000,ipv4
VNC server running on ::1:5900

Verified on qemu-kvm-rhev-2.10.0-7.el7.ppc64le:

# /usr/libexec/qemu-kvm -incoming tcp:[::]:9000,ipv4
VNC server running on ::1:5900
qemu-kvm: -incoming tcp:[::]:9000,ipv4: address resolution failed for :::9000: Address family for hostname not supported

QEMU failed to boot up when incoming migration process bind with ipv6 address while ipv6 is disabled. 

Setting to VERIFIED.

Comment 14 errata-xmlrpc 2018-04-11 00:19:31 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.