vMotion and Storage vMotion (using vCenter)

Finally if you have been following the series we come to the most enjoyable part, vMotion, storage vMotion and Cold Migration. Before we start I just want to recap on my test environment I have two nested ESXi servers connected to a Synology iSCSI SAN which will supply the shared storage, I have created a RedHat VM to show you how to migrate storage using Storage vMotion.

To say we are moving a VM from one ESXi server to another with vMotion is a bit of a lie, we don't actually move the data at all, this stays on the shared storage, it's only the VM's memory contents that are moved from one ESXi server to another. The VM on the first ESXi server is duplicated on to the second ESXi server and then the original is deleted, during vMotion first ESXi server creates an initial pre-copy of memory from the running VM into the second ESXi server, during the copy process, a log file is generated to track all changes during the initial copy phase (it is referred to as a memory bitmap). Once the VM's are practically at the same state, this memory bitmap is transferred to the second ESXi server, before the transfer of the bitmap file the VM on the first ESXi server is put into a quiesced state. This state reduces the amount of activity occurring inside the VM that is being migrated, it allows the bitmap to become so small that it can be transferred very quickly, it also allows for rollback if a network failure occurs, this means that the migration will have to be successful or unsuccessful. When the bitmap has been transferred the user is then switched to the new ESXi server and the original VM is removed from the first ESXi server.

You need the following to perform a vMotion all requirements are for both ESXI servers involved

• Shared storage visibility between the source and destination ESXi servers, this also includes any RDM-mapped LUN's
• A VMKernel port group on a vSwitch configured with 1Gbps on the vMotion network, it will requires a separate IP address
• Access to the same network, preferably not going across switches/routers, etc
• Consistently labeled vSwitch port groups
• Compatible CPUs

If one of the above has not been met, then vMotion will fail. I just want to touch on the network quality, I highly recommend that you use a dedicated 1GB network for the vMotion, however I am seeing more companies using 10GB networks and running everything through this (Management, iSCSI, vMotion, etc). Also CPU compatibility is also a show stopper, try to make sure that all your ESXi server that you plan to use vMotion are the same, it is possible to vMotion across different CPU types but it can be a real pain and expensive option only to find out that it does not work, buy for compatibility.

There are a few requirements for the VM's

• Inconsistently named port groups, vMotion expects the port group name for both the vMotion vSwitch and VM port group to be spelled the same and in the same case, for example vMotion and VMotion are different.
• Active connections that use an internal switch, by active I mean that the VM is configured and connected to the same internal switch.
• Active connection to use a CD/DVD that is not shared, vMotion cannot guarantee that a CD/DVD will be connected after the switch
• CPU affinities, vMotion cannot guarantee that the VM will be able to continue to run on a specific CPU number on the destination server
• VMs in cluster relationship regarding the use of RDM files used in VM clustering, MSCS used to have problems with this
• No visibility to LUN, where RDM files are not visible to both ESXi servers
• Inconsistent security settings on a vSwitch/port group, if you have mismatched settings vMotion will error
• snapshots are fully supported you may be warned if reverting when a VM is moved, but as long as the data is on the shared storage there should be no problems

vMotion requires a VMKernel port group with a valid IP address and subnet mask for the vMotion network. A default gateway is not required (you should really have all ESXi servers that you are going to use with vMotion on the same subnet) but VMware does support vMotion across routers or WAN's.You can create a vMotion port group on an existing vSwitch.

So lets create the vMotion port group

Now we use vCenter to manage vMotion, DRS, HA, etc for the whole VMWare environment, so we start but setting up a Data Center folder called Production (in my case) and then we add the ESXi servers to the vCenter this allows the vCenter to manage these ESXi servers in the cluster in a per environment. You will not be able to create any virtual machines until a Datacenter has been created and at least one ESXi server has been added to this Datacenter.

Now we start to add the ESXi servers (hosts), by right-clicking on the Production data center and selecting add host

You are taken to a configuration screen, first enter the ESXi server IP address

Enter the root credentials, to allow the vCenter to login to the ESXi server (make sure the crednetials have admin access)

Then you get a summary screen

Enter any licensing, here I am just using evaluation licences for testing purposes

You can tighten security if you so wish but as this is a test rig i will leave it as default (disabled)

If you have setup multiple data centers you could select a specific data center

Finally we get to the summary screen, double check and click finish to allow the vCenter to control the ESXi server, do this for all ESXi servers you wish to manage by the vCenter

When you refresh the vCenter main screen you can see that we now have control over 2 ESXi servers, once of the ESXi server has a Red Hat 8 configured.

If you login to the ESXi server you can see that it is can also be managed by the vCenter server in several places, the state states that you are connected to the vCenter server and you have a notification in the middle of the screen.

VM vMotion

Now using vCenter we can use vMotion to very easily move VM's from one ESXi server to another

Storage vMotion

It is possible to move the storage of a VM and locate it to another storage area without even powering off, this is ideal when you want to migrate onto a new SAN or iSCSI server, thus upgrading your storage is a breeze, there are a number of other reasons to use Storage vMotion

• Decommission an old SAN array whose lease or warranty has expired
• switch from one storage type to another, say from Fibre channel to iSCSI
• Move VMs or virtual disks out of a LUN that is running out of space
• Ease future upgrades from one version of VMFS to another
• Convert RDM files into virtual disks

Like vMotion there are a number of requirements

• Spare memory and CPU cycles, when you move storage additional memory is required to carry out the process, also additional CPU cycles will be used
• Free space for snapshots, storage vMotion is a copy/ file delete process so make sure there is enough free spare space available
• Time it will take longer to copy the files across, the larger the files the longer it will take
• Concurrency try now to burden the ESXi server to much by running multiple storage vMotion's at once, maximum of 4 at any one time

Migrating the storage is the same process as migrating the VM as seen below, moving the storage Hot (while the VM is running) or Cold (VM is shutdown) is the same