Just recently a few colleagues of mine were attempting to generate new private keys with a 4096 bit size but they were seeing shocking performance from all of their Linux VMs. They were seeing key generation taking up to 15 minutes while smashing away at the keyboard to generate entropy. It wasn’t a resource issue, the VMs were sized appropriately and showed no signs of stress. They asked me if they could throw a “Chaos Key” USB device into each of the ESXi hosts to generate more entropy to reduce the time it takes, but I knew that wasn’t required (like I was going to let that happen).

If you followed my previous posts on auto deploying a Hugo site from GitHub to S3 (Part 1, Part 2) you may have noticed that GitHub is deprecating the GitHub Services Integration mechanism. This is critical to the auto deployment function so we’ll need an alternative. To add to my woes, I’ve found that the Node deployment package and all of its dependencies involves more maintenance than it deserves. I also noticed that the original Node package was only adding to the target S3 bucket, not performing a sync or equivalent.

With the release of vCloud Director 9.5 I’ve gone ahead and upgraded my test environment from 9.1 (specifically 9.1.0.1) to 9.5. Straight away I notice in the release notes that having a mix of vCloud Director appliances and Linux servers (with vCD installed) is not supported. There is also no supported migration method to move from Linux servers to the appliance. So, in place upgrade it is! I won’t go over the entire experience of using the HTML5 UI, only things I’ve noticed that are new in 9.

VMware has released vCloud Director 9.5! If you go to the My VMware downloads section you won’t find it. You need to change the URL so it has “9_5” on the end: vCloud Director 9.5 Download Assuming you have the right entitlements, you’ll be able to start downloading the upgrade bin’s and the OVA. To find out what’s new, VMware have released a PDF highlighting all the new features: What’s new with vCloud Director 9.

I’ve been working on some more automation lately for vCloud Director using vRealize Orchestrator. One of my use cases was to retrieve the SDK Connection scripting object for the linked vCenter Server. My starting point was an Org vDC, and from there I wanted to get the backing vCenter Server. Let’s start by getting the Provider vDC vCloud Reference object from the Org vDC scripting object (orgVDC): var providerRef = orgVDC.

I’ve got a standalone vRealize Orchestrator 7.4 instance in my test environment and with the release of vRealize Orchestrator 7.5 I wanted to run through the upgrade. If you haven’t noticed already, it’s a migration to a new appliance not an in-place upgrade. This means the new vRO instance will need to connect to the existing vRO appliance and pull all of the data. When I tried doing my migration/upgrade, I got the following error message during the validation phase:

Last year the legendary William Lam (Virtually Ghetto) posted a handy Powershell script that can use the vSphere 6.5 API’s to send keyboard key strokes to a VM (https://www.virtuallyghetto.com/2017/09/automating-vm-keystrokes-using-the-vsphere-api-powercli.html). I recently had a need for this feature but in vRealize Orchestrator and in Javascript instead of Powershell so I’ve re-written it in Javascript. I’ve included 2 additional script blocks that you can place into Scriptable Tasks or Actions too.

I’ve been working on some automation that will create metadata against objects in vCloud Director using vRealize Orchestrator. If you’ve ever had to do this before you’ll know how painful it can be to get your head around all of the objects/transformations you need to make before you can even set the metadata to the object. First you take the metadata value (in this case a string) and create a new VclMetadataStringValue object.

Recently I spent some time configuring vCloud Director metrics and storing them in a Cassandra cluster. If you have ever stepped outside of the default metrics and tried to provide your own via a Groovy file, you may have hit the following error in the cell-management-tool.log log: Invalid column name **metric** because it conflicts with an existing column If your Groovy file contains the metric listed in the error message and you’ve only listed it once, you’re probably thinking “where on earth is this duplicate coming from?

Have you got an NSX Manager that’s done the rounds for the past few years and served you well? Is it time for another upgrade but you’re stuck because the disk is full and you’ve been told: Cannot continue upgrade due to errors : Insufficient disk space. Database disk usage is at 87%, but it should be less than 70%. We recommend running a database full vacuum before proceeding with upgrade.