Question_Answer

Loading views...

Network Virtualization — Deep Dive Q&A Reference

A formal technical reference addressing advanced questions on virtual connectivity, OpenStack internals, OVS architecture, DPDK, eBPF, Xen, KVM, TAP monitoring, and packet bypass mechanisms.

Virtual Connections in Network Virtualization (Physical Analogues)
OpenStack Directly on a Host OS — How VMs Are Created Without a Type-2 Hypervisor
The Role of OVS in Network Virtualization — Why It Appears Across Every Technique
OVS Variants Compared — Independent, OVS-DPDK, and OVS-eBPF
Monitoring TAP vs. Network TAP — Differences and Similarities
Xen Hypervisor — Purpose, Architecture, and Direct Installation on a Host OS
Can eBPF Be Used With OVS?
Applying DPDK Kernel Bypass at the vNIC Layer in Network Virtualization
KVM as a Linux Feature vs. KVM as a Hypervisor

1. Virtual Connections in Network Virtualization (Physical Analogues)

Question

What are all the virtual connection types used in network virtualization, and what physical networking component does each one correspond to?

Answer

Every physical networking construct — cables, switches, NICs, taps, mirrors — has one or more software equivalents in network virtualization. The table below maps each virtual mechanism to its physical analogue, followed by a detailed explanation of each.

Master Mapping Table

Physical Component	Virtual Equivalent(s)	Layer	Primary Use
Ethernet cable (patch cord)	Veth Pair	L2	Container-to-host connectivity
Network cable (IP tunnel)	TUN device	L3	VPN, overlay routing
NIC (guest-facing)	TAP device	L2	VM Ethernet I/O via hypervisor
NIC (paravirtualized)	Virtio-net	L2	High-perf guest NIC
NIC (shared-memory)	Memif	L2	Userspace NFV process I/O
NIC (DPDK userspace)	Virtio-user PMD	L2	Container DPDK I/O
NIC (hardware-isolated)	SR-IOV VF	L2	Hardware-partitioned NIC
NIC (logical)	MACVLAN / IPVLAN	L2/L3	Multi-IP on one physical NIC
Unmanaged L2 switch	Linux Bridge	L2	Basic Ethernet frame switching
Managed/programmable switch	OVS (Open vSwitch)	L2/L3	SDN-controlled vSwitching
DPDK-accelerated switch	OVS-DPDK / VPP	L2/L3	Line-rate userspace switching
VLAN trunk port	802.1Q VLAN subinterface	L2	Traffic segmentation
VXLAN tunnel endpoint	VTEP (in OVS / kernel)	L2 over L3	Overlay L2 across L3 fabric
Port mirror (SPAN)	Linux Bridge mirror / OVS mirror	L2	Traffic monitoring copy
Network TAP (hardware)	Monitoring TAP (kernel/OVS)	L2	Passive inline capture
Dedicated fiber interconnect	RDMA over RoCE (lossless Ethernet)	L2	Zero-copy memory transfer
Loopback (RJ45 loopback)	Loopback interface (`lo`)	L3	Self-addressed local traffic
Cross-connect (direct fiber)	XDPREDIRECT / AFXDP	L2	Kernel-bypass direct redirect
Smart NIC / line-card ASIC	XDP Offload / SmartNIC eBPF	L2	On-NIC packet processing
Cable between two servers	VXLAN / GRE / Geneve tunnel	L3	Virtual L2 link over IP

Detailed Explanations

Veth Pair → Ethernet Patch Cord

A veth pair is a pair of virtual Ethernet interfaces linked in software such that any frame written to one end appears on the other end instantly. It behaves exactly like a physical patch cord connecting two switch ports, except both ends are software constructs inside the Linux kernel. In container networking, one end of the veth pair resides inside the container's network namespace (appearing as eth0 to the container), while the other end lives in the host's network namespace and connects to a bridge or routing table. There is no buffering, no switching logic — it is a pure pipe, identical in concept to a crossover cable between two network cards.

[ Container NS ]   [ Host NS ]
     eth0     <──────> vethXXX ──> Linux Bridge / OVS / routes
              veth pair (virtual patch cord)

TUN Device → Layer-3 IP Tunnel Cable

A TUN (network tunnel) device presents itself to the Linux kernel as a normal IP interface, but instead of sending packets to a physical wire, it delivers raw IP datagrams to a userspace process via a file descriptor. The userspace process typically encrypts these packets and sends them over the real network — this is the mechanism behind most VPN software. The physical analogue is a dedicated IP tunnel or leased line: traffic enters one end, travels through an opaque transport, and exits the other end as if it were a direct connection.

TAP Device → Guest Network Interface Card (NIC)

A TAP (Terminal Access Point) device is a Layer-2 virtual interface that delivers raw Ethernet frames to a userspace application via a file descriptor. QEMU (the VM process) uses a TAP device to give each VM the appearance of a physical NIC. From the guest's perspective, it has a real NIC; from the host's perspective, there is a file descriptor from which QEMU reads and writes Ethernet frames. The TAP device is then connected to a Linux bridge or OVS port, completing the virtual network topology. The physical analogue is the NIC installed in a physical server that the server uses to connect to a switch.

Virtio-net → Paravirtualized (High-Efficiency) NIC

Virtio-net is the guest-side driver for a paravirtualized network device. Rather than emulating a real NIC's hardware registers (as full emulation does), virtio-net uses shared-memory ring buffers (virtqueues) to exchange packet descriptors between the guest kernel and the host backend (QEMU, vhost-net, or vhost-user). The physical analogue is a modern high-speed NIC with driver-level DMA optimization — it skips the slow I/O register interface and uses bulk DMA descriptor transfer instead.

Memif → Direct Memory Interconnect (Shared Backplane)

Memif (Memory Interface) is a shared-memory packet exchange mechanism between two userspace processes. Both processes map the same hugepage-backed memory region; packets are passed by descriptor reference with no copies and no kernel system calls. The physical analogue is a direct memory interconnect or backplane fabric in a modular chassis — two line cards sharing a common memory bus for high-speed packet exchange without going through an external switch.

SR-IOV VF → Hardware-Partitioned NIC Port

SR-IOV (Single Root I/O Virtualization) allows a single physical NIC to expose multiple Virtual Functions — each is a real PCIe hardware device with its own TX/RX queues, DMA engine, and interrupt lines. A VF assigned directly to a VM or container bypasses all software switching. The physical analogue is a multi-port NIC where each port is completely independent with its own MAC, queues, and direct host connection — except all ports share one physical PCIe slot and one physical cable.

MACVLAN / IPVLAN → NIC with Multiple IP/MAC Bindings

