VMware ESXi and vSphere Cluster Management

How to Take Virtual Machine Snapshots in VMware vSphere and ESXi

Learn how to create, inspect, and plan VMware vSphere and ESXi virtual machine snapshots, including memory capture, guest file system quiescing, and datastore management.

A VMware virtual machine snapshot is a temporary point-in-time recovery marker for a VM. It records the VM's disk state and configuration state, and it can optionally record the running memory state. You can later return the VM to the captured state by reverting to the snapshot.

This makes snapshots useful before maintenance, configuration changes, software testing, and troubleshooting. A snapshot is not a long-term protection method: it should have a clear purpose, owner, and removal date.

Prerequisites

Basic knowledge of virtual machines, ESXi hosts, VM power states, datastores, and virtual disks.
Access to the vSphere Client, usually through vCenter Server or directly to an ESXi host.
Sufficient inventory and virtual machine snapshot management permissions.
Knowledge of the change or maintenance activity that the snapshot will protect.
Enough free datastore capacity for snapshot metadata and possible delta-disk growth.

What a VM Snapshot Captures

A snapshot can preserve three related parts of a VM's state:

Disk state: VMware preserves the point-in-time relationship between the VM and its virtual disks. Later writes are recorded in delta disk files rather than being written directly to the original disk state.
Configuration state: The snapshot records VM settings and virtual hardware configuration as they existed at capture time.
Memory state: When selected, VMware captures the contents of the VM's RAM. This can allow a powered-on VM to resume closer to its previous execution state, including some in-memory troubleshooting context.

Capturing memory generally takes longer and consumes more storage than capturing disk and configuration state alone. It can also affect the running VM while the capture is performed.

Snapshot Compared with Other Methods

Capability	Primary Purpose	Retention Suitability	Rollback Capability	Backup Replacement
VM snapshot	Short-term rollback before a change	Temporary	Returns the VM to a captured point in time	No
Backup	Recoverable copies for data protection	Planned short- or long-term retention	Restores protected VM or application data	Yes, when designed and tested appropriately
Clone	Creates a separate VM copy	Depends on its purpose	Does not directly roll back the source VM	No
Template	Provides a standard source for deploying VMs	Usually retained as a reference image	Does not roll back an existing VM	No
Replication	Maintains a copy at another location or storage target	Designed for continuity and disaster recovery	Can support recovery at the replica	No; it complements backups

Snapshot Files and Datastore Impact

VMware stores snapshot-related metadata and delta disk files on the datastore. After a snapshot is created, new disk writes are redirected to delta files while the earlier disk state remains available as the snapshot reference.

Delta disks can grow substantially on write-intensive VMs. Databases, file servers, logging systems, and other high-I/O workloads may consume datastore capacity quickly. Long-lived snapshots can also increase storage overhead and affect VM performance, particularly when several snapshots form a chain.

When snapshots are removed, VMware may need to consolidate the snapshot changes by merging them into the appropriate base virtual disks. Consolidation can require time and temporary capacity, so monitor the datastore before and during removal.

Choosing a Snapshot Option

Option	What It Captures or Does	Prerequisites	Best Use Case	Tradeoffs and Limitations
Disk and configuration state only	Captures the VM's virtual disk point and configuration, without RAM contents	Normal snapshot permissions and datastore capacity	Most short-term maintenance and rollback operations	Does not preserve the running execution state
Include VM memory	Captures the contents of the VM's RAM as well as disk and configuration state	Additional datastore capacity and time	Preserving a running, nonproduction troubleshooting or test session	Longer capture, more storage use, possible performance impact; guest quiescing is unavailable in the described workflow
Quiesce guest file system	Coordinates with the guest operating system to place file systems into a more consistent state before capture	Powered-on VM, healthy VMware Tools, and memory capture cleared	Capturing a running server with important file changes	Does not automatically provide application consistency for every database or transaction-sensitive application

Supported VM Power States

Snapshots can be created while a VM is powered on, powered off, or suspended. The selected power state affects what can be captured and how much coordination is required.

