4TB Virtual to Virtual Migration Using Veeam 6.5

Requirements

    Over the past month I have been working with a client to migrate 4TB of Virtual Machines from their existing fiberchannel EMC array to their new 10GB compellant array. The requirements were to complete this move within a 4 hour outage window moving no more than 10 virtual machines at a time. I also didn't have the ability to install 10GB network cards in their existing environment and direct connect to the new storage due to physical location constraints of the server to storage equipment.

 Design

    To complete this setup I knew that the customer's existing virtual environment was running esx3.5 and had 6 poweredge 2950 servers attached to their existing fiber channel array. I opted to use veeam due to it's proven ability to replicate and move virtual systems within our cloud solutions environment. I wanted to maximize the throughput of their existing environment while trying to apply the lowest load on their existing environment.
     In order to meet these guidelines I installed a veeam backup proxy on each new ESX host and registered them all on the first veeam server to manage all through one central console. Below is a high level view of this architecture.

 After completing the installation of veeam on each vm and registering them to Veeam1, I configured replication jobs to run one job for each vm per backup proxy. While I created these jobs I made sure to stagger the jobs on each backup proxy in a round robin selection while selecting the destination esx host for each job as the one local to that backup proxy which was executing the job. This made the transfer from the veeam backup proxy to the destination host as fast as the esx host was able to process.

Why not Quick Migrate Instead?

Two main reasons I opted to use replication jobs instead of quick migration. One reason was that with the replication job I was able to configure the new network label for each virtual machine on the destination side and allow veeam to configure each virtual machine. Another reason is that I wanted to leave the original vm intact on the source system. Also the ability to complete an initial seed of the system on the destination side confirmed storage space was available prior to the final migration. After inital copies I found the absense of Change Block Tracking on VMFS in esx3.5 really hurt the inital seed process. I found  that performing a full replication of the system after powering off the source virtual machine winded up making the process faster than doing an initial seed. The overhead of parsing the blocks for changes was a greater time issue than performing a full replication of the system.

Configuring the replication Jobs

In order to quickly create the replication jobs I wrote a powershell script leveraging the veeam api. This script takes a templated replication job that you have created in the GUI and applies the same settings to each replication job that it creates. This script uses the a serverlist input file to parse and creates a replication job for each virtual machine defined in the input file. Here is the code I wrote. I did write this in about 1 hour and never seen veeam api prior to this so it is a little bit sloppy but it works. Since I was only running at most 10 of these jobs at one I was able to edit each job and assign the correct backup proxy and destination datastore for each system. There were some manual steps involved but I was in a bit of a hurry when writing this.

$vms = gc c:\scripts\vmlist.txt
$counter = 0
foreach ($vm in $vms){
$counter++
#Create a ReplicaJob
$NameOfJobToCreate = "$vm Replication Job"
$DestinationEsxServerName = "$counter-ServerNameSuffix"
$DestinationDatastoreName = "DS-0$counter"
$TargetVirtualMachineName = "hdcsnap_OLD_OFF"
$server = get-vbrserver -name $DestinationEsxServerName
$datastore = Find-vbrDatastore -Server (get-vbrserver -name $DestinationEsxServerName) -Name $DestinationDatastoreName
Add-VBRReplicaJob -Name $NameOfJobToCreate -Type VDDK -Server $server -datastore $datastore -objects $TargetVirtualMachineName


#Copy MasterReplicatJobOptions to New ReplicaJob
#This code will take all the options configured in the gui and use it on the new jobs
$MasterReplicJobName = "bes1 Replication Job"
$masteroptions = Get-VBRJob -name $MasterReplicJobName | get-vbrJobOptions
$jobObject = Get-VBRJob -name $NameOfJobToCreate
set-vbrjoboptions -job $jobObject -Options $masteroptions
#Check if counter has reached 6 there are 6 esx host in this enviroment if so reset to 0
if ($counter -eq 6)
{
$counter = 0
}
}


Post Job Creation

After completing the replication move with veeam, each virtual machine was powered on the destination side. Once all the destination systems were online, I utilized VMware Update Manager to patch vmware tools and perform virtual hardware upgrades on each system.

Conclusion

If you have the ability to use change block tracking with a esx4.x environment for you source system then performing initial seeds of your systems would drastically improve your migration time. While I always like dual homing a host for migrations that was not an option on this environment and veeam was proven as a great tool to show progress of job migrating and make transition from old to new environment easier.