Bug 1075520
| Summary: | RFE: libvirt should let you set usernet network address | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Richard W.M. Jones <rjones> |
| Component: | libvirt | Assignee: | Michal Privoznik <mprivozn> |
| Status: | CLOSED ERRATA | QA Contact: | yalzhang <yalzhang> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 7.0 | CC: | berrange, dyuan, dzheng, gsun, laine, lcheng, mprivozn, mtessun, mzhan, rbalakri, rjones, xuzhang, yalzhang |
| Target Milestone: | rc | Keywords: | FutureFeature, Upstream |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | libvirt-3.8.0-1.el7 | Doc Type: | Enhancement |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-04-10 10:33:22 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: | 910269, 1288337 | ||
There are a couple of problematic aspects to adding such a feature: 1) According to the qemu team, usernet is considered unsupported/undesirable (it is also used by gnome-boxes, though). 2) If we add ip address configuration to the <interface type='user'> XML, this will inevitably lead to users incorrectly assuming that it can be specified for other types of interface, then complaining when it doesn't work. Neither of these is necessarily a reason to not implement the feature, but we should probably keep them in mind while doing it. (In reply to Laine Stump from comment #2) > There are a couple of problematic aspects to adding such a feature: > > 1) According to the qemu team, usernet is considered unsupported/undesirable > (it is also used by gnome-boxes, though). No one likes SLIRP, but also no one has come up with anything better ... I should add why we need to set the network to 169.254.0.0/16. The default in upstream qemu is 10.0.2.0/24, see: http://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29 The problem with the qemu default is if a process inside the guest needs to connect to some external site which happens to have address 10.0.2.x. Say for example your home network used this numbering and you had an HTTP proxy on 10.0.2.2. What happens is that attempts to connect to the proxy fail silently because they get "intercepted" by the qemu user network. (And yes, this was reported as a bug by a user of virt-v2v.) 169.254 is a link-local address so no network resource should ever have that address. It is possible this is abuse of link- local addresses, but we're only using it for a gateway and it does avoid the problem above. https://tools.ietf.org/html/rfc3927 It'd be nice if qemu user networking default wasn't using a 10.x address, eg. if it used a real assigned address, but we are where we are now. While slirp networking is horrible and we shouldn't encourage its use, given that QEMU already supports the features libguestfs needs, I don't see a reason not to support it in libvirt too. Not having libguestfs use command line passthrough is a win Patch proposed upstream: https://www.redhat.com/archives/libvir-list/2014-March/msg01778.html *** Bug 1147238 has been marked as a duplicate of this bug. *** libguestfs no longer uses SLIRP with the libvirt backend (still does with the direct backend though). In that case, can we close this one? No, there's at least one other bug marked as a duplicate of this (https://bugzilla.redhat.com/show_bug.cgi?id=1147238#c0). Since we now (thanks to the LXC driver, I think) have a field for ip address in the <interface> element, it should be less problematic to implement (at the same time we should make sure that interface types that don't support setting an IP address properly fail with "not supported"). Yeah, seems we can pretty easily implement this now, and it'd be good to deal with this long standing libguestfs RFE to remove their use of qemu passthrough. Patches proposed upstream: https://www.redhat.com/archives/libvir-list/2017-September/msg00252.html Moving to POST:
commit 8703813aae3de35c2042e26dc1c9556783156529
Author: Michal Privoznik <mprivozn>
AuthorDate: Wed Sep 13 11:16:04 2017 +0200
Commit: Michal Privoznik <mprivozn>
CommitDate: Mon Sep 18 13:54:27 2017 +0200
qemu: Implement usernet address
https://bugzilla.redhat.com/show_bug.cgi?id=1075520
Apart from generic checks, we need to constrain netmask/prefix
length a bit. Thing is, with current implementation QEMU needs to
be able to 'assign' some IP addresses to the virtual network. For
instance, the default gateway is at x.x.x.2, dns is at x.x.x.3,
the default DHCP range is x.x.x.15-x.x.x.30. Since we don't
expose these settings yet, it's safer to require shorter prefix
to have room for the defaults.
Signed-off-by: Michal Privoznik <mprivozn>
Reviewed-by: laine
commit d1dbb3078245b44186f6b3f09b6e66fe98b4bede
Author: Michal Privoznik <mprivozn>
AuthorDate: Wed Sep 13 10:47:52 2017 +0200
Commit: Michal Privoznik <mprivozn>
CommitDate: Mon Sep 18 13:54:27 2017 +0200
conf: Allow usernet to have an address
https://bugzilla.redhat.com/show_bug.cgi?id=1075520
Currently, all that users can specify for an interface type of
'user' is the common attributes: PCI address, NIC model (and
that's basically it). However, some need to configure other
address range than the default one.
Signed-off-by: Michal Privoznik <mprivozn>
Reviewed-by: laine
v3.7.0-96-g8703813aa
1. Ignore the prefix, will got ipv4 prefix as 8, will get:
ip: x.0.2.15;
gw: x.0.2.2;
name server: x.0.2.3;
2. set prefix as 1~3, will get
# virsh start rhel7.4
error: Failed to start domain rhel7.4
error: internal error: qemu unexpectedly closed the monitor: 2017-10-11T07:01:11.960271Z qemu-kvm: -chardev pty,id=charserial0: char device redirected to /dev/pts/3 (label charserial0)
2017-10-11T07:01:11.965456Z qemu-kvm: -netdev user,net=200.100.100.0/1,ipv6-net=2001:db8:ac10:fd01::/64,id=hostnet0: Device 'user' could not be initialized
3. Set prefix as 4~27, will get:
ip: $address & $netmask
gw:
name server:
3. Set prefix as 28, will get error.
# virsh edit rhel7.4
error: XML error: prefix too long
Failed. Try again? [y,n,i,f,?]:
Scenario 1: ignore prefix
# virsh dumpxml rhel7.4 | grep /interface -B7
<interface type='user'>
<mac address='52:54:00:01:55:fe'/>
<ip address='100.100.100.20' family='ipv4'/>
<ip address='2001:db8:ac10:fd01::' family='ipv6'/>
<model type='rtl8139'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
# ifconfig ens3
ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 100.0.2.15 netmask 255.0.0.0 broadcast 100.255.255.255
inet6 fe80::5054:ff:fe01:55fe prefixlen 64 scopeid 0x20<link>
inet6 2001:db8:ac10:fd01:5054:ff:fe01:55fe prefixlen 64 scopeid 0x0<global>
...
Scenario 2: Set prefix
# virsh dumpxml rhel7.4 | grep /interface -B7
<interface type='user'>
<mac address='52:54:00:01:55:fe'/>
<ip address='100.100.100.20' family='ipv4' prefix='24'/>
<ip address='2001:db8:ac10:fd01::' family='ipv6' prefix='64'/>
<model type='rtl8139'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
# ifconfig
ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 100.100.100.15 netmask 255.255.255.0 broadcast 100.100.100.255
inet6 fe80::5054:ff:fe01:55fe prefixlen 64 scopeid 0x20<link>
inet6 2001:db8:ac10:fd01:5054:ff:fe01:55fe prefixlen 64 scopeid 0x0<global>
Sorry for misoperation to leave incomplete comment above for item '3. Set prefix as 4~27', verify on libvirt-3.8.0-1.el7.x86_64
continue as below:
4. Set prefix as 4~27, it works. For example set prefix as 24 with ip '100.100.100.20', will get
ip: 100.100.100.15
gw: 100.100.100.2
name server: 100.100.100.3
set prefix as 4 with ip '100.100.100.20', will get
ip: 96.0.2.15
gw: 96.0.2.2
name server: 96.0.2.3
But it do not check the multicast ip address, when I set "<ip address='224.100.100.20' family='ipv4' prefix='8'/>", guest will get:
ip: 224.0.2.15
gw: N/A
name server: 224.0.2.3
and no access.
when set "<ip address='127.100.100.20' family='ipv4' prefix='8'/>", also no access.
ip: 127.0.2.15
gw: 127.0.2.2
name server: 127.0.2.3
This is acceptable as the one set the ip address 'should' be aware of these special ip address.
5. Set more than 1 ip address for ipv4 or ipv6
# virsh edit rhel7.4
error: unsupported configuration: Only one IPv4 address per interface is allowed
Failed. Try again? [y,n,i,f,?]:
or
error: unsupported configuration: Only one IPv6 address per interface is allowed
Failed. Try again? [y,n,i,f,?]:
6. set ip in other type of interface
# virsh edit rhel7.4
error: unsupported configuration: Invalid attempt to set network interface guest-side IP route and/or address info, not supported by QEMU
Failed. Try again? [y,n,i,f,?]:
7. hotplug succeed
# cat net.xml
<interface type='user'>
<mac address="00:11:22:33:44:55"/>
<ip family='ipv4' address='171.17.2.0' prefix='24'/>
<ip family='ipv6' address='2002:db8:ac10:fd01::' prefix='64'/>
</interface>
# virsh attach-device rhel7.4 net.xml
Device attached successfully
Hi Michal, Could you please help to confirm comment 22 item 4? It do not check the multicast ip address and ip address like 127.x.x.x/24, which cause the guest no access, this is acceptable, right? because the one who set this should be aware of the special address. (In reply to yalzhang from comment #23) > Hi Michal, Could you please help to confirm comment 22 item 4? > It do not check the multicast ip address and ip address like 127.x.x.x/24, > which cause the guest no access, this is acceptable, right? Yes, you're right. > because the one > who set this should be aware of the special address. Exactly. 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://access.redhat.com/errata/RHEA-2018:0704 |
Description of problem: libguestfs has this code: /* Workaround because libvirt user networking cannot specify "net=" * parameter. */ if (g->enable_network) { start_element ("qemu:arg") { attribute ("value", "-netdev"); } end_element (); start_element ("qemu:arg") { attribute ("value", "user,id=usernet,net=169.254.0.0/16"); } end_element (); start_element ("qemu:arg") { attribute ("value", "-device"); } end_element (); start_element ("qemu:arg") { attribute ("value", VIRTIO_NET ",netdev=usernet"); } end_element (); } This exists because there's no way using libvirt XML to set the libvirt usernet (SLIRP) network address (net=...) Version-Release number of selected component (if applicable): libvirt 1.1.1-25.el7.x86_64