VM Power State	Can Create Snapshot	Memory Capture Considerations	Quiescing Considerations	Typical Use
Powered on	Yes	Memory can be captured to preserve more of the running state; capture takes longer and uses more storage	Useful when VMware Tools is running and memory capture is cleared	Live maintenance preparation, troubleshooting, and running-server capture
Powered off	Yes	There is no active running memory state to preserve	Generally unnecessary because the guest is not running	Simple rollback before a change when application or memory state is not needed
Suspended	Yes	The VM already has a suspended execution state; evaluate whether additional memory capture is needed	Normally not the primary choice for quiescing	Preserving a suspended lab or test environment

A powered-off snapshot is generally simpler when application consistency and active memory are not required. For a powered-on VM, memory capture can increase completion time because VMware must write the VM's RAM state to storage.

Plan the Snapshot Before Creating It

Identify the exact VM. Select the intended VM in the vSphere inventory and confirm its name, environment, power state, and datastore.
Define the rollback purpose. Record the change being protected, such as an operating system update, configuration edit, or test.
Check permissions. Confirm that your vCenter Server or ESXi account can create and manage snapshots for the VM.
Check datastore capacity. Allow room for metadata, memory capture if selected, and delta-disk growth during the expected snapshot lifetime.
Assess the workload. Identify databases, transaction-sensitive applications, active file changes, and high-I/O processes.
Check VMware Tools. Verify that VMware Tools is installed and running if guest file system quiescing may be needed.
Choose a name and description. Include the change, owner, change window, and expected removal date. For example, use a name such as pre-web-config-2026-08-19 and describe the exact change and cleanup deadline.

Create a Snapshot in the vSphere Client

Open the vSphere Client and locate the target VM in the inventory.
Open the VM's context menu or Actions menu.
Choose the Take Snapshot action.
Enter a clear snapshot name and a description containing the reason, owner, change window, and planned removal date.
Choose whether to select Include virtual machine memory. Select it only when preserving the running RAM state has a clear benefit.
Choose whether to select Quiesce guest file system when the option is available and appropriate.
Submit the snapshot request.
Monitor Recent Tasks or the task monitor until the operation reports successful completion.
Open the VM's snapshot management interface and confirm that the new snapshot appears under the correct VM.

The exact labels can vary slightly by vSphere version and client view, but the workflow remains: select the VM, open the snapshot creation action, define the options, submit the task, and verify the result.

Memory Capture

Selecting the VM memory option captures the contents of the VM's RAM at the snapshot point. This can be useful for a nonproduction troubleshooting session, a test environment with important in-memory state, or a running system that you need to resume close to its previous execution point.

Memory capture is not a default requirement for ordinary rollback. It increases the amount of data written, extends snapshot creation time, and may cause additional datastore consumption and temporary performance impact. Clear the option when disk and configuration rollback are sufficient.

In the described vSphere workflow, the guest file system quiescing option depends on memory capture being cleared. If quiescing is required, clear Include virtual machine memory first.

Guest File System Quiescing

Guest file system quiescing is a coordination step between vSphere and the guest operating system. The guest is asked to place its file systems into a more consistent state before the live snapshot is captured, which can reduce the chance of capturing partially written file-system data.

The VM should be powered on.
VMware Tools must be installed and running.
Memory capture must be cleared before this option is available in the described workflow.
The guest operating system and configuration must support the requested behavior.

Quiescing is primarily relevant to powered-on VMs, such as a running file server before maintenance. However, file-system consistency is not the same as application consistency. Quiescing does not automatically coordinate every database transaction, application cache, or internal data structure. Use application-aware backup or native application protection for transactional workloads, and test recovery procedures before relying on them in production.

View and Manage Snapshots

Open the selected VM's snapshot management interface, commonly called Snapshot Manager, from the VM context menu or Actions menu. Inspect the following items:

The snapshot tree, which shows parent-child relationships when multiple snapshots exist.
The currently active VM state and its relationship to the selected snapshot.
The snapshot name, description, and creation time.
The hierarchy and any snapshot branches.
Available management actions, including revert, delete or consolidate, and delete all.

Revert returns the VM to the state represented by a selected snapshot. Delete removes a snapshot and commits its disk changes as needed; it does not mean that the VM is simply erased. Delete all removes all snapshots for the VM and may require significant consolidation work. Review the target and change plan carefully before using either removal action.

