Bug 1192318
Summary: | support IPv6 in listen type network | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Luyao Huang <lhuang> |
Component: | libvirt | Assignee: | Ján Tomko <jtomko> |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.1 | CC: | dyuan, jtomko, mzhan, rbalakri, zhwang |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | libvirt-1.2.15-1.el7 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-11-19 06:15:31 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: |
Description
Luyao Huang
2015-02-13 06:52:00 UTC
Patches referencing this bug have been posted upstream: https://www.redhat.com/archives/libvir-list/2015-February/msg00442.html v4 of the patches: https://www.redhat.com/archives/libvir-list/2015-April/msg00306.html 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 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 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 File a RFE bug for the comment6's issue https://bugzilla.redhat.com/show_bug.cgi?id=1275232 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 |