VMware vMotion

VMware vMotion

is a feature of vSphere and comes with most license editions. The Essentials Kit and the free stand-alone ESXi edition do not come with this capability.

vMotion is the ability to migrate virtual machines (VMs), also referred to as a

guest

, from one physical ESX host to another without service interruption to the VM. This is a popular feature because it reduces downtime to the VMs and decouples the VMs in a way from the host. A host is just a resource in an ESX cluster now.

File Usage Description

.vmx vmname.vmx Virtual machine configuration file

.vmxf vmname.vmxf Additional virtual machine configuration files .vmdk vmname.vmdk Virtual disk characteristics

-flat.vmdk vmname-flat.vmdk Virtual machine data disk

.nvram vmname.nvram or nvram Virtual machine BIOS or EFI configuration .vmsd vmname.vmsd Virtual machine snapshots

.vmsn vmname.vmsn Virtual machine snapshot data file .vswp vmname.vswp Virtual machine swap file

.vmss vmname.vmss Virtual machine suspend file .log vmware.log Current virtual machine log file -#.log vmware-#.log (where # is a

number starting with 1)

Old virtual machine log entries

Note: When changing the virtual machine name, for example, in the vSphere Client, the

virtual machine home folder and the virtual machine’s virtual disk file names are not automatically renamed. To align the virtual machine file names with the name in the vSphere Client, you need to perform a storage vMotion. However, this was not available in vSphere 5.1. In the vSphere 5.1 update 1, you have to set the vCenter advanced

Figure 3-12 shows an illustration of a VM migration with vMotion.

Figure 3-12 vMotion illustration

vMotion requires a VMkernel network that should have at least 1 Gbit Ethernet connections with a recommended two physical network ports for redundancy. The vMotion network should be a private non-routed network as the virtual machine’s memory is transferred over this, by default, unencrypted. All ESX hosts within a cluster or hosts between vMotion should be enabled and need to be on the same vMotion network. However, no other servers but ESX hosts should be connected to this network because the virtual machine’s memory should not be seen by other servers.

The active memory and execution state is transferred over the vMotion network. vMotion will keep track of the continuous memory transactions in a bitmap. When the entire memory and system state has been transferred over to the destination host, the virtual machine gets suspended on the source host. Then, the bitmap gets copied over to the destination host and the VM gets resumed. With a 1 Gbit connection, this switch over from the source to the target host takes no longer than two seconds, which should be tolerated by the majority of guest systems. If the change rate of the VM memory is greater than the network interface card (NIC) speed, the hypervisor will stun the VM gradually until the change rate is less than the vMotion network. VMs will therefore greatly benefit from increased vMotion bandwidth. Virtual machine networks are virtual as well, and vSphere manages the MAC address. When the virtual machine becomes active on the destination host, the host sends out an RARP packet to the physical network switch to update its table with the new switch port location. With vSphere 5.0, VMware supports multi-NIC vMotion. What this means is that before this, you could have only a single vMotion port group, which could then have multiple NIC ports. However, only one physical network connection can be used at a time leaving the other connections unused and only needed for redundancy in case a connection fails. With vSphere 5.0, a vMotion port group could still only use one network connection at a time, but now you could have multiple vMotion port groups with different IP addresses. And, the ESXi host can load balance between them allowing an increase in the vMotion bandwidth.

Figure 3-13 on page 109 shows a comparison between standard vMotion implementation and multi-NIC vMotion.

Figure 3-13 Simplified illustration of standard and multi-NIC vMotion

vSphere 5.1 also supports vMotion over Metro Networks (long distance) with round-trip latencies of up to 10 ms. This is important for Metro Cluster (SVC Stretched Cluster) implementations where VMs might have to be migrated over a long distance.

New in vSphere 5.1 is the capability to vMotion virtual machines without the requirement of shared storage. This is often referred to as

XvMotion

,

Unified vMotion

, or

enhanced vMotion

but it is not marketed as a separate product and therefore has no separate name. This capability is supported by any edition that supports vMotion.

It now is possible to vMotion a virtual machine from one host with local storage to another host with local storage without service interruption. Before, it was also possible to migrate a virtual machine but only when it was powered off. This is called

cold migration

and is not referred to as vMotion because vMotion is referred to as

live migration

from one host to another.

For more information about vMotion, see the VMware white paper,

VMware vSphere 5.1

vMotion Architecture, Performance and Best Practices

at the following website:

http://www.vmware.com/files/pdf/techpaper/VMware-vSphere51-vMotion-Perf.pdf

In document IBM SAN Solution Design Best Practices for VMware vsphere ESXi (Page 123-125)