Bug 878717

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

From bug 1098659 comment 9, I assume libvirt explicitly uses AI_ADDRCONFIG as a hint.  In this case, discarding IPv4 addresses found, when only IPv6 addresses and IPv4 loopback addresses are configured, is the expected behavior of getaddrinfo per RFC 3493.  It is possible that future releases of glibc revisit this behavior, because it conflicts with POSIX, but I don't envision our making such major changes to getaddrinfo behavior in current releases, so I'm inclined to recommend libvirt to drop AI_ADDRCONFIG for now, if the problem remains, although bug 796043 seems to indicate it was fixed.

In Bug 796043 we THOUGHT it's not a function bug, so we fix it by adding an clear error message.

Until now I still agree with original decision. We can see both IPv4 and IPv6 addresses are configured in 'lo', but we can only indicate to use one of them.

# qemu-kvm -vnc [::1]:0 -> listen IPV6
# qemu-kvm -vnc 127.0.0.1:0 -> listen IPV4

# qemu-kvm -vnc localhost:0 -> listen IPV4
# qemu-kvm -vnc :0 -> listen IPV4

This is the test result in my laptop, localhost is parsed to IPv6 firstly, it depends on the configuration in /etc/hosts

=====================================================

In QEMU (qemu/util/qemu-sockets.c), we set AI_ADDRCONFIG in three parts.

1) TCP listen:
   ai.ai_flags = AI_PASSIVE | AI_ADDRCONFIG;                                                                                                                               

2) TCP client:
   ai.ai_flags = AI_CANONNAME | AI_ADDRCONFIG;                                                                                                                                     

3) UDP:
   ai.ai_flags = AI_CANONNAME | AI_ADDRCONFIG;


What's the expected result after remove this flag?

We need to distinguish internal vs. public, IPv4 vs. IPv6. I don't think we need to change anything here.

Please correct me if the subject fixing is not correct.

I tried to remove AI_ADDRCONFIG from TCP listen.

Result:

# qemu-kvm -vnc localhost:0 -> still only listen IPV4
# qemu-kvm -vnc :0 -> still only listen IPV4

(In reply to Alexandre Oliva from comment #2)
> From bug 1098659 comment 9, I assume libvirt explicitly uses AI_ADDRCONFIG
> as a hint.  In this case, discarding IPv4 addresses found, when only IPv6
> addresses and IPv4 loopback addresses are configured, is the expected
> behavior of getaddrinfo per RFC 3493.  It is possible that future releases
> of glibc revisit this behavior, because it conflicts with POSIX, but I don't
> envision our making such major changes to getaddrinfo behavior in current
> releases, so I'm inclined to recommend libvirt to drop AI_ADDRCONFIG for
> now, if the problem remains, although bug 796043 seems to indicate it was
> fixed.

Libvirt doesn't create the VNC socket, it only checks for available ports without ADDRCONFIG, so the problem with binding to 127.0.0.1 here is in QEMU.

ADDRCONFIG is still used for listening and connecting in libvirt (but it was dropped for listening to wildcard an localhost addresses in RHEL-7 for bug 1098659). This is used for the daemon listen socket and connecting to the destination QEMU when migrating, which don't seem that useful to do with localhost.

(In reply to Amos Kong from comment #5)
> Please correct me if the subject fixing is not correct.
> 
> I tried to remove AI_ADDRCONFIG from TCP listen.
> 
> Result:
> 
> # qemu-kvm -vnc localhost:0 -> still only listen IPV4
> # qemu-kvm -vnc :0 -> still only listen IPV4

Two sockets are needed to listen on both IPv4 and IPv6 localhost, there is a RFE for qemu: bug 1038963

It is correct to remove AI_ADDRCONFIG from any getaddrinfo queries for listening on sockets even though it may not fix your particular issue. The rest will be covered by Alexander in his new proposal regarding AI_PASSIVE and address ordering.

(In reply to Pavel Šimerda (pavlix) from comment #7)
> It is correct to remove AI_ADDRCONFIG from any getaddrinfo queries for
> listening on sockets even though it may not fix your particular issue. The
> rest will be covered by Alexander in his new proposal regarding AI_PASSIVE
> and address ordering.

Removing AI_ADDRCONFIG in qemu for listening tcp sockets doesn't change
behavior.  We can do that in upstream qemu if it is the CorrectThing[tm].

I no reason to bother downstream though, picking up with the next rhel7 qemu rebase will do IMO.

Upstream fix for AI_ADDRCONFIG (in 2.4.0):
3de3d69 util/qemu-sockets: improve ai_flag hints for ipv6 hosts

Let's pick it up with the 7.3 rebase ...

(In reply to Gerd Hoffmann from comment #10)
> Upstream fix for AI_ADDRCONFIG (in 2.4.0):
> 3de3d69 util/qemu-sockets: improve ai_flag hints for ipv6 hosts
> 
> Let's pick it up with the 7.3 rebase ...

We are at 2.5.0 meanwhile, so it's handled now.

Note: this fixes the issue discussed in comment 7+8, vnc not supporting ipv4 + ipv6 at the same time is tracked in separate bug 1038963.

Hi Gerd,

Could you tell QE how to verify this bug? Maybe something queried from strace? As the errata will reach the deadline, please help to provide information ASAP, thanks!

BR/
Guo, Zhiyi

(In reply to Guo, Zhiyi from comment #14)
> Hi Gerd,
> 
> Could you tell QE how to verify this bug? Maybe something queried from
> strace? As the errata will reach the deadline, please help to provide
> information ASAP, thanks!

Easiest is checking the source code I think.

This call goes to the dns resolver in glibc, it wouldn't be directly visible in a system call trace.

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.

https://rhn.redhat.com/errata/RHBA-2016-2673.html