CHAPTER 11
VM Snapshots
This chapter explains how to protect a virtual machine with a snapshot before a planned change, how to return the VM to a saved point if the change does not go as expected, and how to clear snapshots away once they are no longer needed. A snapshot records a restorable point in time for a VM — its state at the moment you create it — and is most useful before a guest operating system update, an application upgrade, a configuration change, or a test whose outcome you are not certain of. Snapshots are managed from the same VM detail page used for the VM console, disks, and network interfaces, so you create and manage them in the context of the VM they protect. The most important habit in this chapter is to treat a snapshot as a deliberate, short-lived safety point — created before a known change and removed once the change is verified — and never as a substitute for a backup.
Cross-reference: For signing in to the management interface, see Section 6.5, Sign In with Administrative Access. For creating the VM you are protecting, see Chapter 8, Creating and Managing Virtual Machines. For disks and network interfaces on the same VM detail page, see Chapter 9, Managing VM Disks, and Chapter 10, Managing VM Network Interfaces. For long-term protection, see Chapter 20, Backup and Recovery. For moving VMs between hosts, see Chapter 21, VM Migration, and Chapter 22, Configuring Host Clusters for Live VM Migration and High Availability.
This chapter at a glance. The sections below follow the life of a snapshot:
- Create a snapshot — record a restorable point before a planned change, with a clear name that says why it exists (Section 11.1).
- Revert to a snapshot — return the VM to a saved point if a change does not go as expected, after confirming what will be discarded (Section 11.2).
- Delete a snapshot — clear away a snapshot once the change is verified, to reclaim storage and keep the recovery path simple (Section 11.3).
- Know the limits — understand what a snapshot does and does not protect, and the practices that keep snapshots safe (Section 11.4).
11.1 Creating Snapshots
Overview
A snapshot records a restorable point for a virtual machine — the VM’s state at the moment you create it. Creating one before a planned change gives you a quick way back if the change does not go as expected. Snapshots are most valuable before guest operating system updates, application upgrades, configuration changes, or tests whose outcome you are not certain of. Create them deliberately, name them clearly, and plan to remove them once the change is verified.

