Bug 1098659 - libvirt binds only to ipv6
Summary: libvirt binds only to ipv6
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Ján Tomko
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 1112692
TreeView+ depends on / blocked
 
Reported: 2014-05-16 20:49 UTC by Dave Allan
Modified: 2016-04-26 14:06 UTC (History)
11 users (show)

Fixed In Version: libvirt-1.2.7-1.el7
Doc Type: Bug Fix
Doc Text:
Cause: Libvirt was only binding to addresses that are configured on some network interfaces. Consequence: Libvirt only listened on ipv6 if it started before ipv4 addresses were configured. Fix: Don't require the address to be configured when binding to the wildcard address (0.0.0.0 or ::) Result: Libvirtd binds to both ipv4 and ipv6.
Clone Of:
: 1112692 (view as bug list)
Environment:
Last Closed: 2015-03-05 07:35:30 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1064176 unspecified CLOSED qpidd binds only to ipv6 after reboot 2021-01-20 06:05:38 UTC
Red Hat Product Errata RHSA-2015:0323 normal SHIPPED_LIVE Low: libvirt security, bug fix, and enhancement update 2015-03-05 12:10:54 UTC

Internal Links: 1064176

Description Dave Allan 2014-05-16 20:49:20 UTC
Toure and I were troubleshooting an unrelated OpenStack issue and noticed that when we restarted the host on which libvirtd was running that libvirtd came up listening only on ipv6.  Restarting libvirtd caused it to bind to ipv4 correctly.  I have not tried to reproduce the behavior, but I'm concerned that we may have a race in which ipv4 is not available when libvirtd starts with the result that we observed.  I realize this is a pretty spare report, so if there are questions I can answer, I'd be happy to do so.

Comment 1 Daniel Berrangé 2014-05-17 18:21:34 UTC
I saw this on a QA host a few weeks back which was mistakenly running NetworkManager - NM shouldn't be run on any Neutron or nova-network enabled hosts, since they'll play badly together.

Comment 2 Daniel Berrangé 2014-05-19 10:00:16 UTC
Opps, forgot needinfo - can you say whether the host you saw this on was running NetworkManager, and whether it had neutron or nova-network present too ?

Comment 3 Dave Allan 2014-05-19 14:45:06 UTC
I don't recall and the box is down at the moment.  Toure, can you answer those questions?

Comment 4 Dave Allan 2014-05-19 14:46:36 UTC
Jan, if there is nothing that libvirt can do about this, please document the behavior thoroughly on the upstream Troubleshooting page.

Comment 5 Toure Dunnon 2014-05-19 15:28:02 UTC
Unfortunately I have already started a second install, but once it completes I will make sure the following will be configured:

1. NetworkManager is disabled.
2. libvirt is added to the firewalld zone
3. The config file Dan and I worked on will be reused as well as the packstack answer file to keep things consistent.

Comment 9 Lukas Bezdicka 2014-05-27 16:11:59 UTC
libvirt needs to change flags for getaddrinfo hints.ai_flags = AI_PASSIVE | AI_ADDRCONFIG; The flag AI_ADDRCONFIG is causing the issue.

Comment 10 Ján Tomko 2014-05-28 10:56:10 UTC
The issue is libvirt being called before the addresses are assigned.

Apparently After=network.target is not enough to get the addresses assigned:
http://www.freedesktop.org/software/systemd/man/systemd.special.html#network-online.target
http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

For the four "universally available" addresses (0.0.0.0, ::, 127.0.0.1, ::1), removing ADDRCONFIG could result in libvirt failing on hosts with IPv6 compiled out or disabled via sysctl.

But for all the other listen addresses/hostnames, we would have to use IP_FREEBIND and give up error reporting for unavailable addresses.

I think adding 'After=network-online.target' to libvirtd's service file is the fix here.

Comment 11 Daniel Berrangé 2014-05-28 11:04:34 UTC
Adding After=network-online.target is going to delay startup of libvirtd on all hosts, even when libvirtd is only wanting to listen on UNIX sockets, so I don't think that's something we can do.

Comment 12 Lukas Bezdicka 2014-05-28 11:18:13 UTC
(In reply to Jan Tomko from comment #10)
> The issue is libvirt being called before the addresses are assigned.
> 
> Apparently After=network.target is not enough to get the addresses assigned:
> http://www.freedesktop.org/software/systemd/man/systemd.special.html#network-
> online.target
> http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
> 
> For the four "universally available" addresses (0.0.0.0, ::, 127.0.0.1,
> ::1), removing ADDRCONFIG could result in libvirt failing on hosts with IPv6
> compiled out or disabled via sysctl.

I would set ADDRCONFIG if nodename id not NULL which means binding to specific address and keep it out for "universally available" addresses. I'm not sure how it would react with ipv6 disabled or ipv6 only but I don't think it would cause that many issues.

> 
> But for all the other listen addresses/hostnames, we would have to use
> IP_FREEBIND and give up error reporting for unavailable addresses.
> 
> I think adding 'After=network-online.target' to libvirtd's service file is
> the fix here.

Comment 13 Ján Tomko 2014-05-29 09:33:50 UTC
I have proposed a patch that removes ADDRCONFIG from hints for wildcard addresses:
https://www.redhat.com/archives/libvir-list/2014-May/msg01009.html

Comment 14 Ján Tomko 2014-06-02 15:32:06 UTC
Now pushed upstream:
commit 819ca36e2b65a0a34263547161a98cec497780c8
Author:     Ján Tomko <jtomko@redhat.com>
AuthorDate: 2014-05-29 11:21:25 +0200
Commit:     Ján Tomko <jtomko@redhat.com>
CommitDate: 2014-06-02 17:12:01 +0200

    Don't use AI_ADDRCONFIG when binding to wildcard addresses
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1098659
    
    With parallel boot, network addresses might not yet be assigned [1],
    but binding to wildcard addresses should work.
    
    For non-wildcard addresses, ADDRCONFIG is still used. Document this
    in libvirtd.conf.
    
    [1] http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

git describe: v1.2.5-9-g819ca36

Comment 27 zhenfeng wang 2014-11-05 13:20:43 UTC
hi Jan
I re-try the comment 18's scenarios with the libvirt-1.2.8-6.el7 and systemd-208-15.el7, however, still get the same result with the comment 18 that the host still can't get the ipv6 address while enable the NetworkManager service , even i enable the NetworkManager-wait-online service. I think this issue should be the same with this bug https://bugzilla.redhat.com/show_bug.cgi?id=997106, right? if it is, then it should be seperate issue with this bug and we could trace the comment18's issue with that bug and mark this bug verified, right? thanks

Comment 28 Ján Tomko 2014-11-05 14:50:51 UTC
Nothing libvirt does should prevent the host from getting a static IPv6 address.
If this is happening to you, it's unlikely to be a libvirt issue.

A static IPv6 added to /etc/sysconfig/network-scripts/ works for me even after restarting the 'network' service with:
NetworkManager-0.9.9.1-47.git20140326.4dba720.el7.x86_64
systemd-208-15.el7.x86_64

I don't know if it's the same issue as in bug 997106, as I'm unable to reproduce it.

Comment 29 zhenfeng wang 2014-11-06 06:49:42 UTC
yes, it also works for me after update the NetworkManager packet to the latest one, so mark this bug verifed, thanks for Jan's help.

Comment 31 errata-xmlrpc 2015-03-05 07:35:30 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.

https://rhn.redhat.com/errata/RHSA-2015-0323.html


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