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!

Native VCSA bootstrap installer in vSAN 6.6

by // 5 Comments

Graphic courtesy of Emad Younis

Almost four years ago, I documented a really cool vSAN capability here and here, which demonstrates how to bootstrap a vSAN datastore onto a single ESXi host. This powerful capability, which was by design, enables customers to easily standup new infrastructure including the vCenter Server Appliance (VCSA) in a pure greenfield environment where you only had bare-metal hardware to start with and no existing vCenter Server.

As you can probably guess, I am a huge advocate for this capability and I think it enables some really interesting use cases for being able to quickly and easily stand up a complete vSphere environment without having to rely on an external storage array or playing games with Storage vMotion'ing the VCSA between local VMFS and the vSAN datastore for initial provisioning.

Over time, this vSAN capability has gone mainstream not only from a customer standpoint but also internal to VMware. In fact, the use of this feature has made its way into several VMware implementations including but not limited to VMware Validated Designs (VVD), VxRail, VMware Cloud Foundation (VCF) and even in the upcoming VMware Cloud on AWS. This really goes to show how useful and critical of a feature this has become for standing up brand new VMware infrastructure which runs on top of vSAN. Huge thanks goes out to the original vSAN Architects who had envisioned such use cases and designed vSAN to include this functionality natively within the product and not have to rely or depend on vCenter Server.

[Read more...]

How to split vCenter Servers configured in an Enhanced Linked Mode (ELM)?

by // 22 Comments

An interesting question that came up on the VMTN forum the other day (thanks to Andreas Peetz for sharing via Twitter) was how to split two vCenter Servers configured in an Enhanced Linked Mode (ELM)? Due to an organization changes in the customers environment, they needed to separate out their two vCenter Servers and run them independently of each other. Although this may sound like an rare event, I have actually seen this use case come up several times now which maybe from a business unit restructuring, spinning out or selling off company assets which then requires the customer to split their existing vCenter Servers that is configured with ELM.

Below is a diagram depicting an example where the original source environment (left) which is composed of two vCenter Servers and two external Platform Services Controller (PSC) configured in an ELM and the desired destination environment (right) which are two separate vCenter Server instances no longer configured in ELM.


The solution to this problem is actually pretty straight forward and leverages the existing vCenter Server and/or Platform Services Controller (PSC) "decommission" workflow. Rather than decommissioning the nodes, we are just simply keeping them around. Below are the instructions on how to achieve this outcome.

UPDATE (05/31/22) - I was recently made aware of the following VMware KB 2106736 article that provides official guidance for splitting/unregistering your vCenter Server from ELM. This should be followed as the officially supported method

UPDATE (01/28/19) - As of vSphere 6.7 Update 1, splitting an Enhanced Linked Mode (ELM) configuration is now supported by using the repointing workflow provided by the enhanced cmsso-util tool.

Disclaimer: Although this solution uses an existing supported workflow, this particular use case has not been tested by VMware. As such, this would not be officially supported by VMware until the appropriate testing has been done by our Engineering teams. One potential option in the short term if you are looking for support from VMware is to file an RPQ request through your VMware account team.

[Read more...]