vSphere 6.0 blog – vMotion

There are a ton of new features and improved features in the release of vSphere 6.0 and my intention is not to go through all of them and make yet another release note copy. VMware has put together a vSphere 6.0 documentation page that includes all the information you require in terms of release notes, installation documents, upgrade documents, component documentation and so on. You can find the page here.

I’m going to do a blog series including three blog post of three awesome improvements and/or new features in the new vSphere 6.0 release which a know a lot of you out there including many of my my customers will benefit a lot from.

The first one includes the new features of the well known feature VMware vMotion. Still remember when i first saw the feature and i that was one of the coolest things i have seen during my years in the IT industry.
Second, the support of multi vCPUs per virtual machine (VM) support in vSphere Fault Tolerance. Blog post available here.
Last thing is the Multi-Site Content Library. Blog post available here.

Three major improvements has been made to the vMotion feature. All of them adds goodness for especially disaster avoidance (DA) but also for the traditional vMotion process for both the automatic (Distributed Resource Schedular) process and the manual process used by vSphere administrators in their day-2-day job. So here they are.

  • Long distance vMotion – The process actually supports a Round Trip Time (RTT) of 100ms now instead of the old 5 ms limitation which has been around for a while now.
  • vMotion across virtual switches – How many times haven’t you been stuck or at least being forced to make some changes/workarounds to your or your customers environment during specific project or during day-2-day operation before you could complete the vMotion process based on incorrect vSphere network configuration.
  • vMotion across vCenter Servers – The vCenter Server is actually no longer the boundary for the vMotion process. You can actually move a VM from one vCenter Server to another and this also includes to the new vCenter Server’s Datacenter object and Folder object. I just can’t wait to see what different software vendors will say about this. Read, software vendors that requires you to license all the physical hardware where a VM might run. I would say in this case they have to claim all physical ESXi servers everywhere 🙂

The vMotion interface now has its own TCP/IP stack and by that can cross L3 network boundaries.

Features and requirements

As with any functionality they come with some features and some requirements.


  • MAC addresses preserved across vCenter Servers
    • Always unique within a vCenter Server
    • Not requested when VM leaves vCenter Server
  • Data prevention
    • Alarms, Events, Tasks History
    • DRS/HA
      • Host Isolation Response
      • Start up priority
      • Automation level
      • Affinity/Anti-Affinity Rules
    • MAC Addresses of virtual NIC
    • VM Resource Settings
      • Limits
      • Reservations
      • Shares
  • VM UUID is maintained across vCenter Servers


  • vCenter Server 6.0 or higher
  • SSO Domain
    • If using vSphere Web Client it has to be the same
    • If using API it is possible to use different
  • L2 network connectivity on VM port groups
    • IP addresses are not updated. Then you have to use e.g. Site Recovery Manager.
  • 250 Mbps network bandwidth per vMotion operation

vSphere 6.0 configuration maximums can be found here.

31 pings

Skip to comment form

Comments have been disabled.