{
    "product": "Cenvero Stratum",
    "generated_at": "2026-08-03T07:18:27+00:00",
    "format": "cenvero-docs-v1",
    "document_count": 1,
    "documents": [
        {
            "slug": "clustering/live-migration",
            "title": "Moving Workloads Between Nodes",
            "category": "Clustering",
            "url": "https://stratum.cenvero.com/docs/clustering/live-migration",
            "headings": [
                {
                    "level": 1,
                    "text": "Moving Workloads Between Nodes"
                },
                {
                    "level": 2,
                    "text": "Why the network identity survives a move"
                },
                {
                    "level": 2,
                    "text": "Moving an endpoint"
                },
                {
                    "level": 3,
                    "text": "If the workload has its own hardware address, name it again"
                },
                {
                    "level": 2,
                    "text": "Pre-move checklist"
                },
                {
                    "level": 2,
                    "text": "See also"
                }
            ],
            "word_count": 599,
            "markdown": "# Moving Workloads Between Nodes\n\nStratum is a software-defined networking platform, not a hypervisor — it manages\nthe *network identity* of a workload, not the workload's compute or memory. There\nis no built-in VM live-migration. What Stratum does provide is a network model\nthat lets a workload **keep its IP and MAC when it moves between nodes**,\nbecause a network's endpoints live in the cluster's shared state and are reachable\non every host through the VXLAN overlay.\n\nIf you run your own hypervisor (QEMU/KVM, etc.) and migrate a guest's memory\nbetween hosts yourself, Stratum keeps the network side consistent — you simply\nmove the endpoint binding to the destination node.\n\n## Why the network identity survives a move\n\nEach managed network is stretched across all cluster members via VXLAN, and every\nendpoint profile (IP ↔ MAC) is stored in the cluster's replicated state. The\noverlay forwards frames for an endpoint's MAC to whichever node currently has that\nendpoint bound. Because the IP and MAC never change, ARP and NDP caches on peer\nendpoints stay valid and active TCP connections are not reset by the move itself.\nValidate cross-host forwarding against your own topology before production rollout.\n\n## Moving an endpoint\n\nMoving a workload's network identity from one node to another is a detach\non the source followed by an attach on the destination, claiming the *same* IP:\n\n```bash\n# On the source node — free the endpoint\nsudo cenvero-str-ctl network detach <endpoint-id>\n\n# On the destination node — re-claim the same IP\nsudo cenvero-str-ctl network attach <network-id> --ip 10.20.0.50\n```\n\nThe destination node programs the data plane for the endpoint (including the\nIP↔MAC anti-spoof binding), and the cluster's shared state updates the\nMAC-to-node mapping. The VXLAN overlay then delivers frames for that MAC to the\nnew node. Sequence the detach/attach close together — and cut over your actual\ncompute workload at the same time — to minimize the window where the endpoint is\nunbound.\n\n### If the workload has its own hardware address, name it again\n\nThis is the detail that catches people out.\n\nWhen you let Stratum choose the hardware address, it is **derived from the IP**.\nRe-claiming the same address on another node therefore reproduces the identical\nhardware address on its own, which is exactly why the identity survives the move\nwith nothing extra from you.\n\nBut if you originally attached the endpoint with a hardware address **of your\nown** — because the workload already had one — then claiming just the IP on the\ndestination gives it the *derived* address instead, not the one it had. The\nworkload's identity changes mid-move: peer ARP caches point at an address that no\nlonger answers, and the anti-spoof binding now expects a different address than\nthe workload actually sends, so its traffic is dropped as spoofed.\n\nPass the same hardware address again and the move is clean:\n\n```bash\n# The workload has its own hardware address — supply it on the destination too\nsudo cenvero-str-ctl network attach <network-id> --ip 10.20.0.50 --mac 52:54:00:ab:01:02\n```\n\nIf you are unsure which case you are in, read the endpoint back before detaching\nit and use whatever address it reports.\n\n## Pre-move checklist\n\n- Both nodes are healthy cluster members: `cenvero-str-ctl cluster status`\n- The destination node has capacity for the workload: `cenvero-str-ctl node info`\n- The management network between the nodes has sufficient bandwidth\n- Firewall rules referencing the endpoint by network and address remain valid\n  after the move — the IP is preserved, so no rule changes are needed\n\n## See also\n\n- [Clustering Overview](/docs/clustering/overview) — VXLAN overlay and cluster membership.\n- [Gateway High Availability](/docs/clustering/high-availability) — failing over Gateway nodes.\n- [CLI Reference](/docs/cli) — the `network` command group (`attach` / `detach` / `endpoints`).\n"
        }
    ]
}