Before you begin
- You are signed in to the SimpleVM management interface with administrative access. See Section 6.5, Sign In with Administrative Access.
- The VM you want to protect already exists. See Chapter 8, Creating and Managing Virtual Machines.
- The VM is in a state you are willing to return to — note whether it is running or shut off so you know what the snapshot captures.
- The VM’s storage type and disk format support snapshots in the SimpleVM interface; the qcow2 disk format used by the default storage pool generally does.
- Enough free space is available in the storage pool that holds the VM disks. See Chapter 12, Managing Storage Pools.
- For databases and other application-sensitive systems, coordinate with the application owner or use an application-aware backup method so the captured state is consistent.
Procedure
- Open Virtual machines from the left-navigation menu.
- Select the VM you want to protect to open its detail page.
- Scroll to the Snapshots section.
- Select Create snapshot.
- Enter a clear snapshot name that identifies the reason for the snapshot — for example, before-os-update-2026-05-26.
- Enter a description if the dialog provides one.
- Select Create, or the equivalent confirmation button, to create the snapshot.
- Wait for the snapshot operation to complete before you make the planned change.
Verification
- The new snapshot appears in the Snapshots section.
- The snapshot name and timestamp identify when, and why, it was created.
- The VM remains in the expected state after the snapshot completes.
Revert this change
Creating a snapshot does not change the running VM, so there is nothing to undo. If you created the snapshot in error, or no longer need it, delete it. See Section 11.3, Deleting Snapshots.
Troubleshooting
If Create snapshot is unavailable, confirm you are signed in with administrative access, that the VM is in a state that allows a snapshot, and that the storage pool holding the VM disks has free space. If the snapshot operation fails or the snapshot does not appear, confirm that the VM’s disk format supports snapshots ( ) and that the storage pool is active. See Chapter 12, Managing Storage Pools, and Section 25.5, Storage Issues.
11.2 Reverting to Snapshots
Overview
Reverting to a snapshot returns the VM to the saved point you selected. This is the recovery action you take when a change does not go as expected. Because reverting restores the VM exactly as it was when the snapshot was created, it discards everything that happened afterward — operating system changes, application changes, and any data written inside the snapshotted disks since the snapshot was taken.
Before you begin
- You are signed in with administrative access. See Section 6.5, Sign In with Administrative Access.
- You have identified the exact snapshot you want to return to, by name and timestamp.
- You have confirmed that any data created after that snapshot is no longer needed or is backed up elsewhere. See Chapter 20, Backup and Recovery.
- Where the interface requires it, the VM is in the state the revert action expects — for example, shut off.
Procedure
- Open Virtual machines and select the VM.
- Scroll to the Snapshots section.
- Identify the snapshot you want to restore, and review its name, timestamp, and description.
- Recommended: create a new snapshot of the current state first, so you have a way back to it. See Section 11.1, Creating Snapshots.
- Open the snapshot’s action menu and choose the revert option.
- Confirm the revert action.
- Wait for the revert operation to complete before you start or use the VM.
Verification
- The VM returns to the expected state from the selected snapshot.
- The guest operating system starts successfully.
- Applications and services inside the VM behave as expected after the revert.
- Any data that needed to be preserved outside the snapshot is available from backup or external storage.
Revert this change
A snapshot revert cannot always be cleanly undone. If you created a newer snapshot of the current state before reverting, you can return to that newer state by reverting to it. Otherwise, restore the VM or the affected data from backup. See Chapter 20, Backup and Recovery.
Troubleshooting
If the revert option is unavailable, confirm administrative access and whether the VM must be in a particular state — for example, shut off — before reverting. If the VM does not behave as expected after a revert, confirm you selected the intended snapshot by timestamp, and check for data that lived outside the snapshotted disks. See Section 25.4, VM Creation and Boot Issues.
11.3 Deleting Snapshots
Overview
Deleting a snapshot removes that restore point and frees the storage it was holding. Once a planned change has been verified and you are confident you will not need to return to the pre-change state, delete the snapshot. Keeping snapshots only as long as they are needed reclaims storage and keeps the recovery path easy to understand — a VM with many old, unlabeled snapshots is harder to recover safely than one with none.
Before you begin
- You are signed in with administrative access. See Section 6.5, Sign In with Administrative Access.
- The change the snapshot protected has been verified, and you are confident the pre-change state is no longer needed.
- You have confirmed which snapshot to remove, by name and timestamp, so you do not delete one you still rely on.
Procedure
- Open Virtual machines and select the VM.
- Scroll to the Snapshots section.
- Identify the snapshot you want to remove, and confirm its name and timestamp.
- Open the snapshot’s action menu and choose the delete option.
- Confirm the deletion.
- Wait for the operation to complete.
Verification
- The deleted snapshot no longer appears in the Snapshots section.
- The VM continues to run in its current state, unchanged by the deletion.
- Storage used by the snapshot is released back to the pool. Monitor pool capacity to confirm. See Section 12.7, Monitoring Storage Pool Capacity.
Revert this change
Deleting a snapshot is permanent; the restore point cannot be recovered after deletion. If you may still need to return to that state, do not delete the snapshot — keep it, or create a backup of the VM first. See Chapter 20, Backup and Recovery.
Troubleshooting
If the delete option is unavailable, confirm administrative access and that no operation, such as a revert, is in progress on the VM. If storage is not released after deletion, confirm the operation completed and re-check the pool. See Chapter 12, Managing Storage Pools.
11.4 Snapshot Limitations and Best Practices
Overview
Snapshots are useful operational tools, but they work best within clear limits. A snapshot is a short-term safety point before a known change — not a scheduled backup, and not a long-term archive. Understanding what a snapshot does and does not protect keeps your recovery plan honest.
What a snapshot is, and is not:
- A snapshot is a restorable point in time for a single VM, captured on the host that runs it.
- A snapshot is not a backup. It usually depends on the same host storage as the VM, so it does not protect against host or storage failure. For that protection, see Chapter 20, Backup and Recovery.
- A snapshot is not a substitute for application-aware protection. Databases and other active applications may need quiescing or an application-aware method for the captured state to be consistent.
Best practices.
| Best practice | Reason |
|---|---|
| Create a snapshot before a planned change | It gives you a quick recovery point if an update or configuration change fails. |
| Keep snapshots short-lived | Long-lived snapshots consume storage and make the recovery path harder to understand. |
| Do not treat snapshots as backups | Snapshots usually depend on the same host storage as the VM and do not protect against host or storage failure. |
| Use clear names and descriptions | A label such as before-os-update-2026-05-26 tells any administrator why the snapshot exists and whether it can be deleted. |
| Create a return-point snapshot before reverting | A revert cannot always be cleanly undone; a newer snapshot of the current state gives you a way back. |
| Monitor storage pool capacity | Snapshot growth can reduce the free space available in the pool. See Section 12.7, Monitoring Storage Pool Capacity. |
| Be careful with databases and active applications | Their data may require an application-aware backup or quiescing to ensure a consistent captured state. |
| Confirm migration and high-availability expectations | VMs with snapshots or assigned host devices may have migration or HA limitations. |
Before you rely on snapshots in a clustered or migrated environment, confirm how they interact with the moves you plan to make.