This page describes the current computer lifecycle. For commands, see Sleep and wake a computer.
States
state describes the computer now. pending names the state a transition is driving
toward; null means no transition is pending.
nevia status shows a pending target with an arrow,
such as ready (→ sleeping).
| State | Meaning | Run a command | Create a checkpoint |
|---|---|---|---|
creating | Provisioning or restoring the computer. | No | No |
ready | The microVM is running. | Yes | Yes |
sleeping | The microVM is paused in memory; RAM remains allocated. | No | Yes |
failed | The computer failed to start or complete a transition. Read its error. | No | No |
deleting | Deletion is in progress. | No | No |
deleted | Deletion is complete; the computer is no longer available. | No | No |
Exec and checkpoint creation require pending: null and an existing microVM.
Checkpoint creation also requires snapshot support and no operation running on the
source computer. Reading status or logs does not wake a sleeping computer. Logs are
available while ready or sleeping.
Transitions
Sleep, wake and branch require pending: null and no operation running on the
computer. Wait for a pending transition or a reported operation to finish before
retrying.
| Action | Required starting state | While in progress | Result |
|---|---|---|---|
| Create | No existing computer. | creating, pending ready | New computer becomes ready. |
| Sleep | ready | ready, pending sleeping | Same computer becomes sleeping. |
| Wake | sleeping | sleeping, pending ready | Same computer becomes ready. |
| Branch | Source is ready or sleeping. | New computer is creating, pending ready. | New computer becomes ready; source keeps its state. |
| Restore a checkpoint | Checkpoint is ready. | New computer is creating, pending ready. | New computer becomes ready; source keeps its state. |
| Delete | A live computer, subject to the blockers below. | deleting, pending deleted | Computer and its data are removed. |
| Restart | Unsupported. | No transition. | The API returns 422 not_supported; there is no CLI restart command. |
These results describe successful transitions. A failed transition can leave the
computer in failed.
Sleep on an idle sleeping computer and wake on an idle ready computer return the
computer unchanged. Sleep and wake can finish within the request. If they need more
time, the response includes an operation and a pending target. The CLI's --wait
follows that operation.
Deletion requires protection to be off and no operation running on the computer. A checkpoint in use by another live computer also blocks deletion of its source; delete the dependent computers first.
Persistence
Provisioning attaches a persistent disk at /data only when the deployment configures
a storage pool. A directory named /data alone does not imply a persistent disk.
Commands run as the nevia user and start in its home directory, which lives on that
disk; write there. The /data mount point itself is not writable.
Sleep calls Ember Machines/Pause; wake calls Machines/Resume. Pausing keeps RAM
allocated and does not require an attached data disk or snapshot support. It does
not create a durable restore point; use a checkpoint when you need one.
The writable root filesystem uses memory. Saving memory preserves those filesystem changes along with the workload's memory.
| Action | Memory and writable root filesystem | Persistent disk, when attached |
|---|---|---|
| Sleep, then wake | Retained in RAM while paused and resumed at wake. | Kept. |
| Create and restore a checkpoint | Captured in the checkpoint and restored into a new computer. | Private copy of the captured data. |
Branch a ready computer | The branch boots from the image with fresh memory and a fresh writable root. | Private copy of the source's data. |
| Branch a computer paused by sleep | The branch boots from the image with fresh memory and a fresh writable root. | Private copy of the paused source's data. |
| Delete | Removed. | Removed. |
Older machines suspended to disk by Machines/Suspend also appear as sleeping.
Wake restores their suspension snapshot; branching one restores its saved memory
and paired disks. The current CLI suspend command pauses in memory instead.
A branch of a running computer can reuse a disk snapshot less than five seconds old. To include writes you just made, finish and flush them, then wait at least five seconds before branching.
Sleep and wake keep the computer's identity, url, image, environment, size and
ports. A branch or checkpoint restore creates a new computer with its own identity
and url; it keeps the source's ports but not its running programs. Writes to its
copied data do not change the source.
A sleeping computer keeps its url and does not answer on it. Ports change only while
the computer is ready. See Computer ports and URLs
for the URL and port rules.
Exec and checkpoints
Sleep, deletion and checkpoint capture end active exec sessions; waking does not reconnect them.
Checkpoint capture briefly pauses a running source, then resumes it; a sleeping
source stays asleep. Only crash consistency is supported.
See Run a command, Create and restore checkpoints, and Branch a computer for the procedures.