There are many options when it comes to moving or copying Virtual Machine(s) across two ESXi hosts that are fully licensed and can be managed by a vCenter Server, but what about standalone ESXi hosts that only use the Free ESXi Hypervisor license?
Luckily, we have a couple of native solutions from VMware that not only work, but they are completely free to use, which some folks may not even realize!
I recently had to re-provision one of my VSAN lab environments using my recently shared ESXi 5.5 VSAN Kickstart. I usually specify a license key within the Kickstart so I do not have to license the ESXi host later. This actually got me wondering on whether VSAN would in fact work with Free ESXi aka vSphere Hypevisor? Being a curious person, I of course had to test this in the lab 🙂
Needless to say, if you want to properly evaluate or use VSAN in production, you should go through the supported method of using vCenter Server as it provides a simple and intuitive management interface for VSAN. More importantly, having the ability to create individual VM Storage Policies that can be applied on a per VMDK basis based on SLA's for your given application or Virtual Machine.
Disclaimer: This is not officially supported by VMware and running ESXi without a VSAN license is against VMware's EULA.
Since we do not have a vCenter Server, we will need to be able to fully configure VSAN without it. Luckily, we know of a way to "bootstraping" VSAN onto an ESXi host without vCenter Server and I will be leveraging that blog post to test this scenario with Free ESXi.
Prerequisite:
Step 1 - SSH to the first ESXi host and run the following ESXCLI command to create a VSAN Cluster:
esxcli vsan cluster join -u $(python -c 'import uuid; print str(uuid.uuid4());')
Step 2 - Run the following ESXCLI command to make a note of the VSAN Cluster UUID (highlighted in green in the screenshot above) which will be needed later:
esxcli vsan cluster get
Step 3 - Enable VSAN Traffic for VMkernel interface you plan on using for VSAN traffic by running the following ESXCLI command:
esxcli vsan network ipv4 add -i vmk0
Step 4 - Run the following command to view a list of disks that are eligible for use with VSAN. You will need a minimum of 1xSSD and 1xMD
vdq -q
Step 5 - Using the information from vdq, we will now create our VSAN Disk Group which will contain the SSD/MD's to be used for VSAN. Use the following ESXCLI command and substituting in the SSD/MD Names (please refer to the screenshot above for an example):
esxcli vsan storage add -s [SSD] -d [MD]
Step 6 - To ensure you have properly configured a VSAN Disk Group, you can run the following ESXCLI command to confirm:
esxcli vsan storage list
At this point, we now have a single ESXi host configured with VSAN Datastore, we can also confirm this by running the following ESXCLI command:
esxcli storage filesystem list
Step 7 - Repeat Steps 3-6 on the remainder two ESXi hosts
Step 8 - Finally, we now need to join the remainder ESXi hosts to the VSAN Cluster. We will need the VSAN Cluster UUID that we recorded earlier and specify that in the following ESXCLI command on each of the remainder ESXi hosts:
esxcli vsan cluster join -u [VSAN-CLUSTER-UUID]
If we now login to all of our ESXi hosts using the vSphere C# Client, we will see a common VSAN Datastore that is shared among the three ESXi hosts. To prove that that VSAN is in fact working, we can create a Virtual Machine and ensure we can power it on as seen in the screenshot below. By default, VSAN has a "Default" policy which defines FTT (Number of host failures to tolerate) set to 1 and assuming you have at least 3 ESXi hosts, all Virtual Machines will be protected by default.
Even though you can run VSAN using Free ESXi and leveraging the default VM Storage Policy that is built into VSAN for protecting Virtual Machines, you are only exercising a tiny portion of the potential that VSAN can bring when consuming it through vCenter Server. As mentioned earlier, you will not have the ability to create specific VM Storage Policies and assign them based on the specific SLAs and be able to easily monitor their compliance and remediation. The management of VSAN Cluster for adding additional capacity or serviceability is also quite limited without vCenter Server, though it can be definitely be done it is much easier with just a couple of clicks in the vSphere Web Client or a simple API call.
To be completely honest, I have not played with VMware Workstation in quite awhile as my day-to-day job primarily revolves around our Enterprise suite of products. In a recent meeting that I was in, I picked up on some interesting tidbits about the latest version of VMware Workstation 10 and after giving it a try in my lab, I thought I would share one very cool feature that you may be aware of (there is actually a lot of cool features in latest release, check what's new here).
The very first thing I noticed is that unlike other downloads from VMware in which you need to register the product and get an evaluation key. VMware Workstation can be downloaded without any registration and you can start the 30-day free trial immediately after installation! I think that is a really slick and can also come in handy if you need to install Workstation right away for something. Make sure you download from this page here by clicking on "Try for Free" instead of going to www.vmware.com/downloads
One of the capabilities that Workstation introduced probably a couple of releases ago was the ability to connect to a remote system whether that is another Workstation instance, vCenter Server and even an ESXi host. At the time I assumed this was to enable users to easily cold migrate a Virtual Machine that was created locally onto one of these remote targets.
What I did not realize was that you could do a lot more with this capability than to just copy offline Virtual Machines. To my surprise I found that you could fully manage the Virtual Machines on these remote targets including changing the virtual hardware configurations such as adding memory, cpu, disk, etc. guestOS as well as provision new Virtual Machines. The VM Console is fully functional leveraging VMRC and you can even connect to Free ESXi instances and get same capabilities you had with the legacy vSphere C# Client. The other neat thing about this is you can also manage your Virtual Hardware 10 VMs even though the latest vSphere C# Client does not allow this because VMware Workstation 10 is vHW10 aware.
Here is a screenshot of managing my Free ESXi host which is running on my Apple Mac Mini as well as my vCenter Server. As you can see you can have multiple connections open up which is quite useful, especially if you have a couple of Free ESXi hosts in which you would like a single pane of glass to manage.
Another nice feature is the amount of backwards capability it provides for vSphere. You can go as far back as vSphere 4.1 (vCenter Server & ESXi). To prove this in my environment, I provisioned a Nested ESXi running on vSphere 4.1, 5.0, 5.1 and 5.5 and connected them all to Workstation. This is another great way to manage standalone ESXi hosts if you still need to run older versions.
Lastly, you do not need to be running the Windows version of VMware Workstation to get these benefits. You can also do the same using Workstation for Linux and here is a screenshot of running Workstation on an Ubuntu desktop.
As you can see this is just one of many new and cool capabilities of VMware Workstation 10 and I have to say for $250, this is a steal to be able to easily manage not only your VMs running locally but also remote systems like vCenter Server, ESXi hosts including Free ESXi which is a huge deal IMHO. The Workstation team really knocked it out of the park and I am glad I had the opportunity to check out their latest release. I also hope VMware Fusion will be getting these capabilities in the near future! Simon, I hope you see this 😉