VM lifecycle
Overview
A VM's lifecycle is the sequence of states it moves through from creation to deletion. After being created, a VM is repeatedly started and stopped during operation; once deleted, it is gone permanently.
State flow
Start: Idle → Allocating → Booting → Running
Stop: Running → Terminating → Idle
Delete: Idle → Deleted
What each state means, and billing
The VM billing below applies to on-demand and spot. Reserved instances are billed at the reserved rate for the contract duration, regardless of state.
| State | Meaning | VM billing |
|---|---|---|
| Idle | No active allocation; can be started | ✗ |
| Allocating | Just after start; reserving resources in the zone | ✗ |
| Booting | Resources reserved; bringing the VM up | ✗ |
| Running | Operating normally | ✓ |
| Terminating | Shutdown in progress | ✓ |
| Deleted | Permanently deleted | ✗ |
Stopping pauses only the VM's compute charges. Attached block storage and public IPs continue to be billed until you delete them.
VM state vs allocation state
Internally, a VM carries two states at once.
VM status
The state of the VM resource itself — whether it has an active allocation and whether it has been deleted.
| Value | Meaning |
|---|---|
idle | No active allocation |
allocated | Has an active allocation |
deleted | Permanently deleted |
idle / allocated only surface in a few screens (such as the eligibility check when attaching block storage, or the list of VMs that belong to a PFS). On most screens the portal shows the label derived from the allocation state below.
VM allocation status
The phases a single start request (allocation) moves through as it starts, runs, and ends. The state label you see in the portal is based on this value.
| Value | Phase | Portal label |
|---|---|---|
| (none) | No allocation | Idle |
queued | Start request waiting | Allocating |
assigned | Scheduler has allocated resources | Allocating |
taken | Agent has taken over and is booting | Booting |
started | Running | Running |
terminating | Shutdown in progress | Terminating |
terminated | Shutdown complete | (Cleaned up; returns to Idle) |
State transition diagram
User action VM status Allocation status
idle
│
Start ──────────────▶
│
allocated ────── ────▶ queued (Allocating)
│ (scheduler)
▼
assigned (Allocating)
│ (agent)
▼
taken (Booting)
│ (agent)
▼
started (Running)
│
Stop ───────────────────────────────────▶
│
terminating (Terminating)
│ (agent)
▼
idle ◀─────────── terminated (Cleaned up; returns to Idle)
Changing pricing type and instance type
While a VM is stopped, you can change its pricing type and instance type without recreating it.
- What changes: the pricing type (on-demand / reserved / spot) and the spec that the instance type defines (vCPU, memory, GPU)
- What stays: the VM itself — network, public IP, attached block storage, name, and tags
The new price applies once you start the VM again after transitioning.
- The VM must be stopped (no active allocation).
- Always-On must be off.
- You can only switch to an instance type in the same zone.
Diagnostic status
In addition to the lifecycle above, a monitoring diagnostic status (Unhealthy / Unknown) may also be shown. This reflects the result of agent and GPU health checks and is independent of the VM lifecycle. For resolution steps see VM diagnostic status.
Next steps
- Choosing an instance type: GPU vs NPU vs CPU
- Pricing model: on-demand vs reserved vs spot
- Block storage: disks that survive VM deletion