diff options
Diffstat (limited to 'Documentation/virt/uml/user_mode_linux_howto_v2.rst')
| -rw-r--r-- | Documentation/virt/uml/user_mode_linux_howto_v2.rst | 80 |
1 files changed, 41 insertions, 39 deletions
diff --git a/Documentation/virt/uml/user_mode_linux_howto_v2.rst b/Documentation/virt/uml/user_mode_linux_howto_v2.rst index d1cfe415e4c4..c37e8e594d12 100644 --- a/Documentation/virt/uml/user_mode_linux_howto_v2.rst +++ b/Documentation/virt/uml/user_mode_linux_howto_v2.rst @@ -147,18 +147,12 @@ The image hostname will be set to the same as the host on which you are creating its image. It is a good idea to change that to avoid "Oh, bummer, I rebooted the wrong machine". -UML supports two classes of network devices - the older uml_net ones -which are scheduled for obsoletion. These are called ethX. It also -supports the newer vector IO devices which are significantly faster -and have support for some standard virtual network encapsulations like -Ethernet over GRE and Ethernet over L2TPv3. These are called vec0. +UML supports vector I/O high performance network devices which have +support for some standard virtual network encapsulations like +Ethernet over GRE and Ethernet over L2TPv3. These are called vecX. -Depending on which one is in use, ``/etc/network/interfaces`` will -need entries like:: - - # legacy UML network devices - auto eth0 - iface eth0 inet dhcp +When vector network devices are in use, ``/etc/network/interfaces`` +will need entries like:: # vector UML network devices auto vec0 @@ -217,17 +211,7 @@ remote UML and other VM instances. +-----------+--------+------------------------------------+------------+ | fd | vector | dependent on fd type | varies | +-----------+--------+------------------------------------+------------+ -| tuntap | legacy | none | ~ 500Mbit | -+-----------+--------+------------------------------------+------------+ -| daemon | legacy | none | ~ 450Mbit | -+-----------+--------+------------------------------------+------------+ -| socket | legacy | none | ~ 450Mbit | -+-----------+--------+------------------------------------+------------+ -| pcap | legacy | rx only | ~ 450Mbit | -+-----------+--------+------------------------------------+------------+ -| ethertap | legacy | obsolete | ~ 500Mbit | -+-----------+--------+------------------------------------+------------+ -| vde | legacy | obsolete | ~ 500Mbit | +| vde | vector | dep. on VDE VPN: Virt.Net Locator | varies | +-----------+--------+------------------------------------+------------+ * All transports which have tso and checksum offloads can deliver speeds @@ -236,27 +220,16 @@ remote UML and other VM instances. * All transports which have multi-packet rx and/or tx can deliver pps rates of up to 1Mps or more. -* All legacy transports are generally limited to ~600-700MBit and 0.05Mps. - * GRE and L2TPv3 allow connections to all of: local machine, remote machines, remote network devices and remote UML instances. -* Socket allows connections only between UML instances. - -* Daemon and bess require running a local switch. This switch may be - connected to the host as well. - Network configuration privileges ================================ The majority of the supported networking modes need ``root`` privileges. -For example, in the legacy tuntap networking mode, users were required -to be part of the group associated with the tunnel device. - -For newer network drivers like the vector transports, ``root`` privilege -is required to fire an ioctl to setup the tun interface and/or use -raw sockets where needed. +For example, for vector transports, ``root`` privilege is required to fire +an ioctl to setup the tun interface and/or use raw sockets where needed. This can be achieved by granting the user a particular capability instead of running UML as root. In case of vector transport, a user can add the @@ -575,11 +548,40 @@ https://github.com/NetSys/bess/wiki/Built-In-Modules-and-Ports BESS transport does not require any special privileges. -Configuring Legacy transports -============================= +VDE vector transport +-------------------- + +Virtual Distributed Ethernet (VDE) is a project whose main goal is to provide a +highly flexible support for virtual networking. + +http://wiki.virtualsquare.org/#/tutorials/vdebasics + +Common usages of VDE include fast prototyping and teaching. + +Examples: + + ``vecX:transport=vde,vnl=tap://tap0`` + +use tap0 + + ``vecX:transport=vde,vnl=slirp://`` + +use slirp + + ``vec0:transport=vde,vnl=vde:///tmp/switch`` + +connect to a vde switch + + ``vecX:transport=\"vde,vnl=cmd://ssh remote.host //tmp/sshlirp\"`` + +connect to a remote slirp (instant VPN: convert ssh to VPN, it uses sshlirp) +https://github.com/virtualsquare/sshlirp + + ``vec0:transport=vde,vnl=vxvde://234.0.0.1`` -Legacy transports are now considered obsolete. Please use the vector -versions. +connect to a local area cloud (all the UML nodes using the same +multicast address running on hosts in the same multicast domain (LAN) +will be automagically connected together to a virtual LAN. *********** Running UML |