Before anyone gets in a huff, I’m not suggesting that a key part of VMware’s automation, orchestration and cloud functionality be consigned to the bin. This is about the name.
It was Q3 / Q4 last year (2014) that VMware announced the changes to its product names. A whole year ago! Of course, it can take time for a change to take effect, particularly when any of the following are a factor:
- Older projects and environments using older versions of the products that contain original branding
- Document, diagram and presentation re-use where the older names are used
- Investment in any other IP or collateral
- Ingrained habits, especially if you’ve been using these products for years
But by now “vCO” should be a thing of the past. That’s not its name anymore. I won’t be removing the tag from my blog but I’ll be making an effort not to use it anymore (after this post) and I’m going to remove the search from my Twitter client too:
New job. New laptop. But of course it isn’t set up like the old one. It doesn’t have all of the tweaks that I made over the years on it.
One annoyance, what with me being a heavy and frequent user of vRealize Orchestrator, is that client.jnlp files downloaded from the vRO web interface don’t have an application association by default. I’m writing this as a quick reference just in case I need it again anytime soon.
- Having downloaded and saved the client.jnlp file as normal, use the finder app to select the file, right click and select “Open with > Other…”.
- Browse to this path: /System/Library/CoreServices
- Select the executable Java-Web-Start.app
- Tick the “Always Open With” option.
- Click “Open”.
I’ve been a user of VMware’s products since finding VMware Workstation in the early noughties but things really took off for me in 2007 with ESX3. I’ve long thought that I might work for VMware one day if the circumstances were right. As of yesterday, it became a reality.
This has been mostly a sideways move for me as I have joined the Northern EMEA PSO team as an SDDC consultant. I’ll probably be working on similar projects to the ones I have been working on already. However, I believe that the opportunities within VMware for me at this stage of my career are significant. I’m excited by the prospects and keen to get stuck in.
One downside to this move is that I have had to step down as a co-leader of the South West UK VMUG chapter. It’s been a fantastic 2 years and we’ve organised some great meetings but the remaining leaders (Barry Coombs, Simon Eady and Jeremy Bowman) are more than equal to the task. (Although they almost stole my thunder!)
On the subject of VMUGs, a quick shout out for the next South West UK VMUG meeting on September 28th 2015. Register here. And although I can no longer have any sort of leadership role in VMUG meetings, I hope to still be presenting at them regularly.
Maybe my google foo is broken, but I couldn’t see any mention of this in VMware’s KB library. I’m trying to find out if it’s also an issue in vRA 6.2 too.
Edit 14/05/2015: I’m reliably informed that this is fixed in 6.2.
So, what’s the problem?
Well, I was demonstrating how it was possible to change the description of a VM in vCAC via the “Edit” resource action and how it would also result in the vCenter VM being updated.
So, with the description added, I hit Submit. The description is added to the Virtual Machine in vCAC and also vCenter. I then went to to demonstrate a custom action that executes a vRO workflow and was surprised when it failed and complained about the identity of the network being used.
A brief bit of head-scratching later, and I discovered that vCAC believed the VM to have no network interface:
The VM’s properties confirmed, that as far as vCAC was concerned, this VM was not connected to any network! However, looking at vCenter, the story was very different:
For anyone familiar with vCAC, the solution is easy. And, in fact, vCAC will fix the issue itself in under 24 hours. Forcing vCAC to refresh the vCenter inventory clears up the discrepancy:
Clearly an odd “feature” of the vCAC portal and I probably wouldn’t even have noticed it but for using the same VM for a particular resource action that needed the VM’s network properties.
It’s been some time since I posted anything on this site (over 4 months in fact). There could be any number of reasons I could come up with as to why that is. The truth though is that I’ve had my head down on a large cloud project (lots of vRO and vRA) for the last 6 months and a great many things have taken a back seat to it.
Whilst the project isn’t over yet, I did manage to have some much needed time off recently and have been catching up a bit since. Part of that catching up involves cherry-picking from the long list of articles that I wanted to / started to write and getting them out of the door.
(In case you were wondering about the title of this post, I heard this song on the way to work and the name sort of fit, even if the rest of the lyrics don’t.)
Ladies and gentlemen, start your downloads!
vRealize Automation 6.2 (formerly known as vCloud Automation Center) has gone GA today. Beside the usual raft of fixes, the major focus for this release is the integration with vRealize Operations 6.0 (formerly known as vCenter Operations Manager).
Download VMware vRealize Automation 6.2
Also updated to download are:
And finally, all new and shiny is vRealize Code Stream. This, I am really looking forward to as it’s aimed at providing continuous delivery of software releases. And that could include vCO (I mean vRealize Orchestrator) workflows – something I’m doing a lot of at the moment.