Moving Workloads Between Nodes

Stratum is a software-defined networking platform, not a hypervisor — it manages the network identity of a workload, not the workload's compute or memory. There is no built-in VM live-migration. What Stratum does provide is a network model that lets a workload keep its IP and MAC when it moves between nodes, because a network's endpoints live in the cluster's shared state and are reachable on every host through the VXLAN overlay.

If you run your own hypervisor (QEMU/KVM, etc.) and migrate a guest's memory between hosts yourself, Stratum keeps the network side consistent — you simply move the endpoint binding to the destination node.

Why the network identity survives a move

Each managed network is stretched across all cluster members via VXLAN, and every endpoint profile (IP ↔ MAC) is stored in the cluster's replicated state. The overlay forwards frames for an endpoint's MAC to whichever node currently has that endpoint bound. Because the IP and MAC never change, ARP and NDP caches on peer endpoints stay valid and active TCP connections are not reset by the move itself. Validate cross-host forwarding against your own topology before production rollout.

Moving an endpoint

Moving a workload's network identity from one node to another is a detach on the source followed by an attach on the destination, claiming the same IP:

# On the source node — free the endpoint
sudo cenvero-str-ctl network detach <endpoint-id>

# On the destination node — re-claim the same IP
sudo cenvero-str-ctl network attach <network-id> --ip 10.20.0.50

The destination node programs the data plane for the endpoint (including the IP↔MAC anti-spoof binding), and the cluster's shared state updates the MAC-to-node mapping. The VXLAN overlay then delivers frames for that MAC to the new node. Sequence the detach/attach close together — and cut over your actual compute workload at the same time — to minimize the window where the endpoint is unbound.

If the workload has its own hardware address, name it again

This is the detail that catches people out.

When you let Stratum choose the hardware address, it is derived from the IP. Re-claiming the same address on another node therefore reproduces the identical hardware address on its own, which is exactly why the identity survives the move with nothing extra from you.

But if you originally attached the endpoint with a hardware address **of your own** — because the workload already had one — then claiming just the IP on the destination gives it the derived address instead, not the one it had. The workload's identity changes mid-move: peer ARP caches point at an address that no longer answers, and the anti-spoof binding now expects a different address than the workload actually sends, so its traffic is dropped as spoofed.

Pass the same hardware address again and the move is clean:

# The workload has its own hardware address — supply it on the destination too
sudo cenvero-str-ctl network attach <network-id> --ip 10.20.0.50 --mac 52:54:00:ab:01:02

If you are unsure which case you are in, read the endpoint back before detaching it and use whatever address it reports.

Pre-move checklist

• Both nodes are healthy cluster members: cenvero-str-ctl cluster status
• The destination node has capacity for the workload: cenvero-str-ctl node info
• The management network between the nodes has sufficient bandwidth
• Firewall rules referencing the endpoint by network and address remain valid

See also

• Clustering Overview — VXLAN overlay and cluster membership.
• Gateway High Availability — failing over Gateway nodes.
• CLI Reference — the network command group (attach / detach / endpoints).