MACVLAN creates multiple virtual interfaces on top of one physical interface, each with a unique MAC address. IPVLAN creates multiple virtual interfaces sharing the parent's MAC but each with its own IP. The physical analogues are: MACVLAN corresponds to a NIC with multiple hardware MAC addresses programmed (some NICs support this via firmware); IPVLAN corresponds to a NIC with multiple IP aliases configured via the OS but sharing one MAC.

Linux Bridge → Unmanaged Layer-2 Switch

A Linux bridge is a kernel software switch that learns MAC addresses and forwards Ethernet frames between attached interfaces using a forwarding table. It has no management interface, no OpenFlow support, no VLAN awareness beyond basic tagging, and no QoS. The physical analogue is an unmanaged desktop switch — it works, it is reliable, but it cannot be programmed or monitored in any sophisticated way.

OVS → Managed, Programmable L2/L3 Switch

Open vSwitch is a full-featured virtual switch with OpenFlow support, VLAN trunking, tunnel termination (VXLAN, GRE, Geneve), QoS, metering, and bond aggregation. It can be controlled by an external SDN controller. The physical analogue is a managed enterprise or data-center switch (Cisco Catalyst, Arista, Juniper EX) with a control plane interface, SNMP monitoring, and the ability to program forwarding behavior programmatically.

VXLAN / GRE / Geneve Tunnel → Virtual Cross-Connect or WAN Link

These overlay encapsulations create a virtual L2 link between two endpoints separated by an IP network. VXLAN encapsulates Ethernet frames in UDP; GRE encapsulates in IP; Geneve adds variable-length metadata. The physical analogue is an MPLS pseudowire or a dark fiber cross-connect between two data centers — a logical L2 adjacency that physically traverses an L3 IP network.

OVS SPAN Mirror / Linux Bridge Mirror → Hardware SPAN / Port Mirror

Both physical and virtual switches can copy traffic from one port to another for monitoring. The virtual SPAN (configured in OVS via mirror rules) duplicates packets from selected ports and sends copies to a monitor interface — exactly as a physical switch SPAN port does. The physical analogue is a managed switch's SPAN/RSPAN configuration that feeds a network analyzer or IDS sensor.

XDPREDIRECT / AFXDP → Direct Cross-Connect Fiber

XDPREDIRECT allows an eBPF program to redirect a packet from one interface directly to another (or to an AFXDP socket) at the earliest possible point in the receive path, before any kernel stack processing. The physical analogue is a direct fiber cross-connect or a hardware switch fabric path that routes a packet from ingress to egress with minimum latency, bypassing any general-purpose processing.

2. OpenStack Directly on a Host OS — How VMs Are Created Without a Type-2 Hypervisor

Question

If OpenStack is installed directly on a Linux, Windows, or macOS host OS without a Type-2 hypervisor, how does OpenStack create and manage virtual machines?

Answer

Clarifying the Hypervisor Model

To answer this question precisely, it is important to first correct a common misconception. OpenStack itself is not a hypervisor — it is a cloud management and orchestration platform. OpenStack manages compute, networking, and storage resources but delegates actual VM creation to a pluggable hypervisor driver. The relevant component is Nova (the OpenStack Compute service), which communicates with whatever hypervisor is available on the underlying host.

OpenStack does not require a Type-2 hypervisor (such as VirtualBox or VMware Workstation). When installed directly on a Linux host OS, OpenStack uses KVM — which is a Type-1 hypervisor embedded directly inside the Linux kernel.

What Happens on Linux: KVM + QEMU

When OpenStack Nova is configured with the libvirt driver and KVM is available:

OpenStack Nova (orchestration)
    ↓ nova-compute
  libvirt API
    ↓
  QEMU process (per VM)
    ↓
  KVM kernel module (/dev/kvm)
    ↓
  Hardware virtualization (Intel VT-x / AMD-V CPU extensions)

Nova receives a request to boot a VM (from Horizon dashboard, CLI, or API).
nova-compute calls the libvirt API (a virtualization management library).
libvirt spawns a QEMU process with parameters defining the VM's CPU count, RAM, disk images, and network interfaces.
QEMU opens /dev/kvm — the KVM kernel module's character device — and issues ioctl() calls to create a virtual CPU (vCPU), allocate guest physical memory, and configure hardware virtualization.
The Linux kernel's KVM module programs the CPU's virtualization extensions (Intel VT-x or AMD-V) to run guest code directly on the physical CPU without software interpretation.
QEMU handles device emulation (virtual disk, virtual NIC via TAP/virtio) while KVM handles the CPU and memory virtualization in hardware.

KVM is classified as a Type-1 hypervisor because it runs inside the OS kernel itself — the Linux kernel becomes the hypervisor. It does not sit on top of a general-purpose OS the way Type-2 hypervisors do.

On Windows: No Native KVM — HyperV or QEMU Software Emulation

OpenStack is not natively supported on Windows as a host OS. Windows lacks:

The KVM kernel module (Windows uses Hyper-V for hardware-assisted virtualization)
Native libvirt support
Linux network namespaces, OVS, and the full Linux networking stack that OpenStack Neutron requires

OpenStack can technically run on Windows inside WSL2 (Windows Subsystem for Linux 2), which itself uses a lightweight Hyper-V-based Linux VM. In this configuration, QEMU runs inside the WSL2 Linux environment and uses KVM via Hyper-V's nested virtualization support. This is a development/testing scenario and not a production deployment model.

On macOS: QEMU with HVF (Hypervisor.framework)

macOS also does not support KVM. When OpenStack is run on macOS (again, typically inside a Linux VM or via tools like DevStack on an OrbStack/UTM VM), QEMU uses Apple's Hypervisor.framework (HVF) to access hardware virtualization extensions via macOS's native API. Performance is reasonable for development but lacks the production-grade feature set of Linux KVM.

Summary: OpenStack VM Creation on Bare-Metal Linux (Production)

Step	Component	Action
1	Nova API	Receives boot request
2	nova-scheduler	Selects compute host
3	nova-compute	Calls libvirt driver
4	libvirt	Generates XML domain definition
5	QEMU	Spawns as a process, opens `/dev/kvm`
6	KVM (kernel)	Programs VT-x/AMD-V, creates vCPU
7	Nova + Neutron	Creates TAP device, connects to OVS
8	OVS	Connects TAP to virtual network (VXLAN, VLAN, flat)
9	Cinder	Attaches block storage (RBD/iSCSI) as virtual disk
10	VM	Boots, sees virtio-net NIC and virtio-blk disk

OpenStack on bare-metal Linux with KVM is, by definition, a Type-1 virtualization deployment — there is no general-purpose OS layer between the hypervisor (KVM in the kernel) and the hardware.

3. The Role of OVS in Network Virtualization — Why It Appears Across Every Technique

Question

