vSphere 5.5 – Page 4

Automate VSAN Observer offline mode configurations

10.09.2014 by William Lam // 1 Comment

I was recently reading two of Rawlinson Rivera's articles (here and here) on configuring the VSAN Observer to be able to run in an "offline mode". The VSAN Observer currently leverages several open source libraries including Javascript, CSS and Font files to render the UI which assumes you have direct internet access to load these library files. In a traditional Enterprise environment, direct Internet access is usually not available and thought it could be provided either through a white list of proxy addresses, but in most cases it is just blocked.

Rawlinson provided a nice writeup on the specific library files that needs to be downloaded, the directory structure that needs to be created and the modifications required for each file. Unfortunately, the process is quite manual and potentially very error prone which usually screams for some Automation 🙂 I figure I could help my buddy Rawlinson out by creating two scripts which would download all the necessary files and the other script which will go ahead and update all the appropriate VSAN Observer files.

The first script is called download_vsan_observer_offline_files.sh which will download the necessary library files and put them in the expected directory structure externallibs{js,css,font} using cURL. This shell script is meant to run on a system which has Internet access and uses cURL to perform the download. If you do not have cURL, you can update the script to use wget instead. At the end of the script, you should see a directory created called externallibs which will need to be SCP'ed to the VCSA running the VSAN Observer (this is a prerequisite to the second script).

Here is an example of running the shell script:

The second script is called update_vsan_observer_offline_files.sh which runs on the VCSA that will be used for the VSAN Observer. This shell scripts expects the externallibs directory to be present before updating the VSAN Observer files and will error out if it does not detect it.

Here is an example of running the shell script:

At this point you are ready to run your VSAN Observer in an "offline mode" as Rawlinson has documented on his blog. Please refer his article for more details on using the VSAN Observer.

One thing I was pleasantly surprise to see in the latest vSphere 5.5 Update 2 release of the VCSA is that VSAN Observer now supports HTTPS as well as authentication when logging into the VSAN Observer UI. This is a very nice update and I recommend you download the latest release of VCSA to benefit from these new features.

HTML5 console now defaults to HTTPS/WSS in vSphere 5.5 Update 2

09.24.2014 by William Lam // 5 Comments

I just found out from one of my readers that with the latest release of vSphere 5.5 Update 2, the HTML5 Console in vCenter Server now goes over a secure connection (HTTPS) as well as using secure web socket connection (WSS) by default. In addition to this change, the HTML5 console port has also been changed from 7331 to 7343. I know customers have asking about this in the past and though this was not possible with previous releases, I am glad to see that VMware Engineering has now added this capablity, another reason to go to vSphere 5.5 Update 2!

This new change is also documented in the vSphere 5.5 Update release notes, which I some how must have missed:

Virtual machines with HTML 5 console in vSphere 5.5 open connections with http:// instead of https://
When the HTML 5 console is launched on a virtual machine, it uses connections like http:// and web sockets like ws:// instead of secure connections like https:// and wss://.

This release resolves the issue by launching the virtual machine console with secure connection over port 7343 instead of the connection over port 7331.

For those of you using my generateHTML5VMConsole script to generate a pre-authenticated HTML5 VM Console, I have updated the script to include a new variable called isvSphere55u2 which will default to "false" but you can set it in the command-line to "true" and this will automatically generate a URL using HTTPS instead of HTTP and use port 7343 instead of 7331. Other than these two minor changes, the URL format is exactly the same and will continue to work.

Here is a quick screenshot of the HTML5 VM Console URL in my lab running vSphere 5.5 Update 2:

Does VSAN work with Free ESXi?

07.22.2014 by William Lam // 8 Comments

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:

3 ESXi 5.5 hosts already installed and licensed with vSphere Hypervisor (Free ESXi) License
SSH Enabled

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.