vMotion Across Virtual Switches
With vSphere 6.0 you can migrate Virtual Machines across virtual switches. The new vMotion workflow allows you to choose the destination network which can be on a vSwitch or vDS. This feature eliminates the need to span virtual switches across two locations. Nevertheless you still have to span the subnet between both locations because vMotion does not change the IP address.
The new workflow is integrated to the migration process in the vSphere Web Client. After selecting the compute resource and optionally storage, you can select a new destination network for each VM network adapter.
You can migrate between the same type of switches, or from a vSwitch to a vDS. Migrating from vDS to vSwitch is not supported:
"The type of the destination network is not supported for vMotion based on the source network type."
"Network card 'Network adapter 1' has a DVPort backing, which is not supported. This could be because the host does not support VDS or because the host has not joined a VDS."
vMotion Across vCenter Servers
vSphere 6 allows to simultaneously change compute, storage, networks, and management. This enables you to migrate virtual machines across Datacenter and vCenter boundaries. VM Properties are maintained across vCenter Server instances, this includes VM UUID, Events and Tasks History, Alarms, DRS anti-affinity rules and HA properties.
Cross vCenter vMotion triggered by the vSphere Web Client requires both vCenters to be in the same SSO domain. Migration with different SSO domains is possible by using the API.
The new workflow is integrated to the migration process in the vSphere Web Client. Destination resources can be selected in the following sequences:
- Compute resource > Storage > Network
- Storage > Compute resource > Network
- Virtual Datacenter > Storage Policy > Network > Placement Policy
Beside the network, the new part is in the compute resource page where you can chose between all vCenters that are part of the SSO domain.
Routed Long-Distance vMotion
In vSphere 6.0 vMotion traffic is no longer bound to the same subnet. Routed L3 connections for vMotion traffic are supported. Bandwith requirements are 250 Mbps per concurrent vMotion operation.
The latency or round-trip time limit for vMotion has been increased to 100ms. What does that means in terms of distance? Optical cables transfer data at the speed of light in glass which is around 200,000 km/s. Thus the maximum distance for a supported round-trip time of 100ms is theoretically 10,000 km. In the real world you have delays caused by switches and routers and the cable is never in a linear distance.
Round-trip times that we see in the real world are:
- 73ms from New York to San Francisco (4100km)
- 80ms from New York to Amsterdam (5900km)
With vSphere 6.0 we can migrate a virtual machine across the Atlantic
Pingback: vSphere 6.0 vExpert Blog Articles | VMTN Blog - VMware Blogs
Message is confusing !
- Nevertheless you still have to span the subnet between both locations because vMotion does not change the IP address.
and
- In vSphere 6.0 vMotion traffic is no longer bound to the same subnet. Routed L3 connections for vMotion traffic are supported.
That are 2 different networks. The vMotion network where ESXi hosts are talking to each other to transfer the virtual machine, and the network where the virtual machine is connected to. The traffic between ESXi hosts can be routed since vSphere 6.0.
Both of this Statements refer to the vmotion Network ?
It therefore still implies: mandatory to be L2 !
"Nevertheless you still have to span.." refers to the VM network. The new fact is actually that you can switch the virtual machines Portgroup/vSwitch during vMotion. But both portgroups require L2 connectivity.
Pingback: Which vSphere 6.0 Features are available in Editions? | Virten.net
Pingback: vSphere 6.0 vExpert Blog Articles Covering What’s New, Installation, VVOLS, vMotion, VSAN, Web Client and much much more | Toronto VMware User Group