One of the important features enabled in Windows 2012 is the ability to live migrate VMs anywhere. Whether the VM migrating within a cluster, across clusters, standalone to standalone or standalone to cluster or vice versa, VM will not be paused or interrupted at the time of VM live migration. This efficiency enables fabric administrators manage their fabric and load balance the environment and ensure that their private cloud deployments are running optimally. While this provides freedom and flexibility for fabric administrators, this poses management problem for backup administrators. As the fabric administrator leveraging these capabilities to optimize the fabric performance and taking these decisions independently backup administrators will not be aware of this until backup software fails to find the VM and so failing the backups. This kind of dynamic fabric provides problems for the backup administrators.
DPM 2012 SP1’s motto is to provide flexible and yet powerful backup solutions for your private cloud deployments. As part of this target, DPM introduced intelligence where DPM can detect the VM movement and continue VM protection, all without any active involvement from backup administrator. Also, not only DPM can detect the VM migration but also can continue protection efficiently when VM migration does not involve storage migration. As the VM migrates from one host(s) to another host(s), same DPM server will continue to retain the backup responsibility for this VM.
At the time of backup, DPM detects the VM’s new host by communicating with VMM. At the time of backup, DPM interacts with VMM to find the VM’s new host. Based on the information, DPM communicates with new host(s) for taking backups. In order to achieve this, backup administrators need to connect DPM(s) to VMM server and all host(s) where VM “will” be migrated to, so that DPM can communicate with the new host(s) to backup VM when it migrates.
Enable DPM communication with VMM:
In order for DPM to interact with VMM, make DPM machine account as “ReadOnly” administrator on VMM and as discussed here. This will allow DPM to enquire about any VM which might be residing anywhere in VMM’s fabric/cloud. DPM communicates with VMM using VMM power shell. So, VMM client should be installed on DPM Server. Also, configure DPM with the VMM server name by setting DPM global property called “KnownVMMServers”. Here are the steps that need to be performed for setting up DPM server ready for VM Live Migration: Uninterrupted data protection.
1) Install VMM Console on the DPM server. Ensure that the VMM console and VMM server are of same version.
2) Install DPM protection agent on all “targeted” hosts and attach to this DPM server
3) Using elevated DPM Windows PowerShell, run Set-DPMGlobalProperty as shown below on the DPM server
Set-DPMGlobalProperty –DPMServerName DPM01 –KnownVMMServers VMMTST01
Above command preps DPM server to communicate with VMM server named VMMTST01. Subsequently DPM consults VMM server for any VM backup to find its new host(s). Please note that DPM server can interact with only one VMM server and so the variable should be set with only one VMM server. DPM PowerShell can be used to verify that the global property is set properly by using Get-DPMGlobalProperty as shown below.
4) Start the DPMVMMHelper service
Also, all “potential target” hosts should be configured to connect with this particular DPM server. As mentioned previously, DPM now supports DPM scale out feature. So, same Hyper-V host(s) can be configured to communicate with multiple DPM servers. For an interrupted data protection, DPM should already be attached to all host(s) where the VMs are going to be migrated.
Windows 2012 VM live migrate “anywhere”, makes the VM migration possible in various kinds of Hyper-V deployments. There are three kinds of VM live migration at a high level.
- A VM live migration where the migration involves only compute but not storage
- A VM live migration where the migration involves both compute and storage
- A VM live migration where migration involves only storage but not compute
Whenever there is a storage migration involved in a VM live migration, DPM will do onetime full CC of the VM (ie., read VM on both “new” Hyper-V host(s) and DPM server, compare checksum and then transfer changed content to DPM server). Normal expressfull Delta Replication (DR) backups will resume after CC. When live migration doesn’t involve storage migration, DPM do not need to go through full CC and so expressfull DR backups will continue. Here is the list of combinations that live migration can be done and DPM’s protection behavior.
As DPM is dependent on the VMM to know where the VM has been migrated to, for an effective backup, it is advised to do the VM migration using VMM Live Migration workflow as described here. In some of the scenarios, Windows 2012 VM live migration with storage migration causes VM to be “rearranged” on the destination. This leads to almost whole size of VM being backed up by DPM via CC in the next backup. DPM has a new service named DPM VMM Helper Service which will be interacting with the VMM server. This service will be running on system context.
While connecting all hosts to single DPM enable “uninterrupted VM protection” and SC 2012 SP1 – DPM enhanced its scale, a single DPM server cannot protect all VMs in the private cloud deployment. Considering this, DPM 2012 SP1 introduced a new capability called scaleout feature where multiple DPM servers can protect VMs on a single host or a single cluster. This is further discussed in the blog “SC 2012 SP1 – DPM: Leveraging DPM ScaleOut feature to protect VMs deployed on a big cluster”.
DPM’s communication with VMM can be reverted by resetting the “KnownVMMServers” global property as shown below.
Set-DPMGlobalProperty –DPMServerName DPM01 –KnownVMMServers “”
This command will ensure that DPM will not look for/communicate with the VMM server. Also, if same command is issued with a different VMM server name, DPM will start communicating with the new VMM server.
With the mobility in picture, DPM recovery scenarios are changed a little bit. Any recovery points on or after the latest recovery point can do Original Location Recovery (OLR) meaning the VM can be recovered to location where the VM is currently running. For all these recovery points, DPM can do Alternate Location Recovery (ALR) and Item Level Recovery (ILR) as well. For all recovery points before last VM live migration, only ALR and ILR are possible. OLR scenario is not supported for these recovery points.
Due to various restrictions, VM mobility cannot be combined with Secondary DPM protection (or DPM DR).