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.
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.
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 ?
I don't recall and the box is down at the moment. Toure, can you answer those questions?
Jan, if there is nothing that libvirt can do about this, please document the behavior thoroughly on the upstream Troubleshooting page.
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.
libvirt needs to change flags for getaddrinfo hints.ai_flags = AI_PASSIVE | AI_ADDRCONFIG; The flag AI_ADDRCONFIG is causing the issue.
The issue is libvirt being called before the addresses are assigned.
Apparently After=network.target is not enough to get the addresses assigned:
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.
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.
(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:
> 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.
I have proposed a patch that removes ADDRCONFIG from hints for wildcard addresses:
Now pushed upstream:
Author: Ján Tomko <firstname.lastname@example.org>
AuthorDate: 2014-05-29 11:21:25 +0200
Commit: Ján Tomko <email@example.com>
CommitDate: 2014-06-02 17:12:01 +0200
Don't use AI_ADDRCONFIG when binding to wildcard addresses
With parallel boot, network addresses might not yet be assigned ,
but binding to wildcard addresses should work.
For non-wildcard addresses, ADDRCONFIG is still used. Document this
git describe: v1.2.5-9-g819ca36
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
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:
I don't know if it's the same issue as in bug 997106, as I'm unable to reproduce it.
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.
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.