VCSA – Page 28

What's New in vSphere 6.0 Update 1 for VCSA?

09.01.2015 by William Lam // 31 Comments

One of the announcements at VMworld this week is the upcoming release of vSphere 6.0 Update 1 (GA sometime in Q3 2015) and in addition to bug fixes there are also several new enhancements that have been added. Here are some of the new capabilities specifically for the vCenter Server Appliance (VCSA).

New Deployment Targets - The VCSA now supports both vCenter Server (brownfield) as well as ESXi (greenfield) as a deployment targets.When using either the Guided UI or Scripted UI, you can now deploy to an existing vCenter Server which might serve as a management cluster for example. Previously, ESXi was the only supported deployment target.
Convert Embedded VCSA to External PSC - An Embedded VCSA deployment can now be re-configured or re-pointed to an External PSC using the new "reconfigure" and "repoint" option found in the /bin/cmsso-util utility. This allows customers to quickly get started using the simple Embedded VCSA deployment and as they get more comfortable and want to scale out to an External PSC for features like Enhanced Linked Mode, you can easily do so.

Two of the most frequently asked questions that I have seen from customers since the release of the VCSA 6.0 is where did the VMware Appliance Management Interface (VAMI) and URL-based patching go? These were definitely two missed features that did not make it into VCSA 6.0 release and today I am pleased to announce that they have returned with some nice enhancements!

VAMI UI - The VAMI UI can be accessed in the familiar 5480 port by visiting the following URL of the VCSA: https://[VCSA]:5480 and requires a local OS account to login like the root user account. The VAMI itself has been completely re-written both on the backend as well as the frontend which is now an HTML5 interface. All VAMI functionality can be accessed both from the UI as well as using the appliancesh command-line interface.

URL-based patching - URL-based patching is also included in the new VAMI UI interface. By default it is configured to point back to VMware's online repository but you can also configure it to use an ISO or a custom repository as previous versions supported. All patching capabilities are also available using the appliancesh command-line interface.

PSC UI - In addition to new VAMI UI, there also now a new Platform Services Controller (PSC) UI which is also written in HTML5. The new UI is located at the following URL: https://[VCSA]/psc and requires an SSO Administrator account to login. This new UI actually uses the same backend as the PSC configurations found within the vSphere Web Client. The idea behind this UI is to provide customers with a way to configure SSO and other related configurations within the PSC for either a greenfield setup or when the vSphere Web Client is unavailable. This can come in handy for troubleshooting purposes. Lastly, with the new PSC UI, you will now be able to replace certificates from a UI standpoint where as previously this was only available in the CLI.

Build-2-Build upgrade support - In prior releases, both a "Major" and "U" (Update) release of the VCSA meant that you had to deploy the new VCSA to perform a migration based upgrade. In vSphere 6.0 Update 1, "U" releases (U1, U2, etc) can now be accomplished by an in-place upgrade or sometimes refer to as a build-2-build. There will be a VCSA 6.0 Update 1 ISO which can be mounted within your existing VCSA 6.0 appliance to perform the upgrade as seen in the screenshot below.

appliancesh automation - The appliancesh interface in the VCSA 6.0 was primarily targeted for interactive usage and did not support any type of Automation. The feedback from customers was to provide a way to be able to call into the various appliancesh commands and in VCSA 6.0 Update 1, you can now execute a series of appliancesh commands within a file and re-directing that into an SSH session. VMware is also looking into providing a proper API for the appliancesh commands, if you have any feedback on this please leave a comment or reach out to Alan Renouf, who is the PM.

Below is the contents of the vcsa-commands.txt file which contains the following appliancesh commands to configure and enable NTP for the VCSA:

ntp.test --servers 0.pool.ntp.org,1.pool.ntp.org
ntp.server.add --server 0.pool.ntp.org,1.pool.ntp.org
timesync.set --mode NTP
ntp.get

Lastly, though this is not specific to the VCSA, I thought it was also worth mentioning that you can now access ALL capabilities of vSphere Update Manager (VUM) within the vSphere Web Client. VUM will still require a separate Windows system, but will fully inter-operate with both the Windows VC as well as the VCSA and you no longer need to rely on the vSphere C# Client to perform remediation or base-line creation and assignments.

