White Papers

SC Series snapshots and Hyper-V
28 Dell EMC SC Series: Microsoft Hyper-V Best Practices | CML1009
3.2.1 Recover a guest VM on a standalone Hyper-V host
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.
If a VM virtual hard disk and configuration files reside on separate host data volumes, then it is a best practice
to configure a consistency group for these volumes on the SC Series array so that crash-consistent
snapshots occur at the same exact time. For example, a boot virtual hard disk for a VM might reside on one
host volume, while one or more virtual hard disks for data might reside on another host volume.
When performing a recovery of a VM with SC Series snapshots, there are several options.
• Option 1: Replace the existing data volume on the host that contains the VM configuration and virtual
hard disks with a View Volume created from the desired SC Series snapshot. In this scenario, the VM
in question is powered down, the original volume is unmapped from the server, and the View Volume
is mapped to the host using the same LUN number, drive letter mapping, or mount point.
- This may only be practical if the data volume contains only one VM. If the data volume contains
multiple VMs, it will still work if all the VMs are being recovered to the same point in time.
Otherwise, option 2 or 3 would be necessary if needing to recover just one VM.
- This will allow the VM being recovered to power up without any additional configuration or
recovery steps required.
- It is essential to document the LUN number, disk letter or mount point information for the volume
to be recovered, before starting the recovery.
• Option 2: Map the View Volume 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 View Volume to the original location.
- Delete, move, or rename the original virtual hard disks.
- After copying the recovered virtual hard disks to their original location, rename them and use
Hyper-V manager to re-associate them with the guest VM. This may 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 (Hyper-V 2012 and newer) or created as a new
VM (Hyper-V 2008 R2) directly from the View 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 View Volume 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 need to be isolated from each other, or when the original host server is no
longer available.
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) in case importing a VM
configuration is not supported (Hyper-V 2008 R2) or fails.