One of the implications of Virtual Machine (VM) mobility (as implemented by VMware’s vMotion or Microsoft’s Live Migration) is the need to have the same VLAN configured on the access ports connected to the source and the target hypervisor hosts. EVB (802.1Qbg) provides a perfect solution, but it’s questionable when it will leave the dreamland domain. In the meantime, most environments have to deploy stretched VLANs ... or you might be able to use hypervisor-aware features of your edge switches, for example VM Tracer implemented in Arista EOS.

The concepts behind the VM Tracer feature are incredibly simple, so one has to wonder why the same functionality hasn’t been implemented by more vendors. This is what you need to do to enable VM Tracer on an Arista’s switch:

• Configure a vCenter monitoring session on each edge switch. EOS uses the standard VMware vSphere Web Services (SOAP) SDK. Each switch can establish monitoring sessions with up to four vCenters.
• Configure a range of VLANs you want to auto-configure on ESX-facing ports (you wouldn’t want the server administrators to accidentally provision VM in a highly protected VLAN, would you?)
• Enable VM Tracer on ESX-facing edge ports.

The vCenter username and password are stored in cleartext (or weakly encrypted) format in EOS configuration. It might be a good idea to create a dedicated username with read-only access limited to the relevant subset of vCenter objects, and use that username on the EOS switches.

And this is how VM Tracer works:

It sends CDP packets on VM Tracer-enabled ports. ESX servers listen to CDP packets (default setting) and cache the received information. You can inspect the CDP information received by an ESX host through vCenter client, ESX command line, PowerCLI or SOAP SDK. EOS uses the SOAP SDK to query the CDP information received by ESX hosts known to the monitored vCenters. The CDP information is then used to build a host-to-port mapping table.

It monitors VM-related events (VM start, VM stop or vMotion) to discover when a VM is moved away from or to an ESX host connected to a switch. Whenever the first VM is connected to a portgroup on an ESX host (or the last VM is disconnected from the port group), the VLAN list on the edge port to which the ESX host is connected might have to be adjusted.

It adjusts the VLAN list on the edge ports to which known ESX hosts are connected.

In an ideal world, Arista EOS would support GVRP or MVRP and the VLANs needed by the ESX hosts would be auto-provisioned across the entire network. In the imperfect world we live in, you still have to configure the VLANs on inter-switch trunk links. If you’re forced to implement “unrestricted VM mobility” environment, you still have to deploy stretched VLANs and all the floods (broadcasts, multicasts and unknown unicasts) consume the bandwidth on all inter-switch links ... but at least they don’t burn the CPU cycles of every ESX host connected to your network.