Home > Storage > PowerVault > Guides > Dell PowerVault ME5 Series: Microsoft Hyper-V Best Practices > Guest VM recovery with ME5 snapshots
Recover Hyper-V VMs to a previous point in time by using consistent or crash-consistent ME5 snapshots. Snapshots can be used to create cloned copies of VMs in an isolated environment at the same or a different location.
In this scenario, the virtual hard disk and configuration files for a VM reside on a data volume that is mapped to a Hyper-V host.
Option 1: Recover the existing data volume on the host that contains the VM configuration and virtual hard disks by using an ME5 snapshot.
Option 2: Map a snapshot containing the VM configuration and virtual hard disks to the host as a new volume, in a side-by-side fashion using a new drive letter or mount point. Recover the VM by manually copying the virtual hard disks from the recovery snapshot to the original location.
Option 3: Map the recovery snapshot to a different Hyper-V host and recover the VM there. Import the VM configuration or create a VM that points to the virtual hard disks on the recovery volume.
Before beginning a VM recovery, record VM configuration details such as the number of virtual CPUs, memory, virtual networks, and IP addresses. If importing a VM configuration fails, a new VM will need to be created using this information.
The process of using ME5 snapshots to recover guest VMs that reside on a CSV is like the process of recovering a guest VM to a stand-alone host. However, recovering a VM from a snapshot of a CSV may require changing the disk signature first.
Windows Servers assign each volume a unique disk ID (or signature). For example, the disk ID for an MBR disk is a hexadecimal number such as 045C3E2F4. All volumes mapped to a server must use a unique disk ID.
When an ME5 snapshot is taken of a Windows or Hyper-V volume, the snapshot is an exact point-in-time copy, which includes the Windows disk ID. Recovery volumes based on snapshots will have the same disk ID as the original volume.
With stand-alone Windows or Hyper-V servers, disk ID conflicts are avoided. Stand-alone servers can automatically detect a duplicate disk ID and change it dynamically. However, host servers are not able to dynamically change conflicting disk IDs when disks are configured as CSVs due to the behavior of Widows Server clustering.
When attempting to map a copy (snapshot) of a CSV as an additional volume in that same cluster, the recovery volume will create a disk ID conflict. Disk ID conflicts can be service-affecting.
There are two methods to work around the duplicate disk ID issue:
Option 1: Map the recovery volume (snapshot) containing the CSV to another host that is outside of the cluster. Copy the guest VM files over the network to recover the guest VM.
Option 2: Map the recovery volume to another Windows host outside of the cluster and use Diskpart.exe or PowerShell to change the disk ID. Once the ID is changed, remap the recovery volume to the cluster. The following steps demonstrate how to use diskpart.exe to change a disk ID.
Follow these steps to change a disk ID. PowerShell can also be used.
diskpart
list disk
rescan
list disk
select disk 4
uniqueid disk
uniqueid disk ID=<newid>
i For an MBR disk, the ID is an eight-character string in hexadecimal format.
ii For a GPT disk, the ID is a Globally Unique Identifier (GUID) in hexadecimal format.
uniqueid disk