In os-vif, a VIF type refers to a particular approach for configuring the backend of a guest virtual network interface. There is a small, finite set of ways that a VIF backend can be configured for any given hypervisor and a limited amount of metadata is associated with each approach.
Each distinct type of VIF configuration is represented by a versioned object,
subclassing VIFBase
.
Represents a virtual network interface.
The base VIF defines fields that are common to all types of VIF and provides an association to the network the VIF is plugged into. It should not be instantiated itself - use a subclass instead.
A generic-style VIF.
Generic-style VIFs are unbound, floating TUN/TAP devices that should be setup by the plugin, not the hypervisor. The way the TAP device is connected to the host network stack is explicitly left undefined.
For libvirt drivers, this maps to type=”ethernet” which just implies a bare TAP device with all setup delegated to the plugin.
A bridge-style VIF.
Bridge-style VIFs are bound to a Linux host bridge by the hypervisor. This provides Ethernet layer bridging, typically to the LAN. Other devices may be bound to the same L2 virtual bridge.
For libvirt drivers, this maps to type=’bridge’.
A bridge-style VIF specifically for use with OVS.
Open vSwitch VIFs are bound directly (or indirectly) to an Open vSwitch bridge by the hypervisor. Other devices may be bound to the same virtual bridge.
For libvirt drivers, this also maps to type=’bridge’.
A direct-style VIF.
Despite the confusing name, direct-style VIFs utilize macvtap which is a
device driver that inserts a software layer between a guest and an SR-IOV
Virtual Function (VF). Contrast this with
VIFHostDevice
, which allows the guest to
directly connect to the VF.
The connection to the device may operate in one of a number of different
modes, VEPA (either 802.1Qbg or 802.1Qbh),
passthrough (exclusive assignment of the host NIC) or bridge (ethernet
layer bridging of traffic). The passthrough mode would be used when there
is a network device which needs to have a MAC address or VLAN
configuration. For passthrough of network devices without MAC/VLAN
configuration, VIFHostDevice
should be used
instead.
For libvirt drivers, this maps to type=’direct’
A vhostuser-style VIF.
vhostuser-style VIFs utilize a userspace vhost
backend, which allows traffic to traverse between the guest and a host
userspace application (commonly a virtual switch), bypassing the kernel
network stack. Contrast this with VIFBridge
,
where all packets must be handled by the hypervisor.
For libvirt drivers, this maps to type=’vhostuser’
A nested DPDK-style VIF.
Nested DPDK-style VIFs are used by Kuryr-Kubernetes to provide accelerated
DPDK datapath for nested Kubernetes pods running inside the VM. The port
is first attached to the virtual machine, bound to the userspace driver
(e.g. uio_pci_generic
, igb_uio
or vfio-pci
) and then consumed
by Kubernetes pod via the kuryr-kubernetes CNI plugin.
This does not apply to libvirt drivers.
Each VIF instance can optionally be associated with a port profile object. This
provides a set of metadata attributes that serve to identify the guest virtual
interface to the host. Different types of host connectivity will require
different port profile object metadata. Each port profile type is associated
with a versioned object, subclassing VIFPortProfileBase
.
Base class for all types of port profile.
The base profile defines fields that are common to all types of profile. It should not be instantiated itself - use a subclass instead.
Port profile info for Open vSwitch networks.
This profile provides the metadata required to associate a VIF with an Open vSwitch interface.
Port profile info for Open vSwitch networks using fast path.
This profile provides the metadata required to associate a fast path VIF with an Open vSwitch port.
Port profile info for OpenVSwitch networks using a representor.
This profile provides the metadata required to associate a VIF with a VF representor and Open vSwitch port. If representor_name is specified, it indicates a desire to rename the representor to the given name on plugging.
Note
This port profile is provided for backwards compatibility only.
This interface has been superceded by the one provided by the
DatapathOffloadRepresentor
class, which is now a field element
of the VIFPortProfileBase
class. The datapath_offload
field in port profiles should be used instead.
Port profile info for Linux Bridge networks using fast path.
This profile provides the metadata required to associate a fast path VIF with a Linux Bridge port.
Port profile info for Calico networks using fast path.
This profile provides the metadata required to associate a fast path VIF with a Calico port.
Port profile info for VEPA 802.1qbg networks.
This profile provides the metadata required to associate a VIF with a VEPA host device supporting the 802.1Qbg spec.
Port profile info for VEPA 802.1qbh networks.
This profile provides the metadata required to associate a VIF with a VEPA host device supporting the 802.1Qbh spec.
Port profile info for Kuryr-Kubernetes DPDK ports.
This profile provides the metadata required to associate nested DPDK VIF with a Kubernetes pod.
Port profiles can be associated with a datapath_offload
object. This
provides a set of metadata attributes that serve to identify the datapath
offload parameters of a VIF. Each different type of datapath offload is
associated with a versioned object, subclassing DatapathOffloadBase
.
Base class for all types of datapath offload.
Offload type for VF Representors conforming to the switchdev model.
This datapath offloads provides the metadata required to associate a VIF
with a VF representor conforming to the switchdev kernel model.
If representor_name
is specified, it indicates a desire to rename the
representor to the given name on plugging.
Each VIF instance is associated with a set of objects which describe the logical network that the guest will be plugged into. This information is again represented by a set of versioned objects
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.