RedHat OpenShift Virtualization [Part 3] – Multus CNI is the key to multiple networks

In the first two blog posts, we explained the basics of OpenShift Virtualization and the added value it offers businesses. A key technical issue that keeps coming up is network connectivity. While containerized workloads often get by with the standard pod network, virtual machines (VMs) have special requirements: they often need multiple network cards, have to use VLANs, or need near-bare-metal performance via SR-IOV.

The solution to this is called Multus CNI.

Standard pod network in Kubernetes

By default, Kubernetes provides each pod with a single network interface.

• This interface is part of the pod network, usually OVN-Kubernetes in OpenShift.

• Communication is IP-based, service discovery runs via DNS, and additional features such as service mesh can be integrated.

• This is perfectly adequate for most container workloads.

However, it is often not enough for VMs. Many classic applications expect multiple network cards or a direct connection to existing VLANs. This is precisely where the standard model reaches its limits.

Multus CNI – Multiple networks for pods and VMs

Multus CNI is a meta CNI plugin that allows pods (and thus also VMs) to have multiple network interfaces.

• In addition to the standard interface (eth0) in the pod network, additional interfaces can be added.

• These interfaces are defined via NetworkAttachmentDefinitions (NADs) in the respective namespace.

• Each NAD can point to a different CNI implementation, e.g. macvlan, bridge, SR-IOV or other plugins.

This means that a VM can communicate simultaneously in the Kubernetes pod network and in one or more VLANs of the data centre.

Integration with VLANs

A classic case is the connection to VLANs:

• With Multus, an NAD can be created that maps a pod or VM interface directly to a specific VLAN.

• This allows VMs in OpenShift to be connected directly to existing Layer 2 networks – without having to modify legacy systems.

• Example: An ERP VM remains accessible in the ERP VLAN while also communicating with modern microservices via the Kubernetes network.

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: net-1223 
  annotations:
  "k8s.v1.cni.cncf.io/resourceName": bridge.network.kubevirt.io/<
bridge-interface>
spec:
  config: '{
   "cniVersion": "0.3.1",
   "name": "vlan-net-1223",  
   "type": "cnv-bridge", 
   "bridge": "<bridge-interface>", 
   "macspoofchk": true, 
   "vlan": 1223
  }'

SR-IOV – Near-bare-metal performance

For particularly demanding workloads (e.g. databases, storage systems or telco workloads), a purely virtual connection is often not sufficient. This is where SR-IOV (Single Root I/O Virtualization) comes into play:

• With SR-IOV, physical network cards can be divided into multiple virtual functions (VFs).

• These VFs can then be passed directly to pods or VMs – via Multus as an additional network interface.

• Advantage: Nearly native network performance, comparable to bare metal.

• Disadvantage: Flexibility is reduced because VFs are permanently tied to specific workloads.

Multus is the key to OpenShift Virtualization

Without Multus, OpenShift Virtualization would hardly be practical:

• VMs often require more than one network card.

• They must be integrated into existing VLANs.

• SR-IOV is essential for high-performance workloads.

Multus CNI is therefore the ideal solution for running VMs in OpenShift in a way that is compatible with the existing infrastructure and allows seamless communication with containers in the cluster.

Conclusion

The standard pod network alone can only be used for simple scenarios. Multus CNI makes OpenShift Virtualization truly flexible and enterprise ready:

• Multiple networks per VM or pod.

• Integration into VLANs for legacy systems.

• SR-IOV ensures optimal performance.

For enterprises, this means that existing network architectures do not have to be completely rebuilt – instead, they can be integrated into the Kubernetes world step by step. Multus is therefore a crucial building block for the success of OpenShift Virtualization.

zurück