Someone on Twitter the other day quoted Paul Maritz, CEO of VMware, as stating that "at any given time, there are more VMs in flight than there are aircraft ".  That alone describes just how heavily vMotion is used in VMware environments.

It's the most used feature in VMware environments by a LARGE margin, and for good reason. And now with the release of vSphere 5, VMware has made our favorite feature even better.

First, vMotion can now use multiple network adapters to increase the speed in which VMs are migrated. The vmkernel transparently balances the load across available vMotion vmkernels (and their physical NICs)-- even if you're only performing a single vMotion. VMware's internal testing showed migration times improved by a factor of 3x.

The best practice around this dictates that you should use a single vSwitch, and create a vmkernel for each physical NIC you want to use-- and then go into each vmkernel and set a single NIC as the Active NIC . I showed this in a previous video (see below) and the process is the same (skip a few minutes in to see the "how to" within vSphere).

http://www.youtube.com/watch?v=bRCMCxX8KIE

Also helping with the speed of migrations, and helping to reduce failed vMotions, is a new "Stun During Page Send" (SDPS) feature. What this feature essentially does is temporarily slow down the speed in which a VM modifies its pages in memory to allow a vMotion task to copy the contents of memory (iteratively until the "final" copy) to the destination host. In vSphere 4.1, if a VM is modifying its memory faster than the contents of that memory can be copied over the network, the vMotion stalls and eventually fails. SDPS is designed for this specific situation.

In addition, the performance in which memory traces are performed (to track the modified pages in memory during a vMotion) has increased. This reduces the impact / overhead on the virtual machine's workload (and application performance) during a vMotion.

Also in vSphere 5, "Metro vMotion" supports vMotions across networks with up to 10ms of round trip latency, as compared to up to 5 ms of round trip latency in vSphere 4.1. This extends the capability to move machines between geographically disparate data centers  (though 10ms of latency usually indicates the sites are still pretty close to each other).

&nbsp;