WilliamLam.com

VCSA 6.5 CLI Installer now supports new ovftool argument pass-through feature

by // 2 Comments

I had recently discovered a really cool new feature that has been added into the vCenter Server Appliance (VCSA) 6.5 CLI Installer while helping out a fellow colleague. For those of you who have not worked with the VCSA before, you can deploy it using one of two methods: 1) Guided UI Installer 2) Scripted CLI installer. The latter approach is great for Automation purposes as well as being able to quickly spin up a new VCSA as the UI wizard can get tedious once you have done it a few times. The VCSA CLI Installer reads in a JSON configuration file which defines what you will be deploying whether that is an Embedded, PSC or VC node and its respective configuration (networking, password, etc).

In VCSA 6.5, the CLI Installer introduces a new option in the JSON schema called ovftool.arguments. Here is the description of what this new option provides:

Use this subsection to add arbitrary arguments to the OVF Tool
command that the script generates. You do not need to fill it out in
most circumstances.

First of all, I just want to mention that this option should not be required for general deployments but it may come in handy for more advanced use cases. Behind the scenes, the CLI Installer takes the human readable JSON and translates that to a set of OVF properties that are then sent down to ovftool for deployment. Not every single option is implemented in the JSON and for good reason as those level of details should be abstracted away from the end users. However, there may be cases where you may need to invoke a specific configuration or trigger a specific ovftool option and this would allow you to provide what I am calling a "pass-through" to ovftool.

Let me give you one concrete example on how this could be useful and how we can take advantage of this new capability. Since the release of VCSA 6.0, when you enable SSH and you login, you will notice that you are not placed in a regular bash shell but rather a restricted appliancesh interface. From an Automation standpoint, it was some what painful if you wanted to change the default as this feature is not implemented within the JSON configuration file. This meant that if you wanted the bash shell to be the default, you had to either change it manually as part of a post-deployment or you would have to by-pass the native CLI Installer and manually reverse engineer the required set of OVF properties needed for the deployment which is also not ideal.

[Read more...]

Automating the installation of VUM Update Manager Download Service (UMDS) for Linux in vSphere 6.5

by // 10 Comments

One of the most highly requested feature from customers with regards to the adoption of the vCenter Server Appliance (VCSA) is to have vSphere Update Manager (VUM) available as a Virtual Appliance. With the vSphere 6.5 release, this is now a reality as VUM is now embedded within the VCSA. The VUM service is also automatically enabled and associated with the vCenter Server instance which means from a customer standpoint, it is zero touch to get VUM up and running!

In addition to VUM being part of the VCSA 6.5, there is also the VUM Update Manager Download Service (UMDS) that can be installed on a separate Linux system. You can find the UMDS installer within the VCSA 6.5 ISO under the umds directory. To install UMDS, there are several pre-requisites that you must meet, some of which are documented here. The other requirements which are not documented are the additional OS package dependencies required to run the UMDS installer. While going through this by hand the first time, I found the following packages were required to install on an Ubuntu 14.04 distribution:

  • perl
  • tar
  • sed
  • psmisc
  • unixodbc
  • postgresql
  • postgresql-contrib
  • odbc-postgresql

For those of you who know me, if I have to perform something manually once, I might as well automate it for the future 🙂 I decided to create this quick shell script called install_umds65.sh which will allow you to easily deploy UMDS on an Ubuntu LTS 14.04 distribution. This can be useful for automated deployments or quickly standing up a lab environment.

[Read more...]

Custom script bundle is now possible with Auto Deploy in vSphere 6.5

by // 10 Comments

It has been some time since I had looked at the Auto Deploy and Host Profile feature in vSphere. As a former customer, I still remember one of the challenges I had in evaluating Auto Deploy and specifically Host Profiles was the fact that it did not cover all the possible ESXi configurations. This made it very difficult to operationalize as you still needed to handle post-configurations through other mechanisms. Trying to keep both solutions did not make sense for me and I ended up opting for the traditional scripted installation method via Kickstart which I had hooks into automate the full ESXi configuration.

In vSphere 6.5, there was a huge effort to significantly improve both Auto Deploy and Host Profile to what customers had expected of this feature, especially around bringing parity between the configurations that could be done using the vSphere Clients and/or vSphere APIs into Host Profiles. In addition, there was also several UI enhancements that now makes it possible to use both Auto Deploy and Image Builder directly from the vSphere Web Client which was never possible before. For more details, be sure to check out the What's New vSphere 6.5 white paper here.

One new feature that I think is worth calling out is the new Script Bundle capability in Auto Deploy. Previously, if a particular configuration was not available via Host Profiles, there was nothing you could really do and you had to write your own custom post-deployment script to apply to the ESXi host. As I mentioned earlier, in vSphere 6.5, we have closed the gap on the ESXi configurations that were not possible using Host Profile and will ensure that will be in sync going forward. Having said that, there are still certain configurations that are not possible today such as creating a custom ESXi firewall rule for example. For these cases, you either had to either hack it up using a method like this or to create a custom ESXi VIB which would then force customers to lower their ESXi's software acceptance level which was not ideal nor acceptable, especially for customers that are security conscious.

[Read more...]