Home > Storage > PowerStore > Virtualization and Cloud > Dell PowerStore: Microsoft Hyper-V Best Practices > Use PowerStore snapshots to recover guest VMs
You can recover a Hyper-V guest VM to a previous point in time using crash-consistent PowerStore snapshots of the underlying host volume containing the VHD. You can also use snapshots to create copies of VMs in an isolated environment. You may perform this action at the same or a different location when volume replication between PowerStore appliances is used. This section provides guidance and best practices for recovery options using snapshots.
In this scenario, the VHD and configuration files for a VM reside on a data volume that is mapped to a Hyper-V host or cluster.
If the VM VHD and configuration files reside on separate host data volumes, configure a PowerStore volume group for these volumes in PowerStore Manager. This action ensures that crash-consistent snapshots occur at the same exact time. For example, a boot VHD for a VM might reside on one host volume, while one or more data VHDs might reside on another host volume.
When performing a recovery of a VM with PowerStore snapshots, there are several options.
Option 1: Use PowerStore to refresh or restore the existing data volume on the host that contains the VM configuration and VHDs using a snapshot. You could also replace the volume with a thin clone.
Option 2: Map a thin clone containing the VM configuration and VHDs to the host as a new volume, side by side, using a new drive letter or mount point. Manually recover the VM by copying the VHDs from the thin clone to the original location.
Option 3: Map the thin clone to a different Hyper-V host, and recover the VM there by importing the VM configuration. Alternately, create a VM that points to the virtual hard disks on the recovery volume.
Before VM recovery begins, record essential details about the VM hardware configuration in case importing a VM configuration is not supported or fails. These details can include the number of virtual CPUs, memory, virtual networks, and IP addresses.
Previous sections describe using PowerStore snapshots to refresh or restore CSVs or using thin clones to recover guest VMs that reside on one or more CSVs. These processes are similar to recovering a guest VM to a stand-alone host. However, recovering a VM from a thin clone in this scenario might require changing the disk signature first.
Windows Server (including Hyper-V hosts and nodes) assigns each disk a unique ID (or signature). Here are two disk ID examples, each consisting of a string of characters in hexadecimal format:
Volumes mapped to a server must each have a unique disk ID to avoid a possible service interruption.
When a PowerStore snapshot is taken of a Windows Server Hyper-V disk, the snapshot is an exact point-in-time copy. This copy includes the disk ID that Windows Server assigns to the disk. Thin clones that are created from a PowerStore snapshot also have the same disk ID as the source volume.
Stand-alone Windows or Hyper-V servers avoid disk ID conflicts because stand-alone servers can automatically detect duplicate disk IDs and change them dynamically without user intervention. However, clustered Windows Hyper-V nodes with CSVs require administrators to manually change the disk ID of a thin clone before it is mapped to cluster nodes. This requirement is due to Hyper-V cluster nodes not being able to dynamically change conflicting disk IDs on clustered disks. This requirement is important because a disk ID conflict results in an inability to bring the disk online and might also result in a service interruption.
There are two options to address a duplicate disk ID with a thin clone with PowerStore: