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 1192318 - support IPv6 in listen type network
Summary: support IPv6 in listen type network
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.1
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Ján Tomko
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-02-13 06:52 UTC by Luyao Huang
Modified: 2015-11-19 06:15 UTC (History)
5 users (show)

Fixed In Version: libvirt-1.2.15-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 06:15:31 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2202 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2015-11-19 08:17:58 UTC

Description Luyao Huang 2015-02-13 06:52:00 UTC 
description of problem:
libvirt should support listen type network with ipv6

Version-Release number of selected component (if applicable):
libvirt-1.2.8-16.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
 
1.prepare a network use ipv6 family:

# virsh net-dumpxml ipv6
<network connections='1'>
  <name>ipv6</name>
  <uuid>7ba66277-91b2-45b0-810b-f3620b924790</uuid>
  <forward mode='nat'/>
  <bridge name='virbr6' stp='on' delay='0'/>
  <mac address='52:54:00:467:af'/>
  <ip family='ipv6' address='2001b8:ca2:2::1' prefix='64'>
    <dhcp>
      <range start='2001b8:ca2:2:1::10' end='2001b8:ca2:2:1::ff'/>
    </dhcp>
  </ip>
</network>

2.set vm xml like this:

    <graphics type='spice' autoport='yes'>
      <listen type='network' network='ipv6'/>
    </graphics>

3.start vm:
# virsh start test4
error: Failed to start domain test4
error: XML error: listen network 'ipv6' had no usable address


Actual results:
libvirt report a error: network 'ipv6' had no usable address

however it has a ipv6 address and can be used.

Expected results:
libvirt should support listen type network with ipv6

infomation:

qemu and spice and vnc already support ipv6 address.

if have setting like this:
    <graphics type='spice' port='5900' autoport='yes' listen='2001b8:ca2:2::1' keymap='en-us'>
      <listen type='address' address='2001b8:ca2:2::1'/>
    </graphics>

vm will start success and can connect to spice server via ipv6 address
Additional info:
Comment 1 Ján Tomko 2015-02-13 08:16:35 UTC 
Patches referencing this bug have been posted upstream:
https://www.redhat.com/archives/libvir-list/2015-February/msg00442.html
Comment 2 Ján Tomko 2015-04-08 15:36:26 UTC 
v4 of the patches:
https://www.redhat.com/archives/libvir-list/2015-April/msg00306.html
Comment 3 Ján Tomko 2015-04-10 13:13:50 UTC 
Fixed upstream by:
commit 031323830d650a7396627701c16a8667b4f9c783
Author:     Ján Tomko <jtomko>
CommitDate: 2015-04-10 15:01:17 +0200

    Support IPv6 in networkGetNetworkAddress
    
    We've been explicitly requesting IPv4 for some reason,
    even if there were only IPv6 addresses in the network
    definition.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1192318

commit 2605089c0450c47dc2e696c9be2bb75183d93b91
Author:     Luyao Huang <lhuang>
CommitDate: 2015-04-10 15:01:17 +0200

    util: Update virNetDevGetIPAddress to get IPv6 addresses
    
    Add static virNetDevGetifaddrsAddress to attempt to get the interface
    IP address. If getifaddrs is not supported, fall back to
    virNetDevGetIPv4AddressIoctl to get the IP address.
    
    This allows IPv6 addresses to be used for <listen type='network>
    with device-backed networks.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1192318
    
    Signed-off-by: Luyao Huang <lhuang>
    Signed-off-by: John Ferlan <jferlan>
    Signed-off-by: Ján Tomko <jtomko>

git describe: v1.2.14-104-g0313238
Comment 5 vivian zhang 2015-06-02 08:35:48 UTC 
I can produce this bug with build libvirt-1.2.8-16.el7.x86_64

verify this with build libvirt-1.2.15-2.el7.x86_64


Steps:

1. prepare a network with ipv6 family address and start it

# virsh net-dumpxml ipv6
<network>
  <name>ipv6</name>
  <uuid>7ba66277-91b2-45b0-810b-f3620b924790</uuid>
  <forward mode='nat'/>
  <bridge name='virbr6' stp='on' delay='0'/>
  <mac address='52:54:00:46:07:af'/>
  <ip family='ipv6' address='2001:b8:ca2:2::1' prefix='64'>
    <dhcp>
      <range start='2001:b8:ca2:2:1::10' end='2001:b8:ca2:2:1::ff'/>
    </dhcp>
  </ip>
</network>

2. edit guest spice listen type=network
# virsh edit vm1
...
    <graphics type='spice' autoport='yes'>
      <listen type='network' network='ipv6'/>
    </graphics>
...

3. start guest, dumpxml

# virsh start vm1
Domain vm1 started

# virsh domdisplay vm1
spice://[2001:b8:ca2:2::1]:5901

# virsh dumpxml vm1
...
<graphics type='spice' port='5901' autoport='yes' listen='2001:b8:ca2:2::1'>
      <listen type='network' address='2001:b8:ca2:2::1' network='ipv6'/>
    </graphics>
...

4. connect guest with remote-viewer success
# remote-viewer spice://[2001:b8:ca2:2::1]:5901


5. use network with forward mode='route' 'vepa' also success
# virsh net-dumpxml br2
<network connections='1'>
  <name>br2</name>
  <uuid>07524203-49d5-4947-bfad-b0d1d63beb7a</uuid>
  <forward mode='route'/>
  <bridge name='br2' stp='on' delay='0'/>
  <mac address='52:54:00:ad:88:b3'/>
  <ip family='ipv6' address='2002:b8:ca2:2::1' prefix='64'>
    <dhcp>
      <range start='2002:b8:ca2:2:1::10' end='2002:b8:ca2:2:1::ff'/>
    </dhcp>
  </ip>
</network>

# virsh net-dumpxml vepa-net
<network>
  <name>vepa-net</name>
  <uuid>d7c0d06b-08f9-4bad-a126-ce1932151704</uuid>
  <forward dev='br2' mode='vepa'>
    <interface dev='br2'/>
  </forward>
</network>

move to verified
Comment 6 zhenfeng wang 2015-10-15 09:58:57 UTC 
Hi Jan

I have a doubt about this new function that while start a ipv6 network, there will have a new virtual interface created in the pysical host which got a globel ipv6 address from the ipv6 network, however, the virtual interface won't got a link local address like fe80 address automatically, this will lead the guest fail to bind the ipv6 network during we start the guest which graphical buffer bind to ipv6 network, so the question is coming, should libvirt or qemu could assign a fe80 link address to the virtual interface automatically  while we start the ipv6 network? 

steps
1.Prepare a xml for ipv6 network
#cat ipv6-net.xml
<network ipv6='yes'>
  <name>ipv6-net</name>
  <uuid>7ba66277-91b2-45b0-810b-f3620b924790</uuid>
  <forward mode='nat'/>
  <bridge name='virbr6' stp='on' delay='0'/>
  <mac address='52:54:00:46:07:af'/>
  <ip family='ipv6' address='2001:b8:ca2:2::1' prefix='64'>
    <dhcp>
      <range start='2001:b8:ca2:2:1::10' end='2001:b8:ca2:2:1::ff'/>
    </dhcp>
  </ip>
</network>


2.Define the network and start it, after start it, we could find the a new virtual interface created
in the physcial host, however the interface have no linklocal address(fe80 address) assigned
#virsh define ipv6.xml
# virsh net-start ipv6-net
Network ipv6-net started

# ifconfifg
--

virbr6: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet6 2001:b8:ca2:2::1  prefixlen 64  scopeid 0x0<global>
        ether 52:54:00:46:07:af  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

3.Start a guest which graphical buffer listen on ipv6 network, guest will fail to start since 
failed to initialize spice server

#virsh dumpxml rhel72
--
    <graphics type='spice' autoport='yes'>
      <listen type='network' network='ipv6-net'/>
    </graphics>

# virsh start rhel72
error: Failed to start domain rhel72
error: internal error: process exited while connecting to monitor: ((null):21135): Spice-Warning **: reds.c:3107:reds_init_socket: reds_init_socket: binding socket to 2001:b8:ca2:2::1:5900 failed
2015-10-15T09:24:31.904199Z qemu-kvm: failed to initialize spice server



Additional info
The verify steps in comment 5 use following ways to workround the upper issue, but i think we could have a beter way to handle it, how do you think about it?

1.Start a guest which use the previously ipv6 network , after guest start, the virtual interface 
we created during start the ipv6 network will got the fe80 linklocal address automatically

#virsh dumpxml rhel72
--
    <interface type='network'>
      <mac address='52:54:00:8a:21:c7'/>
      <source network='ipv6-net'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
--

 <graphics type='spice' autoport='yes'/>

#virsh start rhel72

#ifconfig 
--
virbr6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::5054:ff:fe46:7af  prefixlen 64  scopeid 0x20<link>
        inet6 2001:b8:ca2:2::1  prefixlen 64  scopeid 0x0<global>
        ether 52:54:00:46:07:af  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7  bytes 866 (866.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

2.Re-start guest which graphical buffer listen on ipv6 network, the guest will start successfully just like the verification steps description in comment5
Comment 7 zhenfeng wang 2015-10-26 10:20:31 UTC 
File a RFE bug for the comment6's issue
https://bugzilla.redhat.com/show_bug.cgi?id=1275232
Comment 9 errata-xmlrpc 2015-11-19 06:15:31 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/RHBA-2015-2202.html
Note You need to log in before you can comment on or make changes to this bug.