I’ve had some partners ask for a reference that maps VCD, CSE, TKG images and TKr versions in a single table. Behold! The Cloud Director column details the VCD version, CSE details the version of CSE compatible with the VCD builds. TKG Images column lists the versions of Tanzu Kubernetes Grid images that are supported by CSE, and the Tanzu Kubernetes Release (TKr) column details the Kubernetes releases available for the TKG Images version in the list.

I’ve just hit the six month mark in my new role at VMware: Senior Cloud Solutions Architect - Service Providers. This role sees me working closely with a paired Business Development Manager, aligned to our VMware Cloud Provider Partners to design and build cloud platforms that highlight and expand on their unique offerings. It’s my first foray into the pre-sales world, and I’m loving it. I’ve really enjoyed talking to our partners, learning more about their businesses, and helping them map VMware solutions to their business objectives.

Recently I had a customer testing their vCenter Server 7.0U3e file-based restore process using the VCSA Restore Wizard. During Stage 2 (data copy) the wizard hung at 80% and did not progress for hours. No UI errors or hints as to what was happening. I had a look at the restore wizard logs and found the following: 2022-07-12T01:16:19.828Z - debug: [7]pollRpmInstallProgress:getGuestFileErr:ServerFaultCode: The object 'vim.VirtualMachine:103' has already been deleted or has not been completely created 2022-07-12T01:16:30.

My latest lab excapades required deploying some VMs into Azure using vRealize Automation. Before I did that though, I wanted to configure private network access between my Azure VNet and my lab network to support things like Domain Joining, Lab DNS lookups, SaltStack Config management, etc. My lab network is managed by a virtual PFSense appliance so this post will cover PFSense configuration too. The IPSec tunnel only needs to exist while I’m deploying and testing things.

While I was writing this post I had a step where I wanted to show a GIF of the operation. MacOS’ built-in screen capture was able to record a section of the screen for me as a Quicktime movie (.mov). For obvious reasons a GIF would be a lot simpler for a blog post, but there was no straight forward mechanism to do what I needed. A quick Google returned this Medium article describing a couple of utilities that can get the job done.

Over the years I’ve had many people ask me how I manage networking on my single host lab environment. “How do you do VLANs and manage routing/firewalling without a physical device providing that upstream?” they would ask. Well, I use a PFSense VM. Which would usually be followed up by “Yea but how?” VLAN trunking on my dvSwitch and sub-interfaces within PFSense. Easy stuff! Let’s review requirements first: Be able to define multiple VLANs and subnets.

While exploring vRealize Automation and SaltStack Config, I had the bright idea to expand the integrations across the vRealize Suite by automatically installing the vROPs Telegraf agent during a vRA Deployment. This would provide immediate guest OS monitoring and (optional) application monitoring to every machine deployed from vRA. What you’ll need: vRealize Automation 8.8 vRealize SaltStack Config 8.8 Integrated with vRealize Automation through either vRealize Suite Lifecycle Manager or as a standalone SaltStack instance.

If you’re ever in a position where you need to change the DNS settings on your VMware Identity Manager (vIDM) appliance, you may have noticed that vRealize Suite Lifecycle Manager (vRSLCM) doesn’t provide you with this mechanism. Luckily, the vIDM appliance itself contains “OVF Properties” within the vSphere UI. You can shutdown the appliance and modify these settings to allow the appliance network configuration to re-apply your new configurations to the guest.

I have a customer about to embark on a (relatively) large Cisco ACI upgrade, followed by a dvSwitch LACP update to Enhanced LACP. This includes updating ACI EPG policies to use the newly created LAG as the primary uplink port. Normally in the vSphere UI, you can view this per port group. But in an environment wth 12 vCenter Servers and 22 distributed switches (and a couple thousand port groups), that manual process can get out of hand pretty quick.

I was trying to install the vRealize Operations Telegraf agent on my VMs by following the documentation. I wrote the steps out in a Salt state file: unzip: pkg.installed install-telegraf: cmd.script: - source: https://cloudproxy.domain.tld/downloads/salt/download.sh - name: /tmp/download.sh -o install -v vrops.domain.tld -u admin -p p@ssw0rd - mode: '0777' Salt takes the source and puts it in the location under name, executing it with the included arguments. However, everytime it ran I would get this: