RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1112692 - 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: 1098659
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-24 13:41 UTC by Jan Kurik
Modified: 2022-07-09 06:34 UTC (History)
13 users (show)

Fixed In Version: libvirt-1.1.1-29.el7_0.1
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: 1098659
Environment:
Last Closed: 2014-07-22 18:31:30 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2014:0914 0 normal SHIPPED_LIVE Moderate: libvirt security and bug fix update 2014-07-22 22:31:05 UTC

Description Jan Kurik 2014-06-24 13:41:04 UTC
This bug has been copied from bug #1098659 and has been proposed
to be backported to 7.0 z-stream (EUS).

Comment 6 zhenfeng wang 2014-07-08 10:58:31 UTC
I can reproduce this bug with libvirt-1.1.1-29.el7.x86_64, the following were my reproduce and verify steps
Reproduce steps
pkg info
libvirt-1.1.1-29.el7.x86_64

steps
1.Get the libvirtd to Listen the tcp port
Edit /etc/sysconfig/libvirtd
LIBVIRTD_ARGS="--listen"

Edit /etc/libvirt/libvirtd.conf
listen_tls = 0
listen_tcp=1
auth_tcp=none

#service libvirtd restart

2.Check the libvirtd listen port

# netstat -tunlp|grep libvirtd
tcp  0 0    0.0.0.0:16509 0.0.0.0:* LISTEN 2520/libvirtd
tcp6 0 0    :::16509      :::*      LISTEN 2520/libvirtd

3.cp /bin/true /usr/sbin/dhclient

4.Disable the NetworkManager service
#systemctl disable NetworkManager

5.Reboot the host
#reboot

6.check the libvirt listen address while the host reboot successfully, only the ipv6 addr was listened
#netstat -tunlp|grep libvirtd
tcp6 0 0 :::16509 :::* LISTEN 1300/libvirtd

7.Restart the libvirtd service, both ipv4 and ipv6 addr was listened
netstat -tunlp|grep libvirtd
tcp  0 0    0.0.0.0:16509 0.0.0.0:* LISTEN 2520/libvirtd
tcp6 0 0    :::16509      :::*      LISTEN 2520/libvirtd



Verify this bug with libvirt-1.1.1-29.el7_0.1
Verify steps
Scenario 1
1.Update the libvirt with the scratch build  libvirt-1.1.1-29.el7_0addrconfig.x86_64
2.Excute the reproduce steps, after the host finish reboot, both the ipv4 and ipv6 address were listend by libvirtd
# netstat -tunlp|grep libvirtd
tcp        0      0 0.0.0.0:16509           0.0.0.0:*               LISTEN      2635/libvirtd       
tcp6       0      0 :::16509                :::*                    LISTEN      2635/libvirtd     

3.Restart the libvirtd service, re-check the libvirtd listen port
#service libvirtd restart

# netstat -tunlp|grep libvirtd
tcp        0      0 0.0.0.0:16509           0.0.0.0:*               LISTEN      2838/libvirtd       
tcp6       0      0 :::16509                :::*                    LISTEN      2838/libvirtd       


Scenario 2
Disable the ipv6 on the host, then excute the reproduce steps, after the host finish reboot, both the ipv4 and ipv6 address were listened
and the libvirtd running correctly.
1.Edit the /etc/sysctl.conf
net.ipv6.conf.all.disable_ipv6 = 1

2.Excute the step 1~5 in the reproduce steps

3.Check the libvirtd listen port while the host finish reboot

# netstat -tunlp|grep libvirtd
tcp        0      0 0.0.0.0:16509           0.0.0.0:*               LISTEN      2768/libvirtd       
tcp6       0      0 :::16509                :::*                    LISTEN      2768/libvirtd

4.Restart libvirtd service , re-check the libvirtd listen port, both ipv4 and ipv6 address will be listened by libvirtd
# netstat -tunlp|grep libvirtd
tcp        0      0 0.0.0.0:16509           0.0.0.0:*               LISTEN      3004/libvirtd       
tcp6       0      0 :::16509                :::*                    LISTEN      3004/libvirtd 

scenario 3
Set the listen_addr in the libvirtd.conf, check that both ipv4 and ipv6 can be listened alone correctly
1.Configure the static ipv6 address for the host
#vim /etc/sysconfig/network-scripts/ifcfg-eno1
IPV6INIT=yes
IPV6ADDR=2001::1

