Bug 1098659
Summary: | libvirt binds only to ipv6 | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Dave Allan <dallan> | |
Component: | libvirt | Assignee: | Ján Tomko <jtomko> | |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | |
Severity: | unspecified | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 7.0 | CC: | berrange, dyuan, jkurik, jtomko, lbezdick, mzhan, rbalakri, tdosek, tdunnon, ydu, zhwang | |
Target Milestone: | rc | Keywords: | ZStream | |
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
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.
|
Story Points: | --- | |
Clone Of: | ||||
: | 1112692 (view as bug list) | Environment: | ||
Last Closed: | 2015-03-05 07:35:30 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1112692 |
Description
Dave Allan
2014-05-16 20:49:20 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. 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: 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. 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: > 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. I have proposed a patch that removes ADDRCONFIG from hints for wildcard addresses: https://www.redhat.com/archives/libvir-list/2014-May/msg01009.html Now pushed upstream: commit 819ca36e2b65a0a34263547161a98cec497780c8 Author: Ján Tomko <jtomko> AuthorDate: 2014-05-29 11:21:25 +0200 Commit: Ján Tomko <jtomko> 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 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 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. 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. https://rhn.redhat.com/errata/RHSA-2015-0323.html |