​
Overview

A VM snapshot captures an entire machine at a moment in time — optionally including memory, so a running machine can be resumed exactly where it left off. That’s the difference from a volume snapshot, which captures one disk.
VM Snapshots requires a per-account entitlement and is off by default. Without it the screen isn’t in your sidebar, and navigating to it directly returns you to Virtual Machines. The feature works, but its interface is known to be rough, which is why it’s opt-in rather than general. Ask support if you need it.
Navigation: Compute → VM Snapshots. Titled VM Snapshots, subtitled “Manage virtual machine snapshots”.

​
VM snapshots versus volume snapshots

Holding VM snapshots blocks two common operations: you cannot scale a machine, and you cannot resize its volumes, while VM snapshots exist. Both dialogs explain this rather than failing obscurely. If you plan to resize, delete the VM snapshots first.

​
Creating one

There is no create button on this screen — snapshots are taken from the machine itself, via Take Snapshot on its detail page. See Virtual Machines. Two fields matter: The dialog summarises what you’ll get: Full VM Snapshot (disk and memory) or Disk-only Snapshot (volumes only).
A running machine cannot be captured disk-only — a disk-only capture of a live machine would be crash-consistent at best. The dialog says: “Enable Include Memory, or power off the VM before taking a disk-only snapshot.”

​
Columns

Snapshot Name and Created are sortable. Expanding a row shows Snapshot ID, Name, Type, Current Snapshot (Yes/No), Created, Zone, Account, and Parent Snapshot where one exists.
(Current) marks the snapshot the machine’s disks currently descend from. Snapshots form a chain via Parent Snapshot, so reverting changes which one is current.

​
States

The State filter offers All States, Ready, Creating, Reverting, and Error — but not Expunging, even though snapshots do enter that state. An expunging snapshot appears under All States only.

​
Row actions

​
Reverting

Reverting is destructive to current state. The dialog is explicit:
  • The VM will be stopped during the revert process
  • All current data will be replaced with the snapshot state
  • Any changes made after this snapshot will be lost
  • The VM will need to be restarted after reverting
There is no undo. If the current state might matter, take a fresh snapshot before reverting to an old one.
Confirmation shows Are you sure you want to revert to snapshot {name} taken on {date}?, and success reports VM reverted to snapshot "{name}".

​
Worked example: a safe in-place upgrade

1

Snapshot with memory while running

On the machine’s detail page, Take Snapshot → name pre-upgrade-{date}, description “Before the 2.x upgrade”, memory included.
2

Wait for Ready

Don’t start the upgrade while the state is still Creating — the snapshot isn’t a usable restore point yet.
3

Do the upgrade

Apply your changes.
4

If it went wrong, revert

Revert to Snapshot on pre-upgrade-{date}. The machine stops, returns to the captured state, and needs starting again.
5

Clean up when you're satisfied

Delete the snapshot once the upgrade is confirmed good. Snapshots consume storage quota and block future scaling and volume resizes while they exist.
For a single disk you plan to roll back, a volume snapshot is lighter: no entitlement needed, and it doesn’t block scaling. Reach for a VM snapshot when you need memory state or the machine’s disks captured together as one consistent set.

​
Empty and error states

Virtual Machines

Where snapshots are actually created.

Snapshots

Per-volume snapshots, available to everyone.

Backups

Managed per-VM protection held separately.