Virtual Network (OVN)
Virtual Network gives a whole datacenter one software-defined network fabric, built on Open Virtual Network (OVN). Where a distributed network is the same configuration applied to each host in a cluster, a Virtual Network is one network that every host in the datacenter is part of: a logical switch exists once, and a virtual machine attached to it is on that switch whichever host it runs on and whichever cluster that host belongs to.
Use it when you need networks that are independent of your physical topology — tenant subnets that follow a VM across clusters, several tenants with overlapping address ranges, routing and NAT defined once for the datacenter, or a network for a Kubernetes cluster whose nodes are spread across hosts.
Additional license required
Virtual Network is a separately licensed feature. It is not included in the base Cockpit license: the datacenter cannot be activated until your license carries the Virtual Network entitlement. Contact your Awanio representative to add it to your subscription, then import the updated license through Cockpit's License Management. Hosts keep their own Vapor license under Host › Configure › System › Licensing.
Cockpit does not run OVN itself. It activates it on the Vapor hosts, keeps them in step, and shows you the result. The OVN concepts — logical switches, routers, VPCs, ACLs, load balancers — are Vapor's, and the Vapor Virtual Network guide describes them in depth. This section is about what Cockpit adds on top: enablement for a whole datacenter, membership, and how the fabric shows up in the rest of Cockpit.
Where it lives
| Place | What you see | What you can do |
|---|---|---|
| Datacenter › Virtual Network | The activation card, or the running deployment: mode, database addresses, member hosts and their state, and the fabric's inventory (VPCs, logical switches, routers, ports, security groups, load balancers, DHCP, chassis). | Activate, sync, add or remove members, deactivate. |
| Cluster › Networks | The datacenter's logical switches, marked Inherited. | Read only. A cluster inside the datacenter uses them; it does not own them. |
| Host › Configure › Networking › Virtual Network | This host's chassis: system ID, encapsulation IP, role, the deployment it belongs to, and its tunnel peers. | Read only, plus Remove from OVN deployment. |
The Virtual Switches page under the same Networking menu is a different thing: it is the host's own libvirt networks and OVS bridges (the Switches and Topology tabs). OVN drives those bridges; it does not replace them.
Datacenter, not cluster
Virtual Network is enabled per datacenter, and every host in that datacenter — directly under it, in a folder, or in any cluster — becomes part of the fabric.
The reason is the same one the public clouds settled on. A cluster in Cockpit is a compute boundary: hosts of identical specification, so DRS and HA can move a VM between siblings, and operators group them by workload — a cluster for applications, another for databases. Binding the network to that boundary would mean the two could never share a subnet. A VPC in a cloud provider is instead a regional object that spans every availability zone in the region; only subnets are pinned to a zone. Datacenter ≈ region, cluster ≈ availability zone. OVN goes one step further — a logical switch has no zone at all, it spans every chassis — so the datacenter is the only level that does not fragment the fabric.
One datacenter has at most one Virtual Network deployment. Everything inside it — VPCs, switches, routers — is a logical object within that one fabric.
Three ways to get a fabric
The activation wizard offers three modes. They differ in who runs the OVN databases; in every mode, the datacenter's hosts join as chassis (the hypervisor side of OVN, which programs the switches on each host).
| Mode | Who runs the databases | What Cockpit does on the hosts |
|---|---|---|
| Form a Vapor-native OVN deployment | Cockpit picks 1, 3 or 5 hosts to be centrals, and they run the databases as a RAFT cluster. | Bootstraps the first central, joins the others one at a time, then joins every other host as a chassis. |
| Join an existing external OVN deployment | Something outside Cockpit — another management system, or an OVN cluster you run yourself. | Points every host at the addresses you give and registers them as chassis. Never touches the databases. |
| Join an existing Kube-OVN cluster | The kube-ovn CNI on a Kubernetes cluster that the hosts are nodes of. | Records the connection and reads the databases. Touches nothing on the hosts: the CNI owns the chassis, the OVS settings and ovn-controller. |
Pick vapor-native for a self-contained datacenter. Pick external when the OVN control plane already exists and is somebody else's to run. Pick Kube-OVN when your hypervisors are also Kubernetes nodes running kube-ovn and you want VMs on the same networks as pods — and read the Kube-OVN notes before you do, because that mode has consequences the other two do not.
Activating the Virtual Network →
What a deployment looks like once it is up
The datacenter's Virtual Network tab shows:
- Mode and the northbound / southbound addresses the hosts use. For a vapor-native deployment these list every central, because OVN clients only talk to the current leader and must know all the members.
- Status —
activewhen every member is in,partialwhen some are not,errorwhen none are. - Members — one row per host in the datacenter with its role (
centralorchassis), encapsulation IP and state:synced,pending,errorwith the reason, orexcludedwith the reason (Kube-OVN mode only; see membership). - A drift banner when the datacenter's hosts and the deployment's members no longer match — a host was added or moved — with a Sync action to reconcile.
- The inventory of the fabric, read through one of the member hosts: VPCs, logical switches, routers, ports, security groups, load balancers, DHCP options and chassis. Creating and editing those objects is done on the Vapor host pages; Cockpit shows them and uses them.
Operating the Virtual Network →
Using it
Once a datacenter has a fabric, its logical switches appear wherever Cockpit lets you pick a network:
- Virtual machine wizard / NIC settings — OVN logical switch is a network type alongside bridges and libvirt networks. Cockpit hands the choice to Vapor, which creates the logical port and pins the MAC so OVN's DHCP answers the guest.
- Kubernetes provisioner — logical switches are offered next to distributed networks, since both reach every host.
- Migration — within one deployment a VM on a logical switch needs no network mapping at all: the switch is the same on every host. Between two deployments it is a different story, described under Virtual machines and migration.
VMs, Kubernetes and migration →
Related topics
- Virtual Networking overview — host networks and distributed networks, and when to use each.
- Vapor: Virtual Network (OVN) — the OVN objects themselves.
- Vapor: Virtual Network Troubleshooting — what to look at on a host when the fabric misbehaves.