Operating the Virtual Network
Once a datacenter has a Virtual Network, Cockpit's job is to keep the deployment and the datacenter in step: every host that belongs to the datacenter should be a member, every member should be healthy, and every host should know about every other. This page is about that upkeep.
Who is a member
The Members table on the datacenter's Virtual Network tab has one row per host in the datacenter subtree. Each row carries:
| Field | Meaning |
|---|---|
| Role | central runs the OVN databases (vapor-native only); chassis is a hypervisor on the fabric. |
| Encap IP | The address this host's Geneve tunnels use. |
| Status | synced — in and healthy. pending — being applied. error — the last apply failed; the reason is shown. excluded — deliberately left out; the reason is shown. |
excluded only occurs in Kube-OVN mode, for hosts that are not kube-ovn nodes or lack the OVN client tools. Nothing is applied to an excluded host, it does not count toward the deployment's status, and it does not register as drift. Fix the cause and Sync to bring it in.
The deployment's own status follows from the members: active when every participating member is synced, partial when some are, error when none are.
Hosts that join, move or leave
Cockpit keeps membership aligned with the inventory tree automatically:
- A host added to the datacenter — directly, in a folder, or in one of its clusters — is enrolled as a chassis as soon as it is claimed and synced. If the enrolment fails, the host is still added; its member row carries the error and Sync will retry.
- A host moved into the datacenter from elsewhere is enrolled the same way.
- A host moved out of the datacenter is deactivated first. Cockpit asks you to confirm, because this cuts every virtual machine interface on that host that sits on a logical switch. Move or stop those VMs first.
- A new host never becomes a central. Changing the RAFT quorum is an explicit decision; new hosts always join as chassis. To promote one, use Add member with the central role.
A drift banner appears when the datacenter and the deployment disagree — a host is missing from the members, a member is no longer in the datacenter, or a member is not synced. Cockpit checks for this every minute and marks the deployment partial while it persists. Sync reconciles it.
Removing a single host
On the host's own page — Host › Configure › Networking › Virtual Network — Remove from OVN deployment takes that one host out: Cockpit deactivates OVN on it through Vapor and re-pushes the member list to everyone else. The same confirmation applies: VM interfaces on logical switches on that host lose connectivity.
Sync
Sync on the datacenter tab does three things in one pass: re-applies the configuration to every member that is not synced, pushes the complete member list to every member, and recomputes drift and status.
The second part is not optional bookkeeping. OVN's database clients only talk to the current cluster leader, so each host has to know every central to keep working when leadership moves. Any change to the membership — a central added or removed — is therefore pushed to all hosts, not just the one that changed. Sync is how you force that after a failure.
Sync never replaces database files, whatever state a central is in. That permission is only ever given once, at activation, by you.
Deactivating
Deactivate on the datacenter tab takes every member out of the fabric and removes the deployment from Cockpit. What happens on each host depends on the mode:
| Mode | On each host |
|---|---|
| Vapor-native | The chassis is released: ovn-controller is stopped and the host forgets the database addresses. The database files on the centrals are left in place — they hold the entire logical configuration, and deleting them is a decision for whoever owns the host, not for Cockpit. |
| External | The chassis is released the same way. The external databases are untouched. |
| Kube-OVN | Nothing on the host is touched. The CNI owns the chassis; Cockpit only forgets the connection. Pods keep their network. |
After deactivation the fabric's switches remain in Cockpit's inventory briefly: a host's OVN inventory is only removed after two consecutive syncs report it inactive, so that a transient read cannot delete real state. Expect the rows to disappear within a couple of minutes.
To reactivate a vapor-native datacenter later, the preflight will find the centrals' existing databases and — since they still form a cluster — leave them in place. The logical configuration comes back with them.
When a deployment is partial
partial means the fan-out finished and some hosts did not make it. Read the per-host error; it names the check or the step that failed. The usual causes, and what to do:
A host was unreachable at apply time. Fix connectivity and Sync.
"Existing cluster member reachable" failed on a joining central. The first central bootstrapped, but the port the others join through is not answering. This usually means the database on that first central is not actually running — look at Host › Configure › Networking › Virtual Network for that host, and at journalctl -u ovn-ovsdb-server-nb on it. Once it is up, Sync joins the others.
"OVN client tools missing" or "not a kube-ovn node". The host is excluded, not failed. See membership.
A central applied but did not register. Vapor accepted the configuration but the host is not in the southbound database. On the host, check ovn-controller is running and that its ovn-remote points at the deployment's southbound addresses. The Vapor page for the host shows both.
The MTU warning was acknowledged and VMs cannot pass traffic. They connect, get an address and then stall on anything larger than a small packet. That is the missing Geneve headroom. Either raise the underlay MTU on every host's encapsulation interface to at least 1558, or set the guest MTU to 1442 (for a 1500-byte underlay).
For anything below Cockpit — a logical switch that exists but does not forward, DHCP that does not answer, a tunnel that will not come up — the host-level view is where the answer is: Vapor: Virtual Network Troubleshooting. In particular, OVN's northbound database accepts configuration that ovn-controller then refuses to compile, and the only place that is reported is /var/log/ovn/ovn-controller.log on the host.
What Cockpit will and will not do
It is worth being clear about the boundary, because it is deliberate:
- Cockpit does activate, keep in step, re-push membership, verify registration, and show the inventory.
- Cockpit does not replace database files without the confirmation given at activation, does not restart a central's databases during a routine sync, and in Kube-OVN mode does not touch the host at all.
- Creating and editing the network objects themselves — VPCs, switches, routers, ACLs, load balancers — is done on the Vapor host pages. Cockpit reads them from a member and uses them.