Virtual Machines and Migration
Once a datacenter has a Virtual Network, its logical switches become networks a VM can be attached to, and the fabric changes what migration has to do — mostly by making it do less.
Attaching a VM to a logical switch
In the VM wizard and in a VM's NIC settings, OVN logical switch is a network type alongside bridges and libvirt networks. Pick the switch; Cockpit passes the choice to Vapor.
Two things you do not have to do:
- Name the port. Vapor creates the logical switch port and gives it the name libvirt requires (a UUID). Cockpit never invents one.
- Choose an address. With DHCP on the switch, Vapor pins the interface's MAC on the port so OVN's DHCP answers the guest. This pinning is what makes DHCP work: without it OVN and libvirt pick different MACs and the guest never gets a lease.
The VM's network then shows the logical switch by name, wherever the VM runs. Cockpit learns the attachment from the host's sync, so it appears in the inventory shortly after the VM is created.
Kubernetes provisioner
The provisioner offers logical switches next to distributed networks. Both qualify for the same reason — every node's host is on them — so a cluster whose nodes land on different hosts, or different clusters within the datacenter, has one network.
Migration within a deployment
A logical switch is the same switch on every chassis in the deployment. So a VM on one needs no network mapping to migrate, in either direction and by any means: manual migration, DRS, HA restart, or evacuation. The migration wizard recognises the interface and skips the question — it shows the network as needing no mapping, in the same way it does for a distributed network.
Live migration is fully supported here. The VM's logical port simply rebinds to the destination chassis; nothing about its address changes.
This is stronger than a distributed network, and worth understanding why: a distributed network is per-host configuration that happens to agree, and an identically named network on two hosts is a coincidence Cockpit has to check. A logical switch is one object; there is nothing to check.
Migration between deployments
Two datacenters have two fabrics, and a logical switch in one is not the same as a same-named switch in the other — there is no Layer-2 between them, and their tunnels do not meet. A VM crossing that boundary is changing networks, and the migration wizard treats it that way.
Cold only
Live migration between deployments is refused, by Cockpit and by Vapor. The guest's MAC and IP would reappear on a different broadcast domain with every upstream cache stale, and a "successful" live migration would hand back a running VM with a dead NIC. Shut the VM down first; the wizard says so and disables the live option.
Mapping the interface
For each interface on a logical switch, the wizard asks where it should land, with three kinds of target:
| Target | What happens |
|---|---|
| A logical switch in the destination deployment | A new port is created on that switch, the VM's MAC is pinned on it, and the interface is rewired to it. If a switch with the same name exists in the destination, the wizard proposes it — the mirrored-fabric case, where two datacenters carry the same network plan. |
| A bridge on the destination host | The interface stops being an OVN interface: it is attached to the bridge like any bridged NIC. |
| A libvirt network on the destination host | Likewise, attached to the network. |
The reverse — a bridged or libvirt-network interface mapped onto a logical switch — works the same way.
What happens to the address
The MAC always survives. The IP is conditional, and the wizard states the verdict for each interface before you migrate rather than letting the guest discover it:
- Preserved — the target is a logical switch whose subnet contains the VM's current address. The address is pinned on the new port, so the guest's lease keeps matching.
- Will change — the target switch has a different subnet. The guest will get a new address from that subnet's DHCP, or needs re-addressing if it is static.
- Not applicable — the target is a bridge or libvirt network. OVN is no longer answering DHCP; whatever serves that network is.
Ports are cleaned up, not leaked
The port on the source switch is removed only after the VM is defined on the destination, and only for interfaces that actually moved to a different network. If the destination define fails, the new port is removed and the source is left exactly as it was — the VM keeps working where it is.
Evacuation and HA
Host evacuation and HA restarts use the same rule: within the deployment, a logical switch needs no mapping and the VM restarts on its network. They never move a VM between deployments; that is always an explicit migration.
Related topics
- VM Migration — the migration wizard in full.
- DRS & High Availability — features that rely on a network being the same across hosts.
- Vapor: VPCs & Virtual Machines — creating the switches and VPCs VMs attach to.