An interesting questions was brought to my attention on Twitter by Anthony Elizondo:

@complex That sounds complex, I'm not sure you could do it with zero data interruption.

— Chris Wahl (@ChrisWahl) June 9, 2014

For those with Twitter blocked, Anthony wants to migrate from a standard vSwitch with no LAG to a distributed vSwitch with LACP, and there are only two uplinks (vmnics).

After spending some time pondering at my whiteboard, I drafted a solution that will overcome reasonable constraints without much risk. In this case, I make an assumption that it is acceptable to disrupt traffic for < 5 seconds by using an old trick to fool the hypervisor with an empty standard vSwitch. It’s something I’ve done a few times in the past when doing rather extreme workload migrations across data centers and has worked rather well for me.

Here’s the high level overview:

The four major steps for migration are as follows, with rough details provided:

1. Create a new VDS with all of the required management, vMotion, virtual machine, and other port groups.
   • Add Host B to the VDS but don’t migrate over any uplinks (vmnics) yet.
   • Put Host B in maintenance mode to remove all of the VMs.
   • Do not configure LACP on the VDS or the physical network at this time.
2. Migrate over one vmnic from the VSS, followed by all of the VMkernel ports to the VDS, and ensure they are operational.
   • Once verified, migrate over the remaining vmnic from the VSS, leaving the standard vSwitch devoid of uplinks.
   • At this point you can configure LACP on the host and then the physical network.
   • Although there will be a slight disruption to VMkernel traffic, the LAG will form in short order and traffic will once again flow.
   • If you goof this up, just restore the config using the ESXi shell or use the VDS rollback feature.
3. Set the cluster’s DRS settings to partially automated or automation level 1 to avoid any automatic vMotion activity.
   • Exit maintenance mode and use vMotion to migrate a VM workload onto the host.
   • The VM will no longer have network connectivity once it arrives on Host B.
4. Immediately change the VM’s network from the standard vSwitch port group to the distributed vSwitch port group.
   • Traffic will resume.

Scripting with PowerCLI

I’d prefer to do the vMotion and port group change with a script to maximize speed. Here’s a quick PowerCLI script I wrote as an example. It primarily leverages the Set-NetworkAdapter cmdlet:

[sourcecode language=”powershell”]
Connect-VIServer vcenter

$desthost = Get-VMHost -Name "hostname"
[array]$vmlist = Get-VM -Name "list of VMs to move"
$destpg = "VM-1"

foreach ($vm in $vmlist)
{

Move-VM -VM $vm -Destination $desthost
Get-NetworkAdapter -VM $vm | Set-NetworkAdapter -Portgroup $destpg -Confirm:$false

}[/sourcecode]