As you can see, there are a ton of enhancements in the latest vSphere 6.0 Update 1 release and if you have not taken vSphere 6.0 for a spin yet, I definitely recommend starting with this release.

Schedule automated backups of VCSA 6.0 vPostgres embedded database to Amazon S3

07.09.2015 by William Lam // 6 Comments

A couple of weeks back, I had received a question around backing up and restoring the Embedded vPostgres Database found within the new vCenter Server Appliance (VCSA) 6.0. At the time, the only thing I had seen was KB 2110294 and vSphere 6.0 Documentation here which recommends that a full VM backup be taken for either the vCenter Server for Windows as well as the VCSA to be able to properly protect your vCenter Server.

It was just recently that I came across VMware KB 2091961 which provides some details on just backing up the individual vPostgres DB. Having said that, just having a database backup is not sufficient to perform a proper restore in the case of completely losing your vCenter Server. There are other sources of data within the vCenter Server as well as the Platform Services Controller that are required and restoring a database would only work if you still had access to the original system. This is why a full VM backup is still the recommended approach.

For those who want to be able to just restore the database, the process listed in the KB is currently a manual step which uses a Python script that is provided in the KB. I thought it would be useful to demonstrate how you could schedule continuous backups during off peak hours using a simple cronjob and more interesting to me, is the how and where of the overall process? One option would be to mount a backup NFS share directly onto the VCSA and place all backups on that volume. Another option could have the backups directly uploaded to a Storage Cloud Provider like an Amazon S3 for example. I decided to take a look into the latter option.

In searching online, I found that Amazon offers a nice CLI called AWS CLI which provides S3 functionality like the 'cp' command and I was able to install it on the VCSA without any issues. You can find the instructions for installing the AWS CLI here and I would also recommend that you create a dedicate user assigned to the S3 bucket for storing the backups and then following the steps here to configure access to the AWS CLI. When asked about the Amazon Region as part of the configuration, I found this page to be helpful in listing the region names.

Disclaimer: Installing 3rd Party tools and products on the (VCSA) is not officially supported, you may be asked by GSS to remove them during troubleshooting.

If everything is installed correct, you should be able to run the following command to ensure you can reach the S3 bucket:

aws s3 ls s3:\\[NAME-OF-YOUR-S3-BUCKET]

To tie everything together, I created a simple shell script called backup_vcsa_vpostgres_db.sh which contains a couple of variables that you will need to edit:

VPOSTGRES_BACKUP_SCRIPT - The path to the Python vPostgres backup script
AWS_CLI - The full path to the AWS CLI binary
AWS_S3_BUCKET - The name of the S3 bucket using syntax s3:\\NAME-OF-YOUR-S3-BUCKET

Before creating the cronjob, I would recommend that you manually run the script to ensure everything works as expected and you are able to upload to your S3 bucket. Here is an example execution of the script which is backing up to my S3 bucket which I called "vcsa-backup".

You can quickly verify that the backup has been uploaded to the S3 bucket by running the "ls" command as shown earlier or you can login to the Amazon S3 console and you should be able to see the backup files as shown in the screenshot below.

To schedule the script to automatically run during a certain period, you can create a cronjob by running the following command:

crontab -e

For more information about setting up a cronjob, you can take a look here or Google your favorite resource. If you plan on storing backups with a Cloud Storage Provider and do not have direct internet access like most customers do, you can configure an HTTP(S) proxy by editing /etc/sysconfig/proxy If you prefer not to install AWS CLI, you can also use this simple bash script which uses an HTTP POST to upload to Amazon S3.

Quick Tip - VCSIM no longer works in VCSA 6.0

07.01.2015 by William Lam // 2 Comments

I figured I do a quick blog post on the topic of VCSIM and VCSA 6.0 since I have received several questions regarding its functioanlity in VCSA 6.0. The simple and unfortunate answer is that VCSIM no longer functions in the latest VCSA 6.0. There have been enough changes to the vSphere 5.x and vSphere 6.0 code base that this internal tool will no longer function. As far as I know, there are no plans of changing this as VCSIM was primarily used internally by our Developers for certain types of functional testing. I know I will miss using the tool as it did come in handy!

UPDATE (04/23/17) - For those interested in VCSIM, there is a new project called govcsim. For more details check it out here.

VCSIM should continue to work in both VCSA 5.1 and 5.5 and you can find more details in the articles below.