Bug 1075520 - RFE: libvirt should let you set usernet network address
Summary: RFE: libvirt should let you set usernet network address
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.0
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: Michal Privoznik
QA Contact: yalzhang@redhat.com
URL:
Whiteboard:
: 1147238 (view as bug list)
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs 1288337
TreeView+ depends on / blocked
 
Reported: 2014-03-12 10:26 UTC by Richard W.M. Jones
Modified: 2018-04-10 10:35 UTC (History)
13 users (show)

Fixed In Version: libvirt-3.8.0-1.el7
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-10 10:33:22 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:0704 None None None 2018-04-10 10:35:51 UTC

Description Richard W.M. Jones 2014-03-12 10:26:54 UTC
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

Comment 2 Laine Stump 2014-03-26 14:30:04 UTC
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.

Comment 3 Richard W.M. Jones 2014-03-26 14:36:00 UTC
(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 ...

Comment 4 Richard W.M. Jones 2014-03-26 14:43:47 UTC
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.

Comment 5 Daniel Berrangé 2014-03-26 15:25:50 UTC
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

Comment 6 Michal Privoznik 2014-03-27 17:46:11 UTC
Patch proposed upstream:

https://www.redhat.com/archives/libvir-list/2014-March/msg01778.html

Comment 8 Ján Tomko 2015-05-15 11:44:14 UTC
*** Bug 1147238 has been marked as a duplicate of this bug. ***

Comment 10 Richard W.M. Jones 2015-08-27 16:27:31 UTC
libguestfs no longer uses SLIRP with the libvirt backend (still
does with the direct backend though).

Comment 11 Michal Privoznik 2015-08-28 04:10:51 UTC
In that case, can we close this one?

Comment 12 Richard W.M. Jones 2015-08-28 07:32:47 UTC
No, there's at least one other bug marked as a duplicate of
this (https://bugzilla.redhat.com/show_bug.cgi?id=1147238#c0).

Comment 13 Laine Stump 2015-08-28 12:59:34 UTC
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").

Comment 14 Daniel Berrangé 2015-08-28 13:02:05 UTC
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.

Comment 17 Michal Privoznik 2017-09-12 09:37:34 UTC
Patches proposed upstream:

https://www.redhat.com/archives/libvir-list/2017-September/msg00252.html

Comment 18 Michal Privoznik 2017-09-13 10:48:49 UTC
Another attempt:

https://www.redhat.com/archives/libvir-list/2017-September/msg00308.html

Comment 19 Michal Privoznik 2017-09-18 11:58:59 UTC
Moving to POST:

commit 8703813aae3de35c2042e26dc1c9556783156529
Author:     Michal Privoznik <mprivozn@redhat.com>
AuthorDate: Wed Sep 13 11:16:04 2017 +0200
Commit:     Michal Privoznik <mprivozn@redhat.com>
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@redhat.com>
    Reviewed-by: laine@laine.org

commit d1dbb3078245b44186f6b3f09b6e66fe98b4bede
Author:     Michal Privoznik <mprivozn@redhat.com>
AuthorDate: Wed Sep 13 10:47:52 2017 +0200
Commit:     Michal Privoznik <mprivozn@redhat.com>
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@redhat.com>
    Reviewed-by: laine@laine.org

v3.7.0-96-g8703813aa

Comment 21 yalzhang@redhat.com 2017-10-11 07:12:19 UTC
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>

Comment 22 yalzhang@redhat.com 2017-10-11 07:57:44 UTC
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

Comment 23 yalzhang@redhat.com 2017-10-11 09:29:47 UTC
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.

Comment 24 Michal Privoznik 2017-10-25 10:19:22 UTC
(In reply to yalzhang@redhat.com 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.

Comment 28 errata-xmlrpc 2018-04-10 10:33:22 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://access.redhat.com/errata/RHEA-2018:0704


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