Snapshots¶

HPE Morpheus Software supports point-in-time snapshots of HVM virtual machines for backup, recovery, and testing purposes. The snapshot mechanism varies depending on the underlying storage backend.

Snapshot Consistency Model¶

HVM snapshots provide different levels of consistency depending on the storage backend and whether the QEMU Guest Agent is available:

Application-consistent snapshots (QEMU Guest Agent connected):

When the QEMU Guest Agent is installed and connected, HPE Morpheus Software quiesces the guest filesystem before taking the snapshot:

• Linux guests: A sync command flushes pending I/O, then fsfreeze is applied to freeze all filesystems before the snapshot

• Windows guests: The fsfreeze call triggers Volume Shadow Copy Service (VSS) inside the guest via the QEMU Guest Agent, which notifies VSS-aware applications (SQL Server, Exchange, Active Directory, etc.) to flush their buffers and enter a consistent state before the snapshot

This provides application-consistent snapshots for both Linux and Windows when the guest agent is available.

Crash-consistent snapshots (no QEMU Guest Agent):

When the guest agent is not installed or not responding, snapshots are crash-consistent — they capture the disk state at a point in time, equivalent to an unexpected power loss:

• No filesystem freeze or application quiescing is performed

• Modern journaling filesystems (ext4, XFS, NTFS) recover cleanly from crash-consistent state

• Applications with their own write-ahead logs (databases) can also recover, but uncommitted transactions may be lost

No memory state is captured in any snapshot mode — reverting a snapshot requires the VM to be restarted.

Snapshot Types by Storage Backend¶

Taking a Snapshot¶

1. Navigate to the VM detail page

2. Click Actions > Create Snapshot

3. Enter a name for the snapshot

4. Click Create

The Instance action is labeled Create Snapshot in current navigation. It appears only for snapshot-capable layouts and users with Snapshots: Full permission. See Managing Instances for action availability.

For VMs with multiple disks, all disks are snapshotted atomically (when supported by the storage backend). CD-ROM volumes are excluded from snapshots.

How File-Based Snapshots Work (GFS2/NFS)¶

When a snapshot is created on a file-based datastore:

1. If the QEMU Guest Agent is connected:

   • Linux: A sync command flushes pending I/O

   • Windows: Sync is skipped (not a Windows command); VSS quiescing is handled by the --quiesce flag in the next step

   • The snapshot is created with the --quiesce flag, which triggers filesystem freeze (and VSS on Windows) via the guest agent

2. If the QEMU Guest Agent is not connected:

   • No pre-snapshot flush or freeze is performed

   • A warning is logged indicating the snapshot will be crash-consistent only

   • The snapshot proceeds without quiescing

3. An external qcow2 overlay is created for each disk using an atomic operation

4. The VM continues running — writes go to the new overlay file

5. The original disk image is preserved as read-only at the point-in-time state

The snapshot file is stored alongside the original disk image on the same datastore.

How Array-Based Snapshots Work (HPE Alletra)¶

When a VM uses storage backed by an HPE Alletra array:

1. HPE Morpheus Software calls the Alletra REST API to create a snapshot of the volume set

2. The snapshot is created as a read-only point-in-time copy at the array level

3. No hypervisor-level operation is needed — the VM continues running uninterrupted

4. The array handles space efficiency internally using copy-on-write

Array-based snapshots are recommended for production workloads due to their minimal performance impact and hardware-accelerated operation.

Reverting a Snapshot¶

1. Navigate to the VM detail page

2. Select the Snapshots tab

3. Click Revert on the desired snapshot

What happens during revert:

1. The guest filesystem is frozen (if the QEMU Guest Agent is available)

2. The VM is powered off

3. The disk is rolled back to the snapshot state:

   • File-based: The overlay is discarded and the base image becomes active

   • RBD: The volume is rolled back to the snapshot point

   • Alletra: The array reverts the volume set to the snapshot state

4. The guest filesystem is thawed

5. The VM is restarted

Deleting a Snapshot¶

1. Navigate to the VM detail page

2. Select the Snapshots tab

3. Click Delete on the snapshot to remove

What happens during deletion:

• File-based: The overlay is committed (merged) back into the base image, then removed. This preserves all changes made since the snapshot while freeing the snapshot overhead.

• RBD: The RBD snapshot is deleted.

• Alletra: The snapshot set is deleted from the array.

Image Import Behavior¶

Existing snapshots are supported when importing an HVM VM as a Virtual Image. For file-based storage, HPE Morpheus Software copies and merges the active qcow2 backing chain into a temporary export disk. This operation does not delete or merge the VM’s existing snapshots. Other supported storage backends create a temporary export snapshot using their datastore implementation.

The resulting Virtual Image must contain both metadata.json and every referenced disk artifact. A metadata-only result is an incomplete import, not evidence that existing snapshots must be deleted. Preserve the source VM and snapshots and see Virtual Images for verification and escalation guidance.

Linked Clone Images¶

HVM snapshots can be registered as linked clone Virtual Images for rapid, space-efficient VM provisioning. The provisioned VM writes to an overlay while the selected snapshot remains its shared backing disk. This is different from importing the VM as an independent Virtual Image.

Create and manage linked clone images from the Instance Backups tab. See the Creating Linked Clone Images section in Storage for the complete workflow, Windows and Linux guest preparation, permissions, and dependency guidance.

On HVM, observe these additional constraints:

• Linked clones require a file-based datastore and QCOW2 disks. LUN-per-vDisk storage, including HPE Alletra datastore types, does not support linked clones.

• A linked clone on local storage is pinned to the source hypervisor and cannot be migrated to another host.

• Storage migration is not supported because the overlay depends on the snapshot backing file in its original datastore.

• The source VM and backing snapshot cannot be deleted while active linked-clone VMs depend on them. Morpheus blocks deletion and displays an error identifying the dependent VMs.

• When shared storage is used, eligible host placement can use the shared backing file, but the source snapshot must remain available.

• A VM cannot be snapshotted while a clone operation is in progress.

During provisioning from a linked clone Virtual Image, Morpheus creates a thin QCOW2 overlay referencing the snapshot as its backing file rather than copying the full disk. This is near-instant regardless of disk size. On local storage, the VM is placed on the same host as the source. On shared storage, any host with access to the datastore is eligible. The linked clone Virtual Image appears only in provisioning dropdowns scoped to the cluster where its backing snapshot exists.

Limitations¶