Remove a snapshot after its short-term rollback purpose has ended. Do not leave old snapshots as an informal backup system.

Post-Creation Validation

Confirm successful completion in Recent Tasks or task monitoring.
Open Snapshot Manager for the exact VM and confirm the snapshot name, description, creation time, and tree position.
Confirm that memory capture was selected or cleared as planned.
Confirm that guest file system quiescing was selected only when VMware Tools and the workload supported it.
Check datastore free capacity after creation and continue monitoring it during the snapshot lifetime.
Record the snapshot's purpose, owner, creation time, and planned expiration.

Practical Examples

Pre-Change Rollback Point for a Test VM

Confirm the test VM identity and verify adequate datastore capacity.
Create a snapshot with a name identifying the planned configuration change.
Record the change window and removal date in the description.
Use a powered-off snapshot when preserving active memory is unnecessary.
Perform the test or update.
Verify the snapshot in Snapshot Manager and remove it after successful validation.

Running File Server Before Maintenance

Verify that VMware Tools is installed, running, and healthy.
Keep the file server powered on.
Clear memory capture.
Enable guest file system quiescing when the option is available and supported.
Perform the maintenance while monitoring datastore capacity.
Remember that quiescing improves file-system consistency but is not a substitute for application-aware backup procedures.

Preserving an Active Troubleshooting Session

Use a powered-on, nonproduction VM.
Select memory capture when the running in-memory state has clear diagnostic value.
Expect additional capture time and datastore use.
Use the snapshot briefly and remove it after analysis.

Reviewing a VM After Snapshot Creation

Open Snapshot Manager for the selected VM.
Locate the new snapshot in the snapshot tree.
Verify its label, description, hierarchy, and creation time.
Review recent tasks for completion status.
Check available datastore capacity and record the planned expiration.

Troubleshooting

Guest File System Quiescing Is Unavailable

Check whether VMware Tools is installed, running, and healthy.
Clear the memory capture option; quiescing is unavailable with that option selected in this workflow.
Review guest operating system and configuration support.
If application consistency is required, use an application-aware backup method instead of relying only on quiescing.

Snapshot Creation Takes Longer Than Expected

Check whether a large VM memory allocation is being captured.
Review datastore latency and available capacity.
Consider whether high disk write activity is extending the operation.
Account for guest quiescing processing.
When feasible, schedule the operation during a lower-workload period and avoid memory capture unless necessary.

Datastore Free Space Declines Rapidly

Look for heavy VM disk writes that are expanding delta disks.
Check whether the snapshot has been retained beyond its planned lifetime.
Look for multiple snapshots forming a chain.
Remove unneeded snapshots promptly, while planning for consolidation time and temporary capacity requirements.

The Snapshot Is Not Visible

Confirm that the correct VM was selected.
Review Recent Tasks for a failed or incomplete creation request.
Open Snapshot Manager for the exact VM and inventory scope.
Investigate task errors before submitting another request.

An Application Does Not Recover Cleanly After Revert

The snapshot may not have been application-consistent.
Active transactions may not have been coordinated by guest file-system quiescing.
The snapshot may have been used in place of a tested backup and recovery process.
Test rollback behavior in nonproduction and use application-aware protection for transactional workloads.

Operational Limits and Best Practices

Use snapshots as temporary rollback tools, not long-term data protection.
Remove snapshots as soon as the protected change is validated or the rollback window ends.
Monitor datastore capacity throughout the snapshot lifetime.
Avoid old snapshot chains on production and high-I/O systems.
Do not make major or prolonged workloads dependent on an old snapshot chain.
Use a maintenance window and verify application recovery requirements before relying on a snapshot for production changes.
Document the reason, owner, creation time, expected removal date, and result of the change.
Use backups, replication, or application-native protection when the requirement is disaster recovery, historical retention, or reliable application recovery.

Summary

To take a VMware snapshot, select the correct VM in the vSphere Client, open Take Snapshot, provide meaningful identifying information, choose memory capture and guest file-system quiescing according to the recovery goal, submit the task, and verify the result in Snapshot Manager. Check datastore capacity before and after creation, monitor delta-disk growth, and remove the snapshot when its temporary purpose is complete.

For related study, review VM snapshot creation and management.