{
    "product": "Cenvero Stratum",
    "generated_at": "2026-10-10T15:59:32+00:00",
    "format": "cenvero-docs-v1",
    "document_count": 1,
    "documents": [
        {
            "slug": "compute/lifecycle",
            "title": "Lifecycle and Restarts",
            "category": "Compute",
            "url": "https://www.stratum.cenvero.com/docs/compute/lifecycle",
            "headings": [
                {
                    "level": 1,
                    "text": "Lifecycle and Restarts"
                },
                {
                    "level": 2,
                    "text": "Starting and stopping"
                },
                {
                    "level": 2,
                    "text": "States"
                },
                {
                    "level": 2,
                    "text": "What happens when…"
                },
                {
                    "level": 2,
                    "text": "Events"
                },
                {
                    "level": 2,
                    "text": "See also"
                }
            ],
            "word_count": 1179,
            "markdown": "# Lifecycle and Restarts\n\nThe node keeps a record of every virtual machine — its size, its interfaces, and\nwhether you want it **running** or **stopped** — and that record is what counts.\nThe node starts the machine itself once the machine's networking is in place,\nand puts things back when something changes them behind its back.\n\n> Part of [Compute](/docs/compute/overview), in early access.\n\n## Starting and stopping\n\n```bash\nsudo cenvero-str-ctl vm start vm-3f9a1c2e\nsudo cenvero-str-ctl vm stop vm-3f9a1c2e               # ask the guest to shut down\nsudo cenvero-str-ctl vm stop vm-3f9a1c2e --timeout 300 # wait longer before forcing it off\nsudo cenvero-str-ctl vm force-stop vm-3f9a1c2e         # power off at once\nsudo cenvero-str-ctl vm restart vm-3f9a1c2e            # stop, then start again\nsudo cenvero-str-ctl vm restart vm-3f9a1c2e --force    # power off, then start again\n```\n\n`vm stop` presses the machine's power button: the guest shuts down cleanly. If it\nhas not finished after the timeout (120 seconds unless you say otherwise), the\nmachine is powered off. A guest that is still booting may not react to the power\nbutton in time. Before every start, the machine's port, its protection and its\nfirst-boot disk are put in place again.\n\n| Method | Path | Body | Answer |\n|---|---|---|---|\n| `POST` | `/api/v1/vms/{id}/start` | — | **200** `running`, or **202** `starting` while it boots |\n| `POST` | `/api/v1/vms/{id}/stop` | `{\"timeout_seconds\": 300}` (optional, up to 3600) | **202** |\n| `POST` | `/api/v1/vms/{id}/force-stop` | — | **202** |\n| `POST` | `/api/v1/vms/{id}/restart` | `{\"force\": true}` (optional) | **202** |\n\nEach answer names the **task** that records the operation (`\"task\"`, and a\n`Location` header). A stop's task stays running until the guest is off — \"the\nguest shut down\", or \"forced off\" after the timeout — and a restart's until the\nmachine runs again, so the task tells you when the operation really finished:\n\n```bash\nsudo cenvero-str-ctl task log tsk-3f2a0c1e9b7d-0mumq7fmz-a05dee --follow\n```\n\nSee [Tasks](/docs/api#tasks) for the whole record, and what happens to a task\nthe agent was carrying out when it restarted.\n\n## States\n\n| `state` | Meaning |\n|---|---|\n| `creating` | Being created |\n| `starting` / `running` | Starting, running |\n| `stopping` / `stopped` | Shutting down, off |\n| `paused` | Paused. With `state_reason` \"storage error\", the disk pool ran out of space — free space, then restart the machine |\n| `crashed` | The guest crashed and is not being restarted (below) |\n| `deleting` | Being deleted; running `vm delete` again carries on where it stopped |\n| `unknown` | The node has lost touch with the machines for a moment (for example while the virtualization service restarts); the reason says what was last known |\n\n`state_reason` says why in plain words. `flags` marks conditions that need your\nattention:\n\n| Flag | Meaning | What to do |\n|---|---|---|\n| `pending_restart` | A change waits for the next restart: one you made with `vm update` that could not be applied live, an interface that needs a free slot, or a definition changed outside Stratum and put back while the running machine still has the changed one | Restart it with `vm restart` |\n| `drifted` | The running machine's network or disk wiring was changed outside Stratum. It is never killed for it; a security event is raised | Restart it to restore its protection |\n| `network_degraded` | The machine's network interface was removed outside Stratum. It has been recreated and protected again, but the running machine could not be reconnected to it (usually it is reconnected without a restart) | Restart it |\n| `crash_loop` | It crashed too often and is left off | Find the cause, then `vm start` |\n\n## What happens when…\n\n**…the guest shuts itself down** (`poweroff` inside it). The machine stays off:\nStratum does not restart a machine its owner switched off. The same goes for a\nmachine stopped by some other tool on the node — and a machine started that way\nis adopted as running.\n\n**…the guest crashes.** It is started again at once, then after 30 seconds, then\nafter two minutes. A fourth crash within ten minutes leaves it `crashed`, flagged\n`crash_loop`, until you start it — also across agent restarts and host reboots.\n\n**…the agent restarts or updates.** Machines keep running: they do not depend on\nthe agent process. While it is down, nothing can be changed and consoles close;\nwhen it is back, it picks the running machines up again without restarting them.\n\n**…the server reboots.** When the server comes back, the node first rebuilds\neach machine's network port, its lock and its separation from other tenants,\nthen starts the machines that were meant to be running. Machines you had\nstopped stay stopped. The installer sets the server up so that its own start-up\ndoes not start them early and a server shutdown shuts them down cleanly (on a\nserver shared with another panel, those settings stay as that panel has them).\n\n**…the virtualization service restarts or is upgraded.** Running machines keep\nrunning. The node reconnects, checks every machine against its records and\naccepts changes again; until then changes are refused with **503** and the\nreason (for example \"Compute is connecting to the virtualization service; try\nagain in a moment\").\n\n**…the disk pool fills up.** Guests that try to write pause, with the reason\n\"storage error\". `compute status` warns at 85 % and 95 % full. Free space and\nrestart the paused machines.\n\n**…someone changes a machine outside Stratum.** A changed definition is put back\n(`pending_restart` while it runs); a deleted definition is recreated; a removed\nnetwork interface is recreated, locked again and reconnected to the running\nmachine (`network_degraded` only when that cannot be done). Changing\nthe running machine's wiring raises `drifted` and a security event — the machine\nis never killed for it. Machines that Stratum did not create are never touched.\n\n**…the licence expires or is frozen.** Machines keep running and come back after\na reboot; starting, stopping, creating and deleting are refused until it is\nrenewed. Consoles still open (see [Consoles](/docs/compute/consoles)).\n\n**…the tenant is suspended.** Its traffic is cut, and its machines are stopped:\neach running one is asked to shut down and is powered off if it has not within\nthe stop timeout (2 minutes). While the suspension lasts they cannot be started\n(`vm start` says why), and one started outside Stratum is stopped again. The node\nremembers which machines were running — across agent restarts and reboots — and\nwhen the tenant is resumed exactly those start again; the ones that were\nstopped stay stopped. Stopping a machine yourself during the suspension means it\nstays off after it. `vm show` marks a held machine with `\"tenant_suspended\":\ntrue` and `\"resume_state\"` (what the resume restores). See\n[Tenants & Bandwidth](/docs/tenants).\n\n## Events\n\nMachines report to the node's [event stream](/docs/api#event-log-server-sent-events)\nand webhooks — creation, corrections (`compute.drift_corrected`), console\nsessions and more — next to everything else the node reports. Every change of a\nmachine's state, desired state or flags is a `compute.vm_state` event, so a\nscreen that shows machines can follow them without asking again; every task's\nstart, progress and end are `task.*` events.\n\n## See also\n\n- [Creating virtual machines](/docs/compute/virtual-machines)\n- [Consoles](/docs/compute/consoles)\n- [Current limits](/docs/compute/limits)\n"
        }
    ]
}