Virtual Network (OVN)
The Virtual Network feature builds software-defined networks on top of Open Virtual Network (OVN). Where an OVS bridge gives you a switch on one host, OVN gives you switches and routers that span every host in your deployment, with addressing, firewalling and load balancing defined once and applied everywhere.
Use it when you want tenant networks that are independent of your physical topology: a subnet that follows a virtual machine when it migrates, several tenants with overlapping address ranges, or egress to the internet through a single controlled address.
Find it under Network > OVN.
How it relates to OVS
OVN does not replace Open vSwitch; it drives it. Each host keeps an OVS integration bridge (br-int), and OVN programs the flows in it. You continue to use the OVS pages for physical uplinks, bonds and bridge-level concerns, and the OVN pages for the logical network above them.
A practical consequence: every host that runs OVN workloads needs the OVS client (ovs-vsctl) present, because Vapor uses it to attach a virtual machine's interface to br-int. Vapor checks for this during activation and reports it on the OVN status card.
The building blocks
Logical switch
A Layer-2 broadcast domain. Ports attached to the same logical switch can reach each other directly, whatever host they sit on — OVN carries the traffic between hosts in a Geneve tunnel. A logical switch normally holds one subnet.
Logical switch port
A single attachment point on a logical switch: a virtual machine interface, a container, or a router connection. A port carries a MAC address and one or more IP addresses, and may take its address from OVN's built-in DHCP server.
Logical router
A Layer-3 router that joins logical switches. It provides the default gateway for each subnet attached to it, and it is where NAT rules, static routes and routing policies live.
VPC
A convenience view over a logical router and the switches attached to it, so you can treat "a router, its subnets and their DHCP" as one thing. Creating a VPC creates the router, the first subnet's logical switch, the router port that joins them and, if asked, the DHCP options for that subnet. The VPCs page lists each VPC with the router that backs it, so you can always cross-reference the Logical Routers page when debugging.
A VPC is a lens, not a separate object: everything it creates remains visible and editable on the individual pages.
Chassis
A host that participates in the data plane. Every hypervisor running OVN workloads registers as a chassis, identified by its system-id, and announces the IP address its tunnels terminate on.
What the pages give you
| Page | Purpose |
|---|---|
| VPCs | Create and remove a router with its first subnet in one step |
| Logical Switches | Subnets, their CIDR and DHCP state, and a per-switch topology view |
| Logical Switch Ports | Every attachment point, its addresses and whether OVN has bound it |
| Logical Routers | Router ports, static routes, routing policies, NAT rules |
| Load Balancers | Virtual IPs with backend pools, and groups that apply a set of them to several switches at once |
| QoS & Meters | Bandwidth limits and DSCP marking per port, and meters used for rate-limiting rule logs |
| Security Groups | Port groups and address sets, and the ACLs applied to them |
| DHCP Options | Address pools and options served to ports |
| DNS | Hostname records answered inside the logical network |
| Chassis | Which hosts are participating, with their tunnel endpoints |
| Topology | A visual map of switches, routers and ports |
Before you start
OVN has to be activated on a host before any of these pages do anything. Activation records where the OVN databases are and configures this host's chassis. See Activating the Virtual Network.
Three deployment shapes are supported:
- Vapor-native — Vapor runs the OVN databases itself, on one host or as a cluster. Recommended for a standalone Vapor deployment. See Vapor-native clusters.
- Existing external OVN — you already run
ovn-centralsomewhere and Vapor joins as a client and a chassis. - Existing kube-ovn cluster — Vapor shares the OVN databases belonging to a Kubernetes CNI. This one carries real constraints; read the mode 3 section of the activation guide before choosing it.