Understanding how KubeVirt and OpenShift Virtualization deliver near-native network performance through PCI passthrough and Virtual Functions.
Every network type covered in Parts 1 through 4 answered where a packet travels. This article answers a different question entirely: what if a packet could avoid nearly all of that travel?
Even the fastest software path still costs something. A bridge lookup here, an OpenFlow table match there, Geneve encapsulation on top of that, a checksum computed, an interrupt fired, the kernel scheduler deciding when to actually run the code that does all of this. None of it is slow in isolation. All of it adds up — and for workloads measured in microseconds, it adds up to something that matters.
Eventually, every architect optimizing for latency asks the same question: can we eliminate all of this software processing entirely? The answer is SR-IOV — and the idea that should stay with you through this entire article is simple: the fastest packet is the one that never enters the software datapath.
| Component | Purpose |
|---|---|
| PF | Physical Function — the real NIC hardware root |
| VF | Virtual Function — a hardware-isolated slice of the PF |
| SR-IOV NIC | The physical card capable of hardware virtualization |
| PCIe | The bus that exposes each VF as its own device |
| IOMMU | Secure DMA isolation between VFs and VMs |
| SR-IOV Network Operator | Manages VF lifecycle across the cluster |
| Device Plugin | Advertises VFs as schedulable Kubernetes resources |
| Multus | Attaches the VF to the workload as a network interface |
| KubeVirt | Consumes the VF as the VM's network device |
Before Kubernetes objects enter the picture at all, here's the pure hardware path — because that's genuinely where SR-IOV's story starts.
A modern SR-IOV-capable NIC doesn't just have one network port — it can partition its own hardware root into isolated virtual slices. A physical interface like ens5f0 can expose Virtual Functions like ens5f0v3, each one a genuinely separate PCI device with its own hardware queue, its own MAC address, and its own place in the NIC's forwarding silicon.
The hardware exists independent of Kubernetes. Here's how OpenShift discovers it, carves it up, and hands a slice to a VM — the same educational pattern as the UDN lifecycle in Part 4, applied to a completely different technology.
A cluster admin applies a SriovNetworkNodePolicy. The SR-IOV Network Operator reads it and instructs the physical NIC to actually create the requested number of VFs in hardware. The Device Plugin then advertises those VFs to Kubernetes as a schedulable resource — not unlike CPU or memory. Multus handles attaching a specific VF to a specific pod or VM at creation time.
Same discipline as every article in this series — real addressing, every hop named. This time the hop count is dramatically shorter.
The guest at 192.168.200.10 writes a raw frame directly into its virtual NIC's hardware registers — not a software queue, an actual register the VF exposes.
The guest driver, running the vfio-pci model, moves the frame directly over PCIe. The host kernel's network stack is not involved in this step at all.
The frame lands in the VF's own hardware Tx ring — a queue that belongs exclusively to this VM, with no other workload's traffic sharing it.
The PF's hardware forwarding engine reads the VF's buffer, applies the VLAN 200 tag at wire-speed inside the NIC's own silicon, and prepares the frame for transmission.
The physical interface's controller handles all packet multiplexing directly in the ASIC. No CPU cycles on the host are spent processing this frame.
The upstream switch receives a tagged, standard 802.1Q frame — configured in trunk mode exactly as it would be for any bare-metal host on VLAN 200.
Most SR-IOV explanations stop at "the VF sends traffic." Here's the layer most of them skip.
When the PF creates a VF, it's allocating a genuinely separate hardware queue — its own Tx/Rx ring, isolated from every other VF's traffic at the silicon level. DMA (Direct Memory Access) lets the NIC write incoming data straight into the VM's memory without the CPU copying it through an intermediate buffer. MSI-X interrupts give each VF its own interrupt vector, so the guest driver can be notified directly rather than waiting on a shared, contended interrupt line.
The series' running comparison, now complete across all five architectures covered so far.
| Network Type | Packet Leaves Node As |
|---|---|
| Linux Bridge | Native Ethernet |
| OVN | Geneve Encapsulated |
| Localnet | Native Ethernet |
| UDN | Geneve Encapsulated |
| SR-IOV | Native Ethernet — direct from hardware |
| Feature | SR-IOV |
|---|---|
| Overlay | No |
| OVS | No |
| Linux Bridge | No |
| Hardware Switching | Yes |
| PCI Passthrough | Yes |
| Live Migration | Limited / conditional |
| Performance | Excellent |
| Flexibility | Lower |
Five network types, side by side — the full picture the series has been building toward.
| Linux Bridge | OVN | Localnet | UDN | SR-IOV | |
|---|---|---|---|---|---|
| Switching Layer | Kernel | SDN | Hybrid | SDN | Hardware |
| OVS Involved | No | Yes | Yes | Yes | No |
| Overlay | No | Yes | No | Yes | No |
| Latency | Good | Good | Better | Good | Excellent |
| Flexibility | High | High | Medium | High | Lower |
Translating five articles of architecture into one lookup table.
| Requirement | Recommended Network |
|---|---|
| Lowest latency | SR-IOV |
| Multi-tenancy | UDN |
| Enterprise VLAN integration | Localnet |
| General-purpose virtualization | Linux Bridge |
| Cloud-native overlay | OVN-Kubernetes |