V-Motion feature from VMware is Industry revolution feature which allowed Customers to migrate the workload from one Host to another Host
Later we got a chance to play with Storage by using Storage V-Motion.
So VMware leftover with couple of other boundaries like Network (Layer 2), other Data Center and other vCenter Server ….
Let us learn new vSphere 6.0 enhancements for V-Motion.
1) Cross vCenter vMotion (xVC-vMotion)
2) Long Distance vMotion (LD-vMotion)
3) Extended Cross vCenter Server vMotion capability (ExVC-vMotion) – Not official one
Cross vSwitch vMotion basically allows you to migrate virtual machines between different vSwitches
Not just from vSS to vSS but also from vSS to vDS and vDS to vDS. Note that vDS to vSS is not supported. This is because when migrating from vDS metadata of the VM is transferred as well and the vSwitch does not have this logic and cannot handle the metadata. Note that the IP Address of the VM that you are migrating will not magically change, so you will need to make sure both the source and the destination portgroup belong to the same layer 2 network. All of this is very useful during for instance Datacenter Migrations or when you are moving VMs between clusters for instance or are migrating to a new vCenter instance even.
vMotion previously could only occur within a network managed by a single virtual switch, either a Virtual Standard Switch (VSS) or Virtual Distributed Switch (VDS). vMotion across vCenters will allow VMs to vMotion to a network managed by a different virtual switch effectively switching the networks seamlessly.
This will include:
- from VSS to VSS
- from VSS to VDS
- from VDS to VDS
You will not be able to vMotion from a VDS to a VSS. VDS port metadata will be transferred and cross vCenter vMotion is still transparent to the guest OS. You will still need Layer 2 VM network connectivity.
Cross vCenter vMotion. The ability to move a VM to a new vCenter Server instance is possible with vSphere 6.0
Not only can you move between vCenter Servers but you can do this with all the different migration types there are: change compute / storage / network. You can even do it without having a shared datastore between the source and destination vCenter aka “shared nothing migration. This functionality will come in handy when you are migrating to a different vCenter instance or even when you are migrating workloads to a different location. Note, it is a requirement for the source and destination vCenter Server to belong to the same SSO domain. When the VM is migrated things like alarms, events, HA and DRS settings are all migrated with it. So if you have affinity rules or changed the host isolation response or set a limit or reservation it will follow the VM which is very cool stuff.
Requirements:
- vCenter 6 (both ends)
- Single SSO domain (same SSO domain to use the UI). With an API it’s possible to use different SSO domain.
- L2 connectivity for VM network
- vMotion Network
- 250 Mbps network bandwidth per vMotion operation
vMotion across vCenters:
- VM UUID is maintained across vCenter server instances
- Retain Alarms, Events, tak and history
- HA/DRS settings including Affinity/anti-affinity rules, isolation responses, automation level, star-up priority
- VM ressources (shares, reservations, limits)
- Maintain MAC address of Virtual NIC
- VM which leaves for another vCenter will keep its MAC address and this MAC address will not be reused in the source vCenter.
- A datacenter was the highest point in the vCenter architecture…. But long distance vMotion can now get over it.
Long Distance vMotion. Maximum tolerated latency was 10ms for vMotion with earlier version and wit this new feature that just went up to 100ms.
Long distance vMotion uses socket buffer resizing techniques to ensure that migrations succeed when latency is high. Note that this will work with any storage system, both VMFS and NFS based solutions are fully supported. This feature still under testing and we may get more latency requirements with actual release.
Requirements
- Same as for the vMotion across vCenter servers.
- L2 connectivity for VM network
- Same VM IP address available at the destination (if not the VM will have to be re-iped and will lose connectivity)
- vMotion network needs L3 connectivity
- 250 Mbps per vMotion operation
Big Thanks to “Duncan Epping” for sharing the knowledge about this feature in his blog