VSphere

The Host Resources Deep Dive book by Frank Denneman and Niels Hagoort has been one of the most widely anticipated books in the VMware community - previous deep dive books by Frank (co-authored with Duncan Epping), tantalising blog posts and captivating presentations have whet the appetite for the last year or so. Having sat through some of these presentations at VMUGs and VMworld I can tell you the depth and understanding that the authors bring to the table is immense.

With the release of vSphere 6.5, VMware upped the game for vCenter High Availability (vCHA) and introduced an active/passive/witness cluster setup to provide a failover cluster for vCenter Server Appliances. The diagram below shows the architecture of the solution.

Deploying vCHA can be done in two modes - “Basic” and “Advanced”. You can use Basic mode if the vCenter you want to be HA is managing the hosts it resides on - in this scenario the wizard configures your vCenter and deploys the Passive and Witness nodes for you. If you have a management cluster for your vCenter Server, or you are deploying a nested environment, you need to use the advanced mode - in this scenario you must configure your active node, deploy clones for the passive and witness nodes, then enable the configuration.

I’ve been holding off upgrading my lab to vSphere 6.5  because NSX 6.2.x doesn’t support it. With the release of NSX 6.3 and vSphere 6.5a, I can now upgrade.

The sequence of the upgrade is slightly different to the generic one published by VMware because vSphere 6.5 isn’t supported with NSX 6.2. If follows that I need to upgrade NSX to 6.3 (which supports vSphere 6.0u2) before I can upgrade vSphere to 6.5a.

My vSphere lab is split into two halves - a low power management cluster, powered by 3 Intel NUCs, and a more hefty workload cluster powered by a Dell C6100 chassis with 3 nodes. The workload servers are noisy and power hungry so they tend to be powered off when I am not using them, and since they live in my garage, I power them on and off remotely.

One of the cool new features released with vRealize Automation 7.2 was the integration of VMware Admiral (container management) into the product, and recently VMware made version 1 of vSphere Integrated Containers generally available (GA), so I thought it was time I started playing around with the two.

In this article I’m going to cover deploying VIC to my vSphere environment and then adding that host to the vRA 7.2 container management.

As a vExpert, I am blessed to get 1000 CPU hours access to Ravello’s awesome platform and recently I’ve been playing with the AutoLab deployments tailored for Ravello.

If you’re unfamiliar with Ravello’s offering (where have you been?!) then it’s basically a custom hypervisor (HVX) running on either AWS or Google Cloud that allows you to run nested environments on those platforms. I did say it’s awesome.

With a Platform Services Controller appliance deployed as part of a vCenter Server installation, either integrated as part of the vCSA or as a separate PSC appliance, you can easily join the PSC to an Active Directory domain using the Web Client.

When you’ve deployed the PSC as the single sign on layer of a distributed vRealize Automation deployment, you don’t have the vSphere Web Client to configure it in the same way. This means that you can’t add an integrated Active Directory identity source to the default tenant, either using the PSC machine account or an SPN for Kerberos.

I tested vSphere 6 quite intensively when it was in beta, but I didn’t ever upgrade my lab - basically because I need a stable environment to work on and I wasn’t sure that I could maintain that with the beta.

Upgrading the vCenter Server Appliance

Download and mount the VMware-VCSA-all-6.0.0-2562643 ISO image (mounted as G:\ on my workstation).

Browse the ISO and run the Client Integration Plugin “G:\vcsa\VMware-ClientIntegrationPlugin-6.0.0.exe” - it’s a simple next, next finish sort of install.

Recently I encountered this problem in a customer site whereby the logon to VCSA 5.5 would either time out, or take 3-5 minutes to actually log on.

Running a netstat on the VCSA during the attempt to logon showed there was a SYN packet sent to the vCOps appliance on port 443 that never established a connection. Another check was attempting to connect using curl <https://> –k  - this would time out.

Derek Seaman’s excellent SSL toolkit. I know that there are hours and hours of work put into this script by Derek and I want to thank him for that – it’s a massive time saver. This modification is to fit a different set of circumstances – “standing on the shoulders of giants” – and should in no way be seen as me criticising or stealing Derek’s work.