Tag - VMware

This one had me stumped for a few minutes. A while ago I was working with a customer that was trying to boot into the EFI shell of a VM. Restarting into the EFI boot menu, they found the EFI shell option was missing: Turns out, you need power off the machine and disable Secure Boot in the VM’s Boot Options: From this To this Booting the machine you’ll find the EFI Shell:

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.

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.