I started looking into this after seeing FAIL: virnetsockettest ====================== TEST: virnetsockettest 1) Socket TCP/IPv4 Accept ... libvirt: XML-RPC error : Unable to resolve address '127.0.0.1' service '5672': Address family for hostname not supported FAILED 2) Socket TCP/IPv6 Accept ... OK 3) Socket TCP/IPv4+IPv6 Accept ... OK 4) Socket TCP/IPv4+IPv6 Accept ... OK 5) Socket UNIX Accept ... OK 6) Socket UNIX Addrs ... OK 7) Socket External Command /dev/zero ... OK 8) Socket External Command /dev/does-not-exist ... libvirt: XML-RPC error : End of file while reading data: /bin/cat: /dev/does-not-exist: No such file or directory: Input/output error OK 9) SSH test 1 ... OK 10) SSH test 2 ... OK 11) SSH test 3 ... OK 12) SSH test 4 ... libvirt: XML-RPC error : End of file while reading data: Cannot connect to host nosuchhost: Input/output error OK 13) SSH test 5 ... libvirt: XML-RPC error : End of file while reading data: : Input/output error OK 14) SSH test 6 ... OK 15) SSH test 7 ... OK during a Debian package build. Full log: https://buildd.debian.org/status/fetch.php?pkg=libvirt&arch=armel&ver=6.4.0-2&stamp=1594738948&raw=0 Just a few days ago, this issue was discussed in https://lists.debian.org/debian-devel/2020/07/msg00070.html and libvirt was mentioned explicitly as a package that could be affected by it. Reproducing the issue is quite simple: just remove all IPv4 addresses *except* the one assigned to 'lo', and you'll see it immediately. The problem seems to be that, in this configuration, virNetSocketCheckProtocols() reports that both IPv4 and IPv6 are available, but XML-RPC is apparently not happy with that. I'm pretty bad at networking, so I'm reporting this in the hope that someone else will figure it out O:-) Anyway, there's another scenario that I found while digging: if you remove *all* IPv4 addresses, *including* the one assigned to 'lo', you get a different failure. My patch addresses this last one. Andrea Bolognani (2): tests: Don't assume IPv4 connectivity is available tests: Minimize variable scope tests/virnetsockettest.c | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) -- 2.25.4
On 7/14/20 10:32 PM, Andrea Bolognani wrote: > I started looking into this after seeing > > FAIL: virnetsockettest > ====================== > > TEST: virnetsockettest > 1) Socket TCP/IPv4 Accept ... libvirt: XML-RPC error : Unable to resolve address '127.0.0.1' service '5672': Address family for hostname not supported > FAILED > > during a Debian package build. > > Full log: > > https://buildd.debian.org/status/fetch.php?pkg=libvirt&arch=armel&ver=6.4.0-2&stamp=1594738948&raw=0 > > Just a few days ago, this issue was discussed in > > https://lists.debian.org/debian-devel/2020/07/msg00070.html > > and libvirt was mentioned explicitly as a package that could be > affected by it. Indeed. I'm able to reproduce and working on a fix as we speak. The problem is that our test assumes that if there is an interface with IPv4 address (as returned by getifaddrs()) then getaddrinfo() of an IPv4 address succeeds. We've seen with IPv6 that it is not true - that's why virNetSocketCheckProtocols() does explicit getaddrinfo() for an IPv6 address. We need to do the same for IPv4. Anyway, for these two: Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Michal
On Wed, 2020-07-15 at 12:38 +0200, Michal Privoznik wrote: > On 7/14/20 10:32 PM, Andrea Bolognani wrote: > > I started looking into this after seeing > > > > FAIL: virnetsockettest > > ====================== > > > > TEST: virnetsockettest > > 1) Socket TCP/IPv4 Accept ... libvirt: XML-RPC error : Unable to resolve address '127.0.0.1' service '5672': Address family for hostname not supported > > FAILED > > during a Debian package build. > > > > Full log: > > > > https://buildd.debian.org/status/fetch.php?pkg=libvirt&arch=armel&ver=6.4.0-2&stamp=1594738948&raw=0 > > > > Just a few days ago, this issue was discussed in > > > > https://lists.debian.org/debian-devel/2020/07/msg00070.html > > > > and libvirt was mentioned explicitly as a package that could be > > affected by it. > > Indeed. I'm able to reproduce and working on a fix as we speak. > The problem is that our test assumes that if there is an interface with > IPv4 address (as returned by getifaddrs()) then getaddrinfo() of an IPv4 > address succeeds. We've seen with IPv6 that it is not true - that's why > virNetSocketCheckProtocols() does explicit getaddrinfo() for an IPv6 > address. We need to do the same for IPv4. That's what I thought needed to happen, but I lack the networking know-how to write the patches myself O:-) > Anyway, for these two: > > Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Thanks, pushed now. -- Andrea Bolognani / Red Hat / Virtualization
© 2016 - 2024 Red Hat, Inc.