Home > Storage > PowerStore > Virtualization and Cloud > Dell PowerStore: Microsoft Hyper-V Best Practices > Use PowerStore snapshots to recover guest VMs
This section provides guidance and best practices for snapshot recovery options.
Use a consistent or crash-consistent PowerStore snapshot of a host volume that contains the VHD to recover a Hyper-V guest VM to a previous point in time.
You can also use a snapshot to create a copy of a VM in an isolated environment. Perform this action at the same location, or at a different location (if you have enabled PowerStore volume replication between PowerStore clusters).
In this scenario, the VHD and configuration files for a VM reside on a PowerStore data volume. The volume is mapped to a Hyper-V host.
Option 1: Use a PowerStore snapshot to refresh or restore the existing data volume on the host that contains the VM configuration and VHDs. You could also replace the volume with a thin clone.
Option 2: Map a thin clone of the volume that contains the VM configuration and VHDs to the same host as a new volume, with a new drive letter or mount point. Manually recover the VM.
This option might not be practical if the VHDs are large because of the copy time.
To recover a subset of data from a VM, mount a recovery VHD as a temporary volume on the host server. Recover the wanted data over the network. Dismount the recovery VHD when finished.
Option 3: Map the thin clone to a different Hyper-V host and recover the VM there by importing the VM configuration. Alternatively, create a new VM that points to the virtual hard disks on the recovery volume.
Record essential details about the VM configuration, such as the number of virtual CPUs, memory, virtual networks, and IP addresses. If a VM import fails (or is not supported), use this information to create a new VM.
Options 1, 2, and 3 will also work with PowerStore volume groups. Configure a PowerStore volume group as a best practice if a VM has multiple VHDs that reside on multiple host data volumes. A volume group will ensure that snapshots have a consistent timestamp across all the volumes in the group. Consider the following example:
Recovery of a VM on a CSV is similar to a VM recovery on a data volume on a stand-alone host. However, CSV recovery scenarios might require the administrator to change the disk signature to avoid a conflict that can be service-impacting.
Windows Server assigns each disk a unique ID (or signature). A disk ID consists of a string of characters in hexadecimal format. Here are two disk ID examples:
A PowerStore snapshot of a Windows Server host volume or CSV is an exact point-in-time copy (includes the disk ID). A thin clone created from a PowerStore snapshot will have the same disk ID as the source volume.
Stand-alone Windows or Hyper-V servers dynamically avoid disk ID conflicts. A stand-alone server automatically detects duplicate disk IDs and changes them without user intervention.
However, Windows is unable to dynamically change a duplicate disk ID when:
In this situation, an administrator must manually change the disk ID of the thin clone before it is mapped to the cluster. A duplicate disk ID might cause a service interruption.
Given a duplicate disk ID situation with a cluster volume or CSV, it is easy to work around or resolve the issue.