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.
<img class=“size-thumbnail wp-image-8092 alignright” src=“/images/2017/04/echo.jpeg” alt=“” width=“150” height=“150” and having everything wake up for me is really cool. I already have a vRealize Orchestrator workflow to shutdown my workload cluster. What I want to do is trigger that by a voice command from Alexa. Now, the correct and proper thing to do here would be to create a new Alexa skill, write the function in Lambda and connect that to my Orchestrator REST API and execute the workflow.
In this humble consultant’s opinion, Log Insight is one of the most useful tools in the administrator’s tool belt for troubleshooting vRealize Automation. I have lost count of the number of times I’ve been asked to help troubleshoot an issue that, when asked, people don’t know which log they should be looking at. The simple fact is that vRealize Automation has a lot of log files. Correlating these log sources to provide an overall picture is a painful, manual process - unless you have Log Insight!
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.
Equal Cost Multipathing (ECMP), for the vSphere admin, is ability to create routes with an equal cost, which allows multiple paths to the same network to be created and traffic can be distributed over those paths. This is good for a couple of reasons - firstly is availability. If we were to lose a host, and an NSX Edge, the route will time out quicker than NSX Edge High Availability - thus providing higher availability for our network traffic.
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.
Back in January 2015 I wrote an article on how to modify the Java heap settings for the vCenter Orchestrator client when working with very large workflows. Since vRealize Orchestrator 7.x has been released, we no longer have an installable client, just a Java WebStart file (.jnlp) that you run, or a package that you can download - but nothing that installs. Note that none of this is official or supported by VMware as far as I know - it’s the results of my experimentation which has shown some performance improvement by increasing the configured memory pool.
Recently I’ve been working on some ideas in my lab to leverage the AWS endpoint on vRealize Automation. One of the things I needed to get working was getting Software Components working on my AWS deployed instances. The diagram to the right shows my end-stage network - the instance deployed by vRA into AWS should be in a private subnet in my VPC, and should use my local lab DNS server and be able to access my vRA instance.
When you’re working with Amazon and vRealize Automation Software Components, one of the requirements is for the Guest Agent (gugent) to talk back to the vRealize Automation APIs - the gugent polls the API for tasks it should perform, downloads them from the API and executes them, then updates the tasks with a status. This means that Virtual Machines deployed as EC2 instances in an AWS VPC require the ability to talk back to internal corporate networks - not something you’d want to publish on the internet!