Tuesday, March 15, 2016

vSphere 6 - migration and vMotion

In my previous blog post, I created a datastore using NFS on an OpenFiler device. I will now demonstrate how we can move the virtual machine (Lubuntu-1) from its current location, on "ESX1-DataStore", to a new location on the OpenFiler: "OFNAS-1-DataStore".

This type of migration relates to the storage of the files that constitute the virtual machine. I will perform the migration with the virtual machine turned off.

It is also possible to move running (turned on) virtual machines using what is known as "vMotion". I wanted to demonstrate this type of operation as well. This was not successful, apparently because of incompatiblity between the hosts between which the migration was to take place.

I have heard that there may be a way to overcome this problem. Unfortunately, I am using a trial version of vCenter that has expired. Therefore, at this time, I am no longer able to experiment with running virtual machines.


Migrating virtual machine files to different storage

At the location shown below, we right-click on the name of the virtual machine (Lubuntu-1) and select Migrate in the menu:

In this scenario, I will simply move the storage location for the files that constitute the virtual machine, so I select the option "Change storage only" in the screenshot below:

Next, I select the new storage location for the virtual machine (OFNAS-1 - later renamed OFNAS-1-DataStore for consistency):

Step 3 summarizes our choices:

We click on Finish to start the migration and can view the progress as illustrated here:

vMotion or "live migration" (unsuccessful attempt)

Before vSphere 5.5, vMotion required "shared storage". In the screenshots below, for example, I could not have moved a running VM from local storage one ESXi host to local storage on another ESXi host, (i.e. from ESX1-DataStore to ESX2-DataStore). More recent versions of vSphere are no longer subject to this limitation. However, shared storage (a "SAN" or "Storage Area Network" for example), remains the most common scenario in many (most?) vSphere implementations and I will use shared storage in my example below.

At first, the "OFNAS-1-DataStore" - created in the last blog post - is only visible to host ESX1 (in addition to its local datastore "ESX1-DataStore"):

ESX2 is not aware of the existence of the shared storage on the OpenFiler (only local storage is visible):

We make the shared storage visible to ESX2 by selecting "OFNAS-1-DataStore", right-clicking on the icon and selecting the "Mount Datastore to Additional Hosts" option:

We then select ESX2 as the additional host:

Now ESX2 sees the shared storage also:

At this point, I will attempt to migrate a running virtual machine with vMotion. In the Virtual Machines section of vCenter, I select the VM in question (Lubuntu-1 in my case) and turn it on:

Next, we right-click on the VM and (in the resulting menu) select Migrate:

We then select "Change compute resource only" for the migration type (the VM will use the CPU and memory of a different host - ESX2 instead of ESX1 - but the storage remains unchanged - with the OpenFiler, in my case):

Right now, ESX1 provides CPU and memory resources for the VM. We want to transfer this role to ESX2. So we select ESX2 as the new "compute resource":

Apparently, there are CPU incompatibilities between the two hosts and the compatibility check fails:


It is on this unsuccessful result that my first experiments with vSphere 6 came to an end. I used a trial license that expired the following day. Without a valid license (trial or other), the virtual machines will not mount and this limitation prevents further practice with vSphere 6 for the moment. It appears that VMware offers a 365 day evaluation license for certain VMware products to members of the VMware Users Group or "VMUG":


I may examine this option to gain further experience with VMware products. In the near future, however, there are some products from other vendors with which I would like to experiment.

As the radio hosts used to say: "please stay tuned".

No comments:

Post a Comment