9 of 9 – Automating HCX Migrations

We have already discussed why you may want to automate HCX migrations.

There is a nexus point where doing it through the UI no longer offsets the effort to code, test and use new scripts.
Typically this would be defined by the number of VMs to migrate or the complexity of the customers environment.

Some customers want ‘everything as code’ so they can rinse and repeat processes and remove technical skills needed to perform a task.

If your HCX Admin goes on vacation or gets hit by a bus, do you want to continue your migrations? Yes, scripts allow for that.

Up to this point we have:

• Deployed the HCX Connector and HCX Cloud appliances
• Configured the basic Admin settings for each appliance
• Created a site pairing from Connector to Cloud
• Created Network and Compute Profiles
• Deployed a Service Mesh

Now we can look at automating migrations.

With scripting there are many ways to do the same thing, my code is basic and feel free to re-write as you see fit.

With any script that is used over and over, you might want to consider importing or hard coding some values:

After that, you will want to give the user the ability to confirm our change the default values for each server, an example for HCX Manager is shown below:

This what is seen for choices when running the script:

Its a good idea to also confirm or change the CSV file name, then validate it actually exists.

No CSV, no migrations.

You now need to connect to those HCX and vCenter servers, you can prompt the user for login credentials which might wear thin after a few batches or you can opt for something like credential files as discussed in the Little Nuggets Blog.

Consider making a copy of your input CSV file, you can update the copy without running the risk of corrupting the original file. Keep the original clean so you can re-run if needed.

Input CSV

For migrations I have been using an Input CSV to create each batch.

Shown below is an example batch in notepad:

Here is the CSV file in Excel:

Note – There is no need to populate the SRC_PGx and TGT_PGx port group cells for each VM as these will be collected and calculated.
The CSV file allows you to define the following inputs:

• MG_NAME – Mobility Group / Batch Name (this should be the same for every row in the CSV file)
• SCHEDULE – (True / False), if True it uses the values from the script (this should be the same for every row in the CSV file)
• VM_NAME – VM name from vCenter (This should be case sensitive, maybe use a RVTools Export)
• DESTINATION_VM_FOLDER – Where you want to place the VM in the target cluster
• DESTINATION_CLUSTER_OR_HOST – Destination Cluster / Host / Resource Pool
• DESTINATION_DATASTORE – Destination datastore or Datastore Cluster
• MIGRATION_PROFILE – Type of Migration i.e. Bulk,Cold,OsAssistedMigration,RAV,vMotion
• DISK_TYPE – VM disk type at target (SameAsSource,Thick,Thin)
• VMTOOLS – (True / False) Upgrade VMTools as part of migration
• ISOS – (True / False) Disconnect ISOs before migration
• POWER_OFF – (True / False) Force PowerOff Bulk migration VMs if they dont gracefully shutdown
• CUSTOM_ATTRIB – (True / False) Copy Custom Attributes from vCenter to vCenter
• RETAIN_MAC – (True / False) Keep your MAC, this might be required for some legacy licensing solutions
• UPGRADE_HW – (True / False) Upgrade the VMs Virtual Hardware as part of Migration *
• REMOVE_SNAPS – (True / False) Remove any Snapshots before migrating

* WARNING – Be careful enabling upgrade VM Virtual Hardware as it will prevent you migrating / rolling back using RAV, Bulk or vMotion. You would need to power off the VM and Cold Migrate it back to the source. Once back at the source you will need to attempt a vHW rollback, there are a few unsupported processes out there for that.

Import the CSV Data

Unlike my other code, we will not read the CSV into a hashtable, instead we read the CSV and simply loop through row at a time processing the data.

The first thing to do is create a master loop to do this, example below:

Once you have imported the CSV you can simply refer to the cells with the .<Header Name> suffix i.e. $HCXVM.VM_NAME

Perform Data Validation

For each VM, you should perform some pre-validation to make sure you are not trying to create ‘invalid’ migration jobs.

Examples of basic check could be:

Check Power State of VM.

Check if the batch is to be scheduled and Migration Type is Cold or vMotion, if so, skip the VM as Cold and vMotion cannot be scheduled:

if ($EnableSchedule -eq $True -and ($MigrationProfile -eq "Cold" -or $MigrationProfile -eq "vMotion"))

If VM Powered Off, check if the Migration type is not Cold, if so, skip the VM:

if ($VMState.PowerState -eq "PoweredOff" -and ($MigrationProfile -ne "Cold"))

If VM Powered On, check if the Migration type is Cold, if so, skip the VM:

if ($VMState.PowerState -eq "PoweredOn" -and ($MigrationProfile -eq "Cold"))

Consider validating the target environment settings are available i.e. Datastore, Cluster name etc

Note – Any ‘Skipped VMs’ or errors should listed in a separate log file so its easy to track them down. This is useful when might have 100+ VMs in a batch.

Create the Network Mappings

A Network Mapping is simply a map for each vNIC on a VM to a target Port Group.

Rather than manually providing the Port Groups for every vNIC on every VM, consider using a function to get those vNICs, calculate the target Port Group and then create the Network Mapping for each vNIC. In this example I am calling a new Function called New-NetworkMapping:

The New-NetworkMapping Function is listed below:

As you can see from the Function, it uses Get-VM and Get-NetworkAdapter, then loops for every Adapter and creates a mapping.

Some mapping / replace strings are used to calculate the target Port Group, this is tricky if there is no consistency of naming standards.
In a worst case scenario you would need to provide a manual network mapping file to read and pull the target Port Group from.

The script then writes the Source and Target Port Groups into the cloned CSV file.

Finally it provides the array of Network Mappings back to the master script.

Create a Migration Job

Using all the variables created from the CSV data input, use the New-HCXMigration cmdlet to create a Migration job for the VM.
Maybe check if Schedule was enabled and add / remove the schedule parameters:

 -ScheduleStartTime $startTime -ScheduleEndTime $endTime

Here is the command with the schedule parameters as the screenshot is truncated:
if ($EnableSchedule -eq $True) {
$NewMigration = New-HCXMigration -VM (Get-HCXVM $HCXVM.VM_NAME) -MigrationType $MigrationProfile -SourceSite $HcxSrcSite -DestinationSite $HcxDstSite -Folder $DstFolder -TargetComputeContainer $DstCompute -TargetDatastore $DstDatastore -NetworkMapping $NetworkMapping -DiskProvisionType $DiskType -UpgradeVMTools $VMToolsUpgrade -RemoveISOs $RemoveISOs -ForcePowerOffVm $PowerOff -MigrateCustomAttributes $True -RetainMac $True -UpgradeHardware $UpgradeHW -RemoveSnapshots $RemoveSnaps -ScheduleStartTime $startTime -ScheduleEndTime $endTime -MobilityGroupMigration

Create a Mobility Group and incrementally add the Migration Jobs

In this Lab, a Mobility Group is the equivalent of a batch of VM Migration Jobs.

Before you can create a Mobility Group, you need to create a ‘Configuration’, this can be done using the New-HCXMobilityGroupConfiguration cmdlet.

This cmdlet allows you to define Mobility Group level settings that will be inherited by VM Migration jobs if not configured at the VM level.

With this code, pretty much all config is at the VM level so we just need a simple Mobility Group Configuration.

The next step is to create a Mobility Group, this will throw an error each time in the loop after the first run, please ignore it…..

The Mobility Group is created with the New-HCXMobilityGroup cmdlet, see the example below:

Finally you need to Set the Mobility Group using the Set-HCXMobilityGroup cmdlet:

Last of all, close the loop.

Create a summary of how many VMs were added, skipped etc

You should now have a draft Mobility Group in your source HCX Manager / HCX Connector.

Validate and Run

Edit the Draft Mobility Group using the Pencil icon.

If you have more then one Service Meshes to use, pick the one required.

Note – At this point in time you cannot select the Service Mesh using PowerCLI so I have left this as a manual task.
If you need to change the Storage Policy, do this here also.
Finally, click the Validate button.

HCX will list any issues detected, some will be Warnings with a Triangle, some will be Red bars / Critical Alerts (these are show stoppers)
Resolve any show stoppers, re-run Validate.

Finally Click Run to start the job.

Sit back, grab a drink and bask at HCX doing your job for you.

Thanks for reading….
I hope this series of blogs may have helped you progress your HCX journey.