What does Open vSwitch (OVS) do in network virtualization, and why does it appear across packet processing, packet bypass (DPDK), and packet filtering (eBPF) techniques?

Answer

What OVS Fundamentally Is

Open vSwitch is a programmable, multi-layer virtual switch that provides a stable, consistent control plane and management interface for virtual networking — regardless of what technology drives its data plane. This architectural separation is the key to understanding why OVS appears in every technique.

OVS separates:

Control plane: ovs-vswitchd daemon, OpenFlow processing, OVSDB configuration — always runs in userspace, always the same regardless of dataplane
Data plane: where actual packets are forwarded — this is what changes between standard OVS, OVS-DPDK, and OVS+eBPF

          ┌─────────────────────────────────┐
          │        Control Plane             │
          │   ovs-vswitchd + ovsdb-server    │ ← same in ALL variants
          │   OpenFlow / SDN controller      │
          └───────────────┬─────────────────┘
                          │ flow rules
          ┌───────────────▼─────────────────┐
          │           Data Plane             │
          │  kernel datapath / DPDK / eBPF  │ ← changes per variant
          └─────────────────────────────────┘

What OVS Does in Standard Packet Processing

In its standard form (no DPDK, no eBPF acceleration), OVS operates as follows:

Port management: OVS creates and manages virtual ports — TAP devices (for VMs), veth pairs (for containers), tunnel endpoints (VXLAN/GRE), physical NIC ports, and internal ports.
Flow-based forwarding: Every packet is matched against a flow table. A flow entry specifies: match fields (src/dst MAC, IP, port, VLAN, tunnel ID) and actions (forward to port, modify header, drop, send to controller).
Slow path and fast path: The first packet of a new flow goes to the ovs-vswitchd userspace daemon for OpenFlow processing (slow path). The daemon installs an exact-match cache entry in the kernel datapath. Subsequent packets of the same flow are handled by the kernel datapath directly (fast path) without userspace involvement.
Tunnel termination: OVS acts as a VXLAN/GRE/Geneve VTEP (Virtual Tunnel End Point), encapsulating and decapsulating overlay traffic for inter-host VM/container communication.
VLAN handling: OVS tags, strips, and translates VLAN IDs as packets traverse ports — implementing network segmentation between tenants.
Bond aggregation: OVS can bond multiple physical NICs into a single logical uplink for redundancy and bandwidth aggregation.

Why OVS Appears in DPDK (Packet Bypass) Deployments

When DPDK is introduced, OVS replaces its kernel datapath with a DPDK userspace datapath (OVS-DPDK). The reason OVS is retained — rather than writing a completely custom DPDK forwarding application — is that OVS provides:

Management continuity: The same ovs-vsctl, ovs-ofctl, OVSDB, and OpenFlow APIs work identically. Operators and SDN controllers do not need to change.
Feature richness: VXLAN encapsulation, VLAN handling, QoS, metering, bonding, and ACLs — all available in the DPDK datapath.
Ecosystem integration: OpenStack Neutron, OVN, and commercial SDN controllers all integrate with OVS via standard interfaces.

In OVS-DPDK, the kernel datapath is completely replaced: DPDK PMD threads poll physical NIC queues and vhost-user ports directly, forwarding packets based on OVS flow tables — all in userspace, all without kernel stack involvement.

Why OVS Appears in eBPF (Packet Filtering) Deployments

eBPF-based solutions (Cilium, Calico eBPF) do not typically run inside OVS's data path. However, OVS and eBPF co-exist in the same stack for the following reasons:

OVS handles the underlay: OVS manages physical NIC bonding, VLAN trunking, and inter-host tunnels (VXLAN). eBPF handles the overlay (pod-to-pod policy, service load balancing).
OVN + eBPF: OVN (the OVS control plane for logical networking) is exploring eBPF-accelerated datapaths where eBPF programs implement OVN's logical forwarding rules instead of OVS kernel flows — bringing eBPF performance to the OVN logical networking model.
Hybrid stacks: In OpenStack environments using Cilium for pod networking, OVS still manages the physical underlay (VLAN, VXLAN tunnels) while Cilium's eBPF manages container-level policy and service routing.

The Core Reason OVS Appears Everywhere

OVS occupies the role of the universal virtual networking control and management plane. It answers the question: "How do you configure, monitor, and control virtual network topology?" — regardless of whether the data plane is a kernel module, a DPDK PMD, or an eBPF program. Every virtualization technique needs something to manage ports, configure forwarding rules, and integrate with orchestration systems. OVS is the industry-standard answer to that requirement.

4. OVS Variants Compared — Independent, OVS-DPDK, and OVS-eBPF

Question

How are standard OVS, OVS with DPDK (OVS-DPDK), and OVS with eBPF similar to and different from each other?

Answer

Similarity: All Three Share the Same Control Plane

All three variants share identical control-plane components:

ovs-vswitchd — the main OVS daemon
ovsdb-server — the configuration database
OpenFlow protocol support — same flow table semantics
ovs-vsctl / ovs-ofctl / ovs-appctl CLI tools
Integration with OpenStack Neutron, OVN, and SDN controllers

An operator managing standard OVS, OVS-DPDK, or OVS+eBPF uses the same commands and the same mental model. The topology (bridges, ports, flows) is expressed identically.

Detailed Comparison

Dimension	Standard OVS	OVS-DPDK	OVS + eBPF (OVN-eBPF / experimental)
Data plane location	Linux kernel module	DPDK userspace (PMD threads)	eBPF programs in kernel (TC/XDP hooks)
Packet I/O mechanism	Kernel netdev / softirq	DPDK PMD polling (no interrupts)	eBPF at TC/XDP hook, standard netdev
Kernel stack involvement	Yes (sk_buff allocation)	No (hugepage mbufs)	Partial (sk_buff exists, eBPF intercepts it)
First-packet handling	Userspace slow path	Userspace slow path	eBPF tail calls / map lookups (no slow path)
Throughput	~1–5 Mpps	~20–100 Mpps	~5–20 Mpps
Latency	50–500 µs	5–20 µs	10–50 µs
CPU utilization	Interrupt-driven, efficient at low load	PMD cores at 100% always	Interrupt-driven, efficient at low load
Memory requirements	Standard pages (4 KB)	Hugepages (2 MB / 1 GB) required	Standard pages
NIC requirements	Any Linux-supported NIC	DPDK-compatible NIC + VFIO/UIO	Any NIC (XDP native needs driver support)
VM connectivity	TAP + vhost-net	vhost-user (shared hugepage memory)	TAP + veth (standard)
Container connectivity	veth pair	virtio-user PMD or veth	veth pair
Configuration complexity	Low	High (hugepages, CPU pinning, NUMA)	Medium
Observability	Standard Linux tools	DPDK telemetry, custom	eBPF maps, bpftool, Hubble (if Cilium)
Production maturity	Very high	High (telco, NFV)	Emerging (OVN-eBPF is experimental)