#vim /etc/sysconfig/network
NETWORKING_IPV6=yes

# ip addr show eno1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether e8:39:35:4b:fe:ea brd ff:ff:ff:ff:ff:ff
    inet 10.66.6.134/22 brd 10.66.7.255 scope global dynamic eno1
       valid_lft 85840sec preferred_lft 85840sec
    inet6 2001::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::ea39:35ff:fe4b:feea/64 scope link 
       valid_lft forever preferred_lft forever

2.Get the libvirtd to Listen the tcp port, you can reference the step1 in reproduce steps

3.Set libvirtd listen the ipv4 addr
Edit /etc/libvirt/libvirtd.conf
listen_addr = "10.66.6.134
#service libvirtd restart

4.Check the libvirtd listen port
# netstat -tunlp|grep libvirtd
tcp        0      0 10.66.6.134:16509       0.0.0.0:*               LISTEN      2819/libvirtd

5.Connect the libvirtd via ipv4 with tcp connection, will successfully connect the libvirtd with ipv4 address and
will fail to connect the libvirtd with ipv6 address
#virsh -c qemu+tcp://10.66.6.134/system
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh # net-list --all
 Name                 State      Autostart     Persistent
----------------------------------------------------------
 default              active     yes           yes
 
# virsh -c qemu+tcp://[2001::1]/system
error: failed to connect to the hypervisor
error: unable to connect to server at '2001::1:16509': Connection refused

6.Reboot the host,after host finish reboot,then re-excute step 4~5, get the same result with it

7.Set libvirtd listen the ipv6 addr 
Edit /etc/libvirt/libvirtd.conf
listen_addr = "2001::1"
#service libvirtd restart

8.Check the libvirtd listen port
# netstat -tunlp|grep libvirtd
tcp6       0      0 2001::1:16509           :::*                    LISTEN      2984/libvirtd 

9.Connect the libvirtd with tcp connection, will successuflly connect the libvirtd with ipv6 address and
will fail to connect the libvirtd with ipv4 address
# virsh -c qemu+tcp://[2001::1]/system
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh # net-list --all
 Name                 State      Autostart     Persistent
----------------------------------------------------------
 default              active     yes           yes

# virsh -c qemu+tcp://10.66.6.134/system
error: failed to connect to the hypervisor
error: unable to connect to server at '10.66.6.134:16509': Connection refused

10.Reboot the host,after the host finish reboot, find the libvirtd fail to start and it report the following
error in the libvirtd.log, The reason libvirtd fail to start was that we haven't got the ipv6 address assigned before
libvirtd listen on it. Originally, we can solve this issue by NetworkManager-wait-online serivce, however, that was another 
NetworkManager issue which block the NetworkManager-wait-online service that the host can't get the ipv6 address while 
the NetworkManager service was in running status, the issue is similar with this bug https://bugzilla.redhat.com/show_bug.cgi?id=997106,
so we can't verify this scenario currently. i will re-try this scenario while that issue fixed.

#reboot

After the host finish reboot
# ps aux|grep libvirtd

# netstat -tunlp|grep libvirtd

#cat /var/log/libvirt/libvirtd.log
2014-06-10 11:14:34.985+0000: 1401: info : libvirt version: 1.1.1, package: 29.el7_0addrconfig (Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>, 2014-06-02-10:15:32, x86-021.build.eng.bos.redhat.com)
2014-06-10 11:14:34.985+0000: 1401: error : virNetSocketNewListenTCP:302 : Unable to bind to port: Cannot assign requested address

#service libvirtd restart
Redirecting to /bin/systemctl restart  libvirtd.service

# ps aux|grep libvirtd
root      2629  0.8  0.2 466220 17452 ?        Ssl  19:18   0:00 /usr/sbin/libvirtd --listen

# netstat -tunlp|grep libvirtd
tcp6       0      0 2001::1:16509           :::*                    LISTEN      2629/libvirtd

Comment 7 zhenfeng wang 2014-07-09 10:36:33 UTC
The comment6's steps should be enough to verify this bug, will re-try scenario 3 while that the issue  was fixed in comment6.

Comment 9 errata-xmlrpc 2014-07-22 18:31: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.

http://rhn.redhat.com/errata/RHSA-2014-0914.html


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