VIF Types

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.

VIF objects

Each distinct type of VIF configuration is represented by a versioned object, subclassing VIFBase.

class os_vif.objects.vif.VIFBase(context=None, **kwargs)

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.

class os_vif.objects.vif.VIFGeneric(context=None, **kwargs)

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.

class os_vif.objects.vif.VIFBridge(context=None, **kwargs)

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’.

class os_vif.objects.vif.VIFOpenVSwitch(context=None, **kwargs)

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’.

class os_vif.objects.vif.VIFDirect(context=None, **kwargs)

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’

class os_vif.objects.vif.VIFVHostUser(context=None, **kwargs)

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’

class os_vif.objects.vif.VIFDirect(context=None, **kwargs)

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’

class os_vif.objects.vif.VIFNestedDPDK(context=None, **kwargs)

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.

VIF port profile objects

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.

class os_vif.objects.vif.VIFPortProfileBase(context=None, **kwargs)

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.

class os_vif.objects.vif.VIFPortProfileOpenVSwitch(context=None, **kwargs)

Port profile info for Open vSwitch networks.

This profile provides the metadata required to associate a VIF with an Open vSwitch interface.

class os_vif.objects.vif.VIFPortProfileFPOpenVSwitch(context=None, **kwargs)

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.

class os_vif.objects.vif.VIFPortProfileOVSRepresentor(context=None, **kwargs)

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.

class os_vif.objects.vif.VIFPortProfileFPBridge(context=None, **kwargs)

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.

class os_vif.objects.vif.VIFPortProfileFPTap(context=None, **kwargs)

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.

class os_vif.objects.vif.VIFPortProfile8021Qbg(context=None, **kwargs)

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.

class os_vif.objects.vif.VIFPortProfile8021Qbh(context=None, **kwargs)

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.

class os_vif.objects.vif.VIFPortProfileK8sDPDK(context=None, **kwargs)

Port profile info for Kuryr-Kubernetes DPDK ports.

This profile provides the metadata required to associate nested DPDK VIF with a Kubernetes pod.

Datapath Offload type object

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.

class os_vif.objects.vif.DatapathOffloadBase(context=None, **kwargs)

Base class for all types of datapath offload.

class os_vif.objects.vif.DatapathOffloadRepresentor(context=None, **kwargs)

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.

VIF network objects

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