White Papers

ME4 Series snapshots with Hyper-V
26 Dell EMC PowerVault ME4 Series and Microsoft Hyper-V | 3921-BP-WS
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. The VM can be recovered by
manually copying the virtual hard disks from the recovery snapshot to the original location.
• This involves deleting, moving, or renaming the original virtual hard disks.
• After copying the recovered virtual hard disks to their original location, they must be renamed and
Hyper-V manager must be used to re-associate them with the guest VM. This is necessary to allow
the guest VM to start without permissions errors.
• This may not be practical if the virtual hard disks are extremely large. In this case, the original VM can
be deleted, and the recovery VM imported or created as a new VM directly from the recovery volume.
After the recovery, the original data volume can be unmapped from the host if no longer needed.
• This method also facilitates recovery of a subset of data from a VM by mounting a recovery virtual
hard disk as a volume on the host server temporarily.
Option 3: Map the recovery snapshot to a different Hyper-V host and recover the VM there by importing the
VM configuration or creating a new VM that points to the virtual hard disks on the recovery volume.
• This is common in situations where the original VM and the recovery VM both need to be online at the
same time, but be isolated from each other to avoid name or IP conflicts, or avoid a split-brain
situation with data reads/writes.
• This is a good recovery method when the original host server is no longer available due to a host
failure.
If possible, before beginning any VM recovery, record essential details about the VM hardware configuration
(such as number of virtual CPUs, RAM, virtual networks, and IP addresses) if importing a VM configuration
fails.
4.2.2 Recover guest VM on a cluster shared volume
The process of using ME4 Series snapshots to recover guest VMs that reside on a CSV is like the process of
recovering a guest VM to a standalone host, as detailed in section 4.2.1. 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 an 8-character hexadecimal number such as 045C3E2F4. No two volumes mapped to a server can
have the same disk ID.
When an ME4 Series 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. Therefore, recovery volumes based on snapshots will also
have the same disk ID.
With standalone Windows or Hyper-V servers, disk ID conflicts are avoided because standalone servers can
automatically detect duplicate disk IDs and change them dynamically on the offending disk with no user
intervention. However, host servers are not able to dynamically change conflicting disk IDs when disks are
configured as CSVs, because the disks are mapped to multiple nodes at the same time.
When attempting to map a copy (snapshot) of a CSV back to any server in that same cluster, the recovery
volume will cause a disk ID conflict, which may 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 and copy the guest VM files over the network to recover the guest VM.