Packet Flow Comparison

Standard OVS:

NIC → kernel driver (IRQ) → sk_buff → kernel OVS datapath (flow cache lookup) 
    → [miss] → upcall to ovs-vswitchd → flow installed → kernel forwards
    → [hit]  → kernel forwards directly
→ destination TAP / veth / tunnel

OVS-DPDK:

NIC → VFIO → DPDK PMD (polling) → mbuf → OVS userspace datapath (EMC/DPCLS lookup)
    → [miss] → ovs-vswitchd OpenFlow processing → flow installed
    → [hit]  → forward to vhost-user port / another PMD port / tunnel
→ destination VM (vhost-user virtqueue) / container (virtio-user)

OVS + eBPF (OVN-eBPF experimental):

NIC → kernel driver (IRQ) → sk_buff → TC eBPF hook
    → eBPF program reads OVN logical flow from BPF map
    → eBPF executes action (forward, NAT, encapsulate) directly
    → [no slow path / no ovs-vswitchd for data plane]
→ destination veth / tunnel

When to Use Each Variant

Standard OVS: General-purpose deployments, OpenStack environments, Kubernetes underlay, any environment where operational simplicity matters more than maximum throughput. Handles tens of thousands of flows and millions of packets per second adequately for most workloads.

OVS-DPDK: Telco NFV, 5G user-plane functions, financial trading infrastructure, any workload requiring 10–100 Gbps sustained throughput with single-digit microsecond latency. Requires significant infrastructure investment (hugepages, CPU isolation, NUMA-aware design, DPDK-compatible NICs).

OVS + eBPF: Emerging use case, currently pursued by the OVN community as a way to bring eBPF performance to OVN logical networking without the infrastructure cost of DPDK. Aims for better performance than standard OVS without the operational complexity of DPDK. Not yet production-ready at scale as of 2025.

5. Monitoring TAP vs. Network TAP — Differences and Similarities

Question

How does a monitoring TAP (as used in network analysis) differ from or resemble the TAP virtual device used in Linux network virtualization?

Answer

The Shared Conceptual Root

Both the hardware Network TAP and the Linux TAP virtual device share the same conceptual purpose at a high level: delivering a copy of network traffic to an observer without interrupting the original traffic path. The word "TAP" in both cases derives from the same metaphor — a physical tap on a pipe that lets you sample the fluid flowing through it without stopping the flow.

However, beyond this shared concept, they differ substantially in implementation, scope, and usage.

Hardware Network TAP (Test Access Point)

A hardware Network TAP is a physical inline device inserted into a network cable path between two network devices (e.g., between a router and a firewall). It passively copies all traffic traversing the link and sends the copy to a monitoring port. Key properties:

Inline and passive: The TAP sits physically between two devices. It has no IP address, no MAC address, and generates no traffic of its own.
Completely transparent: The network devices on either side are entirely unaware of the TAP's existence. Even if the TAP loses power, an optical TAP continues to pass light (fiber splits do not require power).
Full-duplex capture: Hardware TAPs typically have separate monitor ports for each direction (TX and RX) because the link is full-duplex. A monitoring system receives both sides.
No packet loss on the live path: Because the copy is made at the physical (optical or electrical) layer, the live traffic path is never affected by monitoring load.
Use cases: Feeding a packet capture system, IDS/IPS, DPI engine, or lawful intercept system with a complete copy of traffic on a specific physical link.

Router ──┬──────────────────────────────> Firewall
         │ (physical TAP device inline)
         └──> Monitor port ──> Wireshark / IDS / DPI
              (copy of all traffic, both directions)

Linux TAP Virtual Device

A Linux TAP device is a kernel virtual network interface that delivers Layer-2 Ethernet frames to a userspace process via a file descriptor. It does not passively copy traffic — it is the traffic path for a virtual machine or other userspace networking application.

Active participant: The Linux TAP device is a network interface. Traffic is directed to it deliberately by the kernel — it does not sit alongside a path and copy it.
Bidirectional I/O: A userspace process reads frames from the TAP FD (receiving from the network) and writes frames to the TAP FD (sending to the network). It is both the producer and consumer of traffic on that interface.
QEMU/KVM usage: When a VM is connected to a TAP device, QEMU reads Ethernet frames from the TAP FD (packets sent by the VM) and writes frames to the TAP FD (packets arriving for the VM). The TAP device is the VM's NIC connection to the host network.
No passivity: The Linux TAP is not passive. If nothing reads from it, packets are dropped.

VM (virtio-net) ──> QEMU reads/writes TAP FD ──> Linux TAP device ──> Linux Bridge / OVS

Comparison Table

Dimension	Hardware Network TAP	Linux TAP Virtual Device
Physical existence	Physical device on a cable	Software construct in kernel
Layer	L1/L2 (electrical or optical copy)	L2 (Ethernet frames via FD)
Role in traffic path	Passive observer (copy only)	Active participant (IS the path)
Transparency	Completely transparent to network	Visible as a network interface
Packet loss risk	Zero on live path	Drops if userspace stalls reading
Power dependency	Optical TAPs: passive, no power needed	Always available while kernel runs
Direction	Full-duplex (both TX and RX)	Bidirectional via single FD
Primary use	Network monitoring, IDS, DPI feed	VM NIC I/O (QEMU/KVM)
Configuration	Physical insertion into cable path	`ip tuntap add` or via libvirt
OSI model	Primarily physical/data link observation	Data link layer I/O

The Common Ground

Both mechanisms enable a system that is not the original intended destination to receive a copy of or access to network traffic:

The hardware TAP gives the monitoring system a copy of traffic on a physical link.
The Linux TAP gives the hypervisor (QEMU) access to a VM's network traffic.

In both cases, a third-party observer (the monitoring system or the hypervisor) gains access to traffic that would otherwise only be seen by the two endpoints of the connection. The hardware TAP achieves this at the physical layer through signal splitting; the Linux TAP achieves this at the software layer through kernel-mediated I/O.

OVS SPAN as a Virtual Equivalent of a Hardware Network TAP

For completeness, the software construct that most closely matches a hardware Network TAP's passive monitoring function is the OVS SPAN mirror (or Linux bridge mirror), not the Linux TAP device. An OVS mirror copies selected traffic from OVS ports and delivers it to a designated monitoring interface — exactly replicating what a hardware TAP does at the physical layer, but entirely in software.

6. Xen Hypervisor — Purpose, Architecture, and Direct Installation on a Host OS

Question

What is Xen, why is it used, and can it be installed directly on a host operating system?

Answer

What Xen Is

Xen Project is an open-source, Type-1 bare-metal hypervisor. It was originally developed at the University of Cambridge and is now maintained by the Linux Foundation. Xen is the hypervisor underlying Amazon Web Services EC2 (historically the primary hypervisor until the gradual transition to KVM/Nitro), Citrix Hypervisor (XenServer), and the Qubes OS security-focused desktop operating system.

Xen runs directly on hardware and manages one or more virtual machines (called domains). It is fundamentally different from KVM: while KVM turns the Linux kernel itself into a hypervisor, Xen runs beneath any operating system. The operating system that administrators interact with (Linux, Windows, FreeBSD) runs inside a privileged VM called dom0, not directly on the hardware.

Xen Architecture

Hardware (CPU with VT-x/AMD-V, NIC, Disk, RAM)
        ↓
  ┌─────────────────────────────────────────────────────┐
  │                 Xen Hypervisor                       │  ← runs directly on hardware
  │  (CPU scheduling, memory management, interrupt       │
  │   routing, device passthrough, hypercall interface) │
  └──────────────┬──────────────────────────────────────┘
                 │
  ┌──────────────▼──────────────┐   ┌────────────┐  ┌────────────┐
  │     dom0 (privileged VM)    │   │  domU (VM) │  │  domU (VM) │
  │  Linux OS + Xen-aware kernel│   │  Guest OS  │  │  Guest OS  │
  │  Manages devices, VMs       │   │  HVM / PV  │  │  HVM / PV  │
  └──────────────┬──────────────┘   └────────────┘  └────────────┘
                 │ device model / toolstack
            xl / libxl / XAPI

Key components:

Xen hypervisor binary: A small, specialized piece of software (~150K lines of code vs. Linux kernel's ~30 million). Manages CPU scheduling across domains, enforces memory isolation, and routes device interrupts. It is intentionally minimal for security.
dom0: The first domain started by Xen, given privileged access to hardware. Dom0 runs a full operating system (typically Linux) and is responsible for running the Xen toolstack (xl commands), managing device drivers, and creating/destroying other VMs (domU). Without dom0, Xen cannot function.
domU (Unprivileged domains): All guest VMs other than dom0. Each domU believes it has its own hardware but is fully isolated by the Xen hypervisor. DomU VMs can run unmodified guest OSes using HVM (hardware-assisted virtualization via VT-x/AMD-V) or paravirtualized OSes using PV mode (modified kernel that makes hypercalls instead of hardware I/O).

Xen Virtualization Modes

Mode	Full Name	Guest Modification	Performance	Use Case
HVM	Hardware Virtual Machine	None required	Good (VT-x/AMD-V)	Windows guests, unmodified Linux
PV	Paravirtualization	Kernel modification needed	Excellent (no emulation)	Linux guests with Xen-aware kernel
PVH	PV on HVM	Minimal	Best (combines both)	Modern Linux guests
PVHVM	PV drivers in HVM guest	PV drivers only (not full kernel)	Very good	Windows with Xen PV drivers

Why Xen Is Used

Xen is preferred in specific scenarios for several reasons:

Security isolation: Xen's hypervisor is intentionally small (minimal attack surface). Device drivers run in dom0 or dedicated driver domains — a driver crash cannot compromise the hypervisor or other VMs. Qubes OS uses this model to isolate sensitive operations (banking, work, personal browsing) in separate VMs.

Cloud infrastructure: AWS built its entire EC2 platform on Xen for over a decade. Xen's mature live migration, memory ballooning, and multi-tenant isolation made it the hypervisor of choice for large-scale cloud deployments.

Strong isolation guarantee: Xen's architecture, where the hypervisor itself has no device drivers and dom0 is isolated, provides a stronger security argument than KVM, where device drivers run in the Linux kernel alongside KVM.

Citrix/Enterprise virtualization: XenServer (now Citrix Hypervisor) is used in enterprise data centers for desktop virtualization (Citrix Virtual Apps and Desktops) and server virtualization.

Can Xen Be Installed Directly on a Host OS?

No — and this is a fundamental architectural point. Xen is not installed on top of an existing operating system. Xen itself boots directly from the bootloader (GRUB), before any operating system loads. GRUB loads the Xen hypervisor binary first, which then loads dom0 (the management Linux OS) as its first virtual machine.

The installation process on a Linux system works as follows:

# Install Xen packages on a Linux distribution (e.g., Debian/Ubuntu)
apt-get install xen-hypervisor-amd64

# After installation, GRUB is updated to offer Xen boot entries.
# The boot order becomes:
# 1. BIOS/UEFI → GRUB → Xen hypervisor binary
# 2. Xen loads → starts dom0 Linux kernel as first VM
# 3. dom0 Linux boots, loads Xen-aware drivers
# 4. Administrator uses xl / libvirt to create domU VMs

The Linux OS that was previously running on the hardware becomes dom0 — it is demoted to a privileged virtual machine managed by the Xen hypervisor. The hardware now belongs to Xen, not Linux.

This distinguishes Xen sharply from KVM: with KVM, Linux remains the primary OS and KVM is a kernel module it loads; with Xen, Linux becomes a VM guest (dom0) underneath the Xen hypervisor.

On Windows or macOS: Xen cannot be installed directly on Windows or macOS as a host OS. These operating systems do not support Xen's boot model (Xen must own the boot process via the bootloader). Xen can run inside a VM on these platforms for testing purposes only.

Xen Networking in Virtualization Context

Xen uses a split-driver model for networking:

Dom0 runs the real NIC driver (the backend driver) and a virtual switch (typically Linux Bridge or OVS).
DomU VMs run a lightweight frontend driver (netfront) that communicates with dom0's backend (netback) via shared memory ring buffers — conceptually similar to virtio.
For high-performance networking, Xen supports SR-IOV VF passthrough directly to domU VMs, bypassing dom0 entirely for the data path.

7. Can eBPF Be Used With OVS?

Question

Is it possible to use eBPF in conjunction with Open vSwitch, and if so, what are the integration models?

Answer

Short Answer

Yes — eBPF can be used with OVS, but they operate at different layers of the stack and their integration takes several distinct forms, ranging from complementary co-existence to experimental direct replacement of OVS's kernel datapath with eBPF programs.

Integration Model 1: Complementary Co-Existence (Most Common)

In the most prevalent deployment model, OVS and eBPF operate at different layers and serve different purposes simultaneously:

OVS manages the underlay: Physical NIC bonding, VLAN trunking, VXLAN/GRE tunnel endpoints, inter-host connectivity, OpenFlow-based forwarding for VM traffic.
eBPF (via Cilium or Calico eBPF) manages the overlay: Pod-level network policy enforcement, service load balancing (replacing kube-proxy), connection tracking, encryption.

Packets flow: Physical NIC → OVS (VXLAN decapsulation, VLAN handling) → veth pair → TC eBPF hook (pod policy) → container.

These two systems do not conflict. OVS sees VXLAN-encapsulated inter-node traffic; eBPF programs attached to pod veth interfaces handle the pod-level policy. Each operates within its own scope.

Integration Model 2: eBPF Accelerating OVS Flow Offload

OVS can offload its kernel datapath to a TC eBPF program, where the eBPF program implements the fast-path forwarding logic using BPF maps populated by ovs-vswitchd. This is conceptually similar to how OVS-DPDK offloads to userspace PMDs, but keeps the data plane in the kernel as eBPF programs.

The ovs-vswitchd daemon populates BPF maps with flow table entries; eBPF programs attached to TC hooks read these maps for packet classification and forwarding. Packets that miss the BPF map are upcalled to ovs-vswitchd via the standard slow path.

This model is being explored by the OVS community but is not fully production-ready as of 2025.

Integration Model 3: OVN + eBPF Logical Forwarding (Experimental)

OVN (Open Virtual Network) is the logical networking control plane built on OVS. OVN translates logical network constructs (logical switches, routers, ACLs) into OVS OpenFlow rules. Research projects and prototypes are exploring replacing OVS OpenFlow rules with eBPF programs that implement OVN's logical forwarding table directly:

OVN control plane compiles logical network state into BPF map entries.
eBPF programs attached to TC hooks perform logical port lookup, ACL evaluation, logical routing, and NAT using BPF maps.
The OVS kernel datapath is bypassed entirely for the fast path.

This approach aims to achieve better performance than standard OVS (by eliminating the kernel datapath module overhead) without the operational complexity of OVS-DPDK.

Integration Model 4: eBPF Monitoring OVS Traffic

Independent of data plane integration, eBPF can be used to monitor and instrument OVS traffic:

TC eBPF programs attached to OVS internal ports can count, timestamp, or sample packets flowing through OVS.
Kprobes/tracepoints can hook into OVS kernel module functions to trace flow lookups, upcalls, and cache misses.
Perf ring buffers can stream per-packet metadata to userspace monitoring tools without copying packet data.

This allows building rich OVS observability using eBPF without modifying OVS itself.

Summary of eBPF + OVS Integration Models

Model	eBPF Role	OVS Role	Status
Co-existence	Pod-level policy (Cilium/Calico)	Underlay switching, tunnels	Production
TC offload	Fast-path forwarding via BPF maps	Control plane, slow path	Experimental
OVN-eBPF	Full logical forwarding replacement	Control plane only	Research
Monitoring	Instrumentation, tracing	Data plane (unchanged)	Production

8. Applying DPDK Kernel Bypass at the vNIC Layer in Network Virtualization

Question

How is DPDK kernel bypass applied at the virtual NIC (vNIC) layer in network virtualization, in both cases: (a) when a DPDK-compatible special NIC is available at the physical layer, and (b) when only a standard general-purpose NIC is available?

Answer

The Core Challenge

DPDK's fundamental mechanism is binding a NIC to a userspace driver (via UIO or VFIO) and polling it directly from a userspace application. At the physical layer this is straightforward. The challenge in network virtualization is: how does this kernel bypass reach the virtual NIC (vNIC) inside a VM or container? The guest does not have direct access to the physical NIC — that is the hypervisor's domain.

The solution depends on the NIC available at the physical layer and the virtualization model being used.

Case A: DPDK-Compatible NIC with SR-IOV Support at the Physical Layer

When the physical server has a DPDK-compatible NIC that supports SR-IOV (e.g., Intel X710, Mellanox ConnectX-5/6, Broadcom P2100), the full kernel-bypass path from physical wire to guest application is achievable with the following architecture:

Step 1 — Physical NIC SR-IOV configuration:

# Enable SR-IOV VFs on the physical NIC (PF)
echo 8 > /sys/bus/pci/devices/0000:01:00.0/sriov_numvfs
# 8 VFs are now created: 0000:01:00.1 through 0000:01:00.8

Step 2 — Bind VFs to VFIO for passthrough:

# Bind each VF to vfio-pci driver
dpdk-devbind.py --bind=vfio-pci 0000:01:00.1

Step 3 — Pass VF directly to VM (VFIO device passthrough):

<!-- In VM XML (libvirt/QEMU): VF passed through directly to guest -->
<interface type='hostdev'>
  <source>
    <address type='pci' bus='0x01' slot='0x00' function='0x1'/>
  </source>
</interface>

Step 4 — Inside the VM (DPDK application):

# Inside VM, VF appears as a PCI device
# Bind to vfio-pci and run DPDK application
dpdk-devbind.py --bind=vfio-pci 0000:00:05.0  # VF address inside guest
./dpdk_app -l 0-3 -n 4 -- ...

Resulting packet path (zero kernel involvement end-to-end):

Physical wire
  → Physical NIC hardware (SR-IOV internal switch)
  → VF hardware queues
  → VFIO passthrough (IOMMU mapping)
  → Guest VM memory (DMA directly into hugepage buffers)
  → DPDK PMD (polling guest VF)
  → DPDK application

The IOMMU (Intel VT-d or AMD-Vi) is critical here — it maps the VF's DMA addresses to the VM's guest physical memory, preventing the VF from DMAsing into arbitrary host memory. This provides both performance (zero-copy DMA) and isolation (one VM's VF cannot access another VM's memory).

For containers (not VMs):

The VF is bound to VFIO on the host and exposed to the container's network namespace via the SR-IOV CNI plugin. The container's DPDK application accesses the VF directly through the VFIO file descriptor.

# SR-IOV CNI assigns VF to pod network namespace
# DPDK app inside pod binds VF via VFIO
./pod_dpdk_app -l 0-1 -n 2 --vdev=net_vdev_netvsc0 -- ...

Case B: Standard General-Purpose NIC (No SR-IOV) at the Physical Layer

When the physical NIC does not support SR-IOV (e.g., a standard Intel 1GbE or basic 10GbE adapter), direct VF passthrough is not available. DPDK kernel bypass is still achievable at the vNIC layer, but through a software-mediated path using vhost-user.

The architecture in this case is:

Physical layer: Standard NIC is bound to its standard kernel driver (e.g., igb, ixgbe). No DPDK is used at the physical NIC level because there are no SR-IOV VFs and no dedicated queues to give to VMs.

Host layer — OVS-DPDK or VPP as the vSwitch:

Even without SR-IOV, DPDK can be applied to the physical NIC if and only if the physical NIC is DPDK-compatible (i.e., has a DPDK PMD available). Many standard NICs have DPDK PMDs (igbpmd, ixgbepmd, e1000_pmd). In this case:

# Bind physical NIC to VFIO (it has a DPDK PMD even without SR-IOV)
dpdk-devbind.py --bind=vfio-pci 0000:01:00.0

# Start OVS-DPDK using the physical NIC's DPDK PMD
ovs-vsctl set Open_vSwitch . other_config:dpdk-init=true
ovs-vsctl add-port br0 dpdk0 -- set interface dpdk0 type=dpdk

Guest connectivity via vhost-user:

Without SR-IOV, VMs connect to the DPDK vSwitch (OVS-DPDK or VPP) via vhost-user — a shared-memory virtqueue mechanism:

Guest VM (virtio-net driver)
  ↕ virtqueue (shared hugepage memory)
OVS-DPDK (vhost-user backend, DPDK PMD thread)
  ↕ DPDK PMD polling
Physical NIC (DPDK PMD, standard NIC with DPDK driver)
  ↕
Physical wire

# Add vhost-user port to OVS-DPDK bridge for each VM
ovs-vsctl add-port br0 vhost-user0 \
  -- set Interface vhost-user0 type=dpdkvhostuserclient \
     options:vhost-server-path=/var/run/vhost-user/vhost-user0

# QEMU starts VM with vhost-user socket
qemu-system-x86_64 \
  -chardev socket,id=char0,path=/var/run/vhost-user/vhost-user0 \
  -netdev type=vhost-user,id=mynet0,chardev=char0,vhostforce \
  -device virtio-net-pci,netdev=mynet0,mac=... \
  -mem-prealloc -m 4096 -object memory-backend-file,...

Packet path (no SR-IOV, but DPDK PMD on physical NIC):

Physical wire
  → NIC (standard, DPDK PMD via VFIO)
  → DPDK PMD thread (OVS-DPDK)
  → OVS flow lookup (userspace)
  → vhost-user virtqueue (shared hugepage memory, zero-copy)
  → VM (virtio-net driver sees frames)
  → [optionally: VM DPDK app using virtio-user PMD for further bypass]

For containers without SR-IOV:

Containers use virtio-user PMD to connect to OVS-DPDK via a vhost-user socket, achieving similar kernel-bypass performance to VMs:

# Container DPDK application uses virtio-user PMD
./container_dpdk_app \
  --vdev=net_virtio_user0,path=/var/run/vhost-user/vhost-user1,queues=1

What If the Physical NIC Has No DPDK PMD At All?

If the physical NIC has no DPDK PMD (extremely uncommon for server NICs but possible for some embedded or specialty cards), DPDK cannot control the physical NIC directly. In this case:

The physical NIC operates through the standard Linux kernel driver.
A TAP-based virtual interface bridges the kernel-network world to DPDK.
DPDK's net_tap PMD creates a TAP interface in the kernel; the DPDK application reads/writes via this TAP, while the kernel driver handles the physical NIC.
Performance is lower than native DPDK (kernel is still in the path for physical I/O) but higher than pure kernel networking for internal DPDK processing.

This is a fallback development scenario and not used in production kernel-bypass deployments.

Summary: DPDK at the vNIC Layer

Physical NIC Type	vNIC Mechanism	Kernel in Data Path?	Max Performance
SR-IOV NIC + DPDK PMD	VF passthrough (VFIO) to VM/container	No	Line rate (~100 Gbps)
DPDK-compatible NIC (no SR-IOV)	vhost-user (OVS-DPDK / VPP backend)	No (shared hugepage)	~40–80 Gbps
Any NIC (last resort)	net_tap PMD bridge	Yes (physical I/O)	~10–20 Gbps

9. KVM as a Linux Feature vs. KVM as a Hypervisor

Question

What is the distinction between KVM as a Linux kernel feature and KVM as a standalone hypervisor product?

Answer

The Conceptual Confusion

The term "KVM" is used in two related but distinct contexts, which causes persistent confusion:

KVM as a Linux kernel module — a kernel feature (kvm.ko, kvmintel.ko / kvmamd.ko) that adds hardware-assisted virtualization capability to the Linux kernel.
KVM as a hypervisor — the complete virtualization platform formed by combining the KVM kernel module with QEMU (the userspace device emulator), libvirt (the management API), and associated tooling.

These are not the same thing. KVM alone (just the kernel module) cannot run a VM — it provides CPU and memory virtualization primitives but has no concept of a virtual disk, virtual NIC, or any other device. QEMU provides all of that.

KVM as a Linux Kernel Feature

What it is:

KVM (Kernel-based Virtual Machine) is a loadable Linux kernel module that transforms the Linux kernel into a Type-1 hypervisor. It was merged into the Linux kernel mainline in version 2.6.20 (February 2007). The module is typically split into:

kvm.ko — common architecture-independent code
kvm_intel.ko — Intel VT-x specific implementation
kvm_amd.ko — AMD-V (AMD SVM) specific implementation

What KVM (the module) specifically does:

Opens the /dev/kvm character device to expose its API to userspace
Creates VM objects (KVMCREATEVM ioctl): an isolated virtual address space
Creates virtual CPUs (KVMCREATEVCPU ioctl): a data structure representing a vCPU
Manages guest memory mapping (KVMSETUSERMEMORYREGION): maps userspace memory into the guest physical address space via the CPU's Extended Page Tables (EPT on Intel, NPT on AMD)
Runs guest code (KVM_RUN ioctl): programs the CPU's virtualization extensions to enter guest mode; when the guest performs a privileged operation (I/O, CPUID, MMIO), the CPU exits guest mode and returns control to KVM, which handles the exit or passes it to QEMU
Handles VM exits for CPU instructions that cannot be virtualized in hardware (e.g., some CPUID leaves, deprecated I/O ports)

What KVM (the module) does NOT do:

KVM does not emulate any devices (no virtual disk, no virtual NIC, no virtual keyboard).
KVM does not manage VM lifecycle (create, start, stop, migrate) at a user-facing level.
KVM does not provide any storage, networking, or display virtualization.
KVM is invisible to users — they never interact with it directly.

# KVM module loaded on a Linux host
lsmod | grep kvm
kvm_intel     315392  0
kvm           978944  1 kvm_intel

# The only userspace interface
ls -la /dev/kvm
crw-rw---- 1 root kvm 10, 232 /dev/kvm

KVM as a Hypervisor (KVM + QEMU + libvirt)

When people say "KVM hypervisor," they typically mean the complete stack:

┌──────────────────────────────────────────────────────────┐
│              Management Layer                             │
│  OpenStack Nova / virt-manager / Cockpit / libvirt CLI   │
└──────────────────────────┬───────────────────────────────┘
                           │
┌──────────────────────────▼───────────────────────────────┐
│              libvirt (virtualization management API)      │
│  Translates management calls to QEMU monitor commands    │
└──────────────────────────┬───────────────────────────────┘
                           │
┌──────────────────────────▼───────────────────────────────┐
│              QEMU (per-VM userspace process)              │
│  - Emulates all virtual devices (NIC, disk, display)     │
│  - Uses /dev/kvm for CPU and memory virtualization        │
│  - Manages TAP, vhost-user, virtio device backends        │
└──────────────────────────┬───────────────────────────────┘
                           │ ioctl() on /dev/kvm
┌──────────────────────────▼───────────────────────────────┐
│         KVM Kernel Module (kvm.ko + kvm_intel.ko)         │
│  - vCPU creation and execution (VT-x / AMD-V)             │
│  - Guest memory isolation (EPT / NPT)                    │
│  - VM exit handling                                       │
└──────────────────────────┬───────────────────────────────┘
                           │
┌──────────────────────────▼───────────────────────────────┐
│              Hardware                                     │
│  Intel VT-x / AMD-V CPU, IOMMU, NIC, Storage              │
└──────────────────────────────────────────────────────────┘

QEMU's role: QEMU is a full machine emulator. Without the KVM module, QEMU emulates the entire CPU in software (extremely slow). With KVM, QEMU delegates CPU execution to KVM (fast hardware execution) while retaining control of device emulation. QEMU spawns one process per VM; within that process, each vCPU is a thread that executes KVM_RUN in a loop.

libvirt's role: libvirt is an abstraction layer and management daemon (libvirtd). It provides a unified API for managing VMs across different hypervisors (KVM/QEMU, Xen, LXC, VMware ESXi). It translates high-level commands (virsh start myvm) into the appropriate QEMU monitor protocol commands and manages persistent VM configuration in XML format.

The Key Distinction

Dimension	KVM (kernel module only)	KVM "Hypervisor" (full stack)
What it is	Linux kernel module (`kvm.ko`)	KVM + QEMU + libvirt + tooling
What it does	CPU & memory virtualization primitives	Complete VM lifecycle management
Where it runs	Kernel space	Kernel (KVM) + Userspace (QEMU, libvirt)
User interaction	None (internal API via /dev/kvm)	virsh, virt-manager, OpenStack, etc.
Device emulation	None	QEMU emulates all devices
Can run VMs alone?	No	Yes
Type classification	Type-1 component (inside Linux kernel)	Type-1 hypervisor (Linux is the host OS)

KVM in Linux vs. Xen: The Philosophical Difference

This distinction also clarifies the difference between KVM and Xen:

KVM approach: Linux is the primary OS. KVM is a feature added to Linux that allows it to also be a hypervisor. Linux was not designed as a hypervisor — KVM adds that capability to an existing general-purpose kernel.
Xen approach: Xen is the primary OS. Xen was designed from the ground up as a hypervisor. Linux runs as dom0 — a privileged guest — not as the host OS.

Both produce a Type-1 hypervisor outcome, but KVM integrates virtualization into an existing general-purpose OS, while Xen separates hypervisor and management OS concerns by design.

KVM in a Networking Virtualization Context

From the perspective of network virtualization:

KVM (module) has no networking role. It manages CPU and memory only.
QEMU creates TAP devices for each VM's virtual NIC, optionally accelerated by vhost-net (kernel) or vhost-user (DPDK userspace).
libvirt automates the creation of bridges, TAP devices, and OVS port attachments when VMs are created.
OVS connects TAP devices from multiple QEMU processes into a unified virtual network fabric.
SR-IOV + VFIO allows QEMU to pass a physical VF directly into a VM, bypassing TAP, OVS, and the Linux network stack entirely.

The full KVM hypervisor stack, not the KVM kernel module alone, is what participates in network virtualization architectures.

← Previous

Question_Answer

Network Virtualization — Deep Dive Q&A Reference

Table of Contents

1. Virtual Connections in Network Virtualization (Physical Analogues)

Question

Answer

Master Mapping Table

Detailed Explanations

2. OpenStack Directly on a Host OS — How VMs Are Created Without a Type-2 Hypervisor

Question

Answer

Clarifying the Hypervisor Model

What Happens on Linux: KVM + QEMU

On Windows: No Native KVM — HyperV or QEMU Software Emulation

On macOS: QEMU with HVF (Hypervisor.framework)

Summary: OpenStack VM Creation on Bare-Metal Linux (Production)

3. The Role of OVS in Network Virtualization — Why It Appears Across Every Technique

Question

Answer

What OVS Fundamentally Is

What OVS Does in Standard Packet Processing

Why OVS Appears in DPDK (Packet Bypass) Deployments

Why OVS Appears in eBPF (Packet Filtering) Deployments

The Core Reason OVS Appears Everywhere

4. OVS Variants Compared — Independent, OVS-DPDK, and OVS-eBPF

Question

Answer

Similarity: All Three Share the Same Control Plane

Detailed Comparison

Packet Flow Comparison

When to Use Each Variant

5. Monitoring TAP vs. Network TAP — Differences and Similarities

Question

Answer

The Shared Conceptual Root

Hardware Network TAP (Test Access Point)

Linux TAP Virtual Device

Comparison Table

The Common Ground

OVS SPAN as a Virtual Equivalent of a Hardware Network TAP

6. Xen Hypervisor — Purpose, Architecture, and Direct Installation on a Host OS

Question

Answer

What Xen Is

Xen Architecture

Xen Virtualization Modes

Why Xen Is Used

Can Xen Be Installed Directly on a Host OS?

Xen Networking in Virtualization Context

7. Can eBPF Be Used With OVS?

Question

Answer

Short Answer

Integration Model 1: Complementary Co-Existence (Most Common)

Integration Model 2: eBPF Accelerating OVS Flow Offload

Integration Model 3: OVN + eBPF Logical Forwarding (Experimental)

Integration Model 4: eBPF Monitoring OVS Traffic

Summary of eBPF + OVS Integration Models

8. Applying DPDK Kernel Bypass at the vNIC Layer in Network Virtualization

Question

Answer

The Core Challenge

Case A: DPDK-Compatible NIC with SR-IOV Support at the Physical Layer

Case B: Standard General-Purpose NIC (No SR-IOV) at the Physical Layer

What If the Physical NIC Has No DPDK PMD At All?

Summary: DPDK at the vNIC Layer

9. KVM as a Linux Feature vs. KVM as a Hypervisor

Question

Answer

The Conceptual Confusion

KVM as a Linux Kernel Feature

KVM as a Hypervisor (KVM + QEMU + libvirt)

The Key Distinction

KVM in Linux vs. Xen: The Philosophical Difference

KVM in a Networking Virtualization Context