Moving Workloads Between Nodes

Stratum does not move running workloads between nodes: there is no live migration, and a Stratum virtual machine cannot move to another node yet (see Compute limits). What Stratum does provide is a network model that lets a workload you run yourself **keep its IP and MAC when it moves between nodes** — if you have prepared both nodes for it.

If you run your own hypervisor or containers and move a workload between hosts yourself, Stratum keeps the network side consistent — you move the endpoint from the source node to the destination node. The nodes do not need to be in a cluster, and being in one does not move anything for you: each endpoint still belongs to one node (see Clustering Overview).

What has to be in place first

Neither of these happens automatically:

The network exists on the destination node too. A network belongs to the node it was created on. Create one with the same subnet and gateway on the destination. It gets its own network id there — use that id when you attach.
The two nodes are joined by an overlay carrying that subnet, so workloads left on the source node can still reach the one that moved, and the other way round. See Networking Overview → Stretching a network across nodes.

Why the network identity survives a move

An endpoint's hardware address is derived from its IP unless you supplied one yourself. Claiming the same IP on the destination therefore reproduces the same IP and MAC pair, so ARP and NDP caches on other workloads 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 on its copy of the network
sudo cenvero-str-ctl network attach <destination-network-id> --ip 10.20.0.50

The destination node registers the IP↔MAC pairing in its packet path, so the workload's traffic is accepted there. If you registered overlay peers with workload hardware addresses, update those entries on the other nodes so they point at the destination node; a peer registered without a hardware address needs no change, because the address is learned from traffic. Sequence the detach/attach close together — and cut over the workload itself 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

The destination node has a network with the same subnet: cenvero-str-ctl network list
The overlay between the two nodes is up in both directions: cenvero-str-ctl vxlan peers <vni> on each
The network between the nodes has sufficient bandwidth
Firewall rules are per node: recreate on the destination any rule that references the endpoint's address — the IP is preserved, so the rule itself does not change