I was asked a question the other day about “enabling vMotion.” The answer actually has 2-parts. Technically there is a parameter you need to have set in order for vMotion to be enabled on your host. “Migrate.Enabled” is an advanced parameter that you would need to set if you were creating networking objects from the command line. Enabling/disabling is one of the troubleshooting steps if vmotion is acting up, however since the flag is handled automatically in the vSphere client when creating networking objects using the GUI, most admins won’t have cause to use it.
Migrate.Enabled in theGUI:
If you are creating the network objects from the command-line (or PowerCLI which is what I’ll use here) you’ll also notice that “VMKernel ports” are actually just a regular port group that a vmkernel NIC has been added to. If the port group already has VMs attached their NICs will be unceremoniously dumped. You can only add one VMKernel NIC (and no VMs) to a VMKernel-enabled “port group.”
You first create a New-VirtualSwitch then add a New-VirtualPortGroup to the vswitch. Next you convert the portgroup to a “VMKernel port” by adding a New-VMHostNetworkAdapter to it using the -Portgroup option, making sure you set -vMotionEnabled:$true for that new port. The last step (as referenced earlier) is to enable vMotion for the host as follows:
[vSphere PowerCLI] C:> Get-VMHost -Host esx1.demo | set-VMHostAdvancedConfiguration -Name Migrate.Enabled -Value 1
Important Note!! The only part of that line (or any of the commands executed so far) that is case-sensitive is the Migrate.Enabled parameter. It is set directly on a host instead of being interpreted by PowerShell the PowerCLI scripts or vCenter Server.
Note that there is also a vMotion timeout that could help if you have delays on your network: MigrateNetTimeout in the GUI (under Advanced/migrate) or Migrate.MigrateNetTimeout from the command line. Default is 20, measurement is seconds.
