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 [email protected] - 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:

During some recent lab work, I deployed a fresh vRealize SaltStack Config 8.8 appliance in my lab and had it integrated with vRA and vIDM. On first login I found that my vIDM/vRA administrator (config admin) was unable to see the minions in SaltStack Config UI. After some trial and error and working with some others internally, I found the issue was related to the default permissions provided by the vRA IAM integration.

Cloud-Init and Hostnames First problem was Ubuntu 20.04 to properly boot from the Packer HTTP directory. I found approximately 3,125,319 blogs online all with different Ubuntu boot commands. I settled on this: boot_command = [ "c", "linux /casper/vmlinuz --- autoinstall ds=\"nocloud-net;seedfrom=http://{{.HTTPIP}}:{{.HTTPPort}}/\"", "<enter><wait>", "initrd /casper/initrd", "<enter><wait>", "boot<enter>" ] Next up was a working user-data file for the boot customisation process. I settled on a mish-mash of different examples found online: #cloud-config autoinstall: version: 1 early-commands: # Stop ssh for packer - sudo systemctl stop ssh locale: en_US keyboard: layout: en variant: us # general packages needed for machines - referenced from https://tekanaid.