WilliamLam.com

Automating the new native VCSA bootstrap "Easy Install" in vSAN 6.6

by // 10 Comments

In case you missed the previous article, have a read here which goes into greater detail behind the new VCSA bootstrap installer (also known as vSAN Easy Install) which is part of the new vSAN 6.6 release. As I hinted at the end of the previous post, customers not only have a simplified way of bootstrapping the VCSA on vSAN from a UI standpoint but they can also completely automate this leveraging some of the new vSAN Management 6.6 APIs, which are the same APIs that the UI uses.

A new Managed Object called VsanVcsaDeployerSystem is now available when connecting to either a standalone ESXi host as well as a vCenter Server. It contains the following three methods:

Here is the workflow for automating the VCSA bootstrap installer:

Step 1 - Connect directly to the ESXi host which you wish to bootstrap vSAN. You will use the VsanPrepareVsanForVcsa() API which accepts a list of disks for either a Hybrid or All-Flash vSAN datastore.

Step 2 - Deploy the VCSA like you normally would using the CLI Installer. You will specify the ESXi host that you had just prepared in Step 1 which includes the vSAN Datastore that was setup as part of that process.

Step 3 - Once the VCSA has been successfully deployed, you will connect to the vCenter Server and use the VsanPostConfigForVcsa() API which will create a vSphere Datacenter, vSphere Cluster and enable it with vSAN (which can also include Dedupe/Compression if you are using an All-Flash setup) and then automatically add the ESXi host that you had just bootstrapped. If you have provisioned other ESXi hosts that have not been configured with vSAN, you can also include that into the API request. The really nice thing about this "post" API is that rather than having to call into several existing vSphere APIs to setup vCenter Server, you can do all of that just using this single API!

To help demonstrate the use of the these new vSAN Management APIs, I have created a simple Python script which exercises these new APIs called vsan-vcsa-deployer-sample.py The script supports three operations: listdisk, prepare and post.

Here is an example of running the listdisk operation which will list all available disks that are currently not in use and can be used by vSAN:

python vsan-vcsa-deployer-sample.py -s 192.168.1.100 -u root -p VMware1! --operation listdisk

Once you have the disks information, you can then use the prepare operation as shown below to bootstrap your ESXi host:

python vsan-vcsa-deployer-sample.py -s 192.168.1.100 -u root -p VMware1! --operation prepare --cache "SAMSUNG MZVPV128" --capacity "Samsung SSD 850"


At this point, you are now ready to deploy the VCSA using the CLI Installer. Once that has completed, you can complete the process by using the post operation and provide the required parameters to setup vCenter Server including the ESXi host that you had just bootstrapped so it can be added to the vCenter Server inventory as shown below:

python vsan-vcsa-deployer-sample.py -s 192.168.1.200 -u '*protected email*' -p VMware1! --operation post --datacenterName "VSAN-Datacenter" --clusterName "VSAN-Cluster" --esxName 192.168.1.100 --esxUsername root --esxPassword VMware1!


Once the post operation has completed, you will have a fully configured vCenter Server which you can check by logging into the vSphere Web Client. Pretty slick, if you ask me!

Project USB to SDDC - Part 3

by // 30 Comments

OK, the wait is finally over! In this final article, we will now walk through the process of getting access to this project as well as how to get this deployed in your own environment. For those that just want to see the code, you can find it at the Github project below:

Github Project: https://github.com/lamw/usb-to-sddc

Below are the details outlining the environment and software requirements as well as the instructions to consume this in your own home lab environment. The content below is a subset of what is published on the Github project, but this should get you going. For more details, please refer to the Github project and if you have any issues/questions, feel free to file a Github issue.

Environment Requirements:

  • USB key that is at least 6GB in capacity
  • Access to either macOS or Linux system as the script that creates the USB key is only supported on these two platforms
  • No additional USB keys must be plugged into the hardware system other than the primary installer USB key
  • Hardware system must have at least 2 disk drives which can either be 1xHDD and 1xSSD for running Hybrid vSAN OR 2xSSD for running All-Flash vSAN
  • Both Intel NUC 6th Gen and Supermicro E200-8D and E300-8D have been tested with this solution. It should work with other hardware systems that meet the minimum requirements but YMMV

Software Requirements:

Note: Other ESXi / VCSA 6.5.x versions can also be substituted, this includes the latest ESXi 6.5d (vSAN 6.6) release which I have also verified myself.

UPDATE (04/17/18) - No changes are required to get vSphere 6.7 to work, the only minor thing to be aware of is that the vSphere Web Client customization has changed in 6.7 and so you need to set VCSA_WEBCLIENT_THEME_NAME="" as empty string or you will find that the UI will not load unless you delete the customization directory in the VCSA that was pulled down automatically.

[Read more...]

Updated Nested ESXi 6.0u3 & 6.5d Virtual Appliances

by // 29 Comments

I finally found a bit of "extra" spare time to update my Nested ESXi Virtual Appliances to support some of the recent releases of ESXi, 6.0 Update 3 and 6.5d, which enables customers to easily and quickly deploy vSAN 6.6 in their environment for testing, development or learning purposes. If you have not used this appliance before, please have a look at this article which goes into greater detail on how to deploy and use the Nested ESXi VA.

As part of this update, I also spent some time looking at all the feedback that I had received from the community since releasing the VA and I took this opportunity to also add some nice enhancements that folks have been asking about 🙂 Jump towards the bottom to see what's new. To reduce the number of VA's that I need to manage and due to usage, the following VA's have recently been decommissioned. I only plan on supporting the latest versions which you can find in the links below.

Decommissioned VA's:

  • ESXi 5.5 Update 3 (Nested_ESXi5.x_Appliance_Template_v2.ova)
  • ESXi 6.0 Update 2 (Nested_ESXi6.x_Appliance_Template_v5.ova)
  • ESXi 6.5 GA (Nested_ESXi6.5_Appliance_Template_v1.ova)

New VA's:

What's New:

  • Support for DHCP 
    • I know this might sound pretty basic but before you were required to specify a static IP (even if you had DHCP). By default, you no longer need to fill out the networking section as highlighted in yellow below.
  • Support for default root password
    • You no longer need to provide root password, it will default to the famous VMware1! The issue in the past was that I had randomly generated a password which I discarded and when the customization failed, it was very difficult to troubleshoot since I do not actually have the password 😉 Hopefully we do not have any other bugs, but this will make debugging easier and also reduce the amount of input if you want to quickly spin up an ESXi instance.
  • Support for VLAN ID
    • Though not a huge number of requests, there were still of you who asked for 802.1q (trunk) support on Management VMkernel interface. This is an optional field and obviously this is only applicable if you provide a static IP Address.
  • Automatic removal of Customization VIB
    • As some of you may or may not know, the way in which these OVF properties are processed within the Nested ESXi instance is a special firstboot script which reads in these values and then applies the ESXi customization. If everything is successful, there really is no use for this to exists further and although you could set a certain advanced setting to force re-customization, it was quicker to just re-deploy. With that in mind, the customization VIB is now automatically removed once its done its job. I have included a special debug option that would allow it to not be deleted in scenarios where there are issues and we need to take a look at the state of the system. With this change, you really now have a "vanilla" ESXi instance 🙂
  • Fixed dvFilter param for eth1


Hope you enjoy some of these new updates and happy Nesting!