Browsed by
Tag: vcenter

vSphere 8!

vSphere 8!

vSphere 8 is GA!

VMware has a great landing page that goes into details on all the new features and functionality.

The new DPU functionality, with the ability to offload network services, is a great advancement. How will this change how you architect future datacenters? When combined with the vSAN 8 Express Storage Architecture, there are many opportunities for optimization with next-gen hardware.

VMSA-2021-0028: Critical VMware Security Advisory (Multiple Products; Apache Log4j Vulnerability)

VMSA-2021-0028: Critical VMware Security Advisory (Multiple Products; Apache Log4j Vulnerability)

On Friday, December 10, 2021, VMware released VMware Security Advisory VMSA-2021-0028 affecting numerous VMware products including vCenter Server. This advisory is re: Apache Log4j vulnerability CVE-2021-44228 with a CVSSv3 score of 10 out of 10.


Unaffected VMware products can be referred to on the Knowledge Base article:
VMware Blog “Investigating the Log4j Vulnerability”:

The key takeaway is that IMMEDIATE ACTION IS REQUIRED. Workaround should be applied to all running products immediately.

This is being actively exploited in the wild, and should be treated as an emergency change with highest priority.

This vulnerability is in the open-source Apache Log4j Java logging library, which is used in numerous software packages. This is not a VMware-specific issue.

Additional background information:
Tech Solvency Log4Shell log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

VMSA-2021-0020: Critical vCenter Server Security Advisory

VMSA-2021-0020: Critical vCenter Server Security Advisory

On Tuesday, September 21, 2021, VMware released VMware Security Advisory VMSA-2021-0020 affecting vCenter Server. This VMSA contains 1 Critical advisory and 18 Important advisories.


Workaround*: VMware KB 85717:
VMware Blog “VMSA-2021-0020: What You Need to Know”:
VMware Communities:

*Workaround provided only for 1 Critical vulnerability. Additional 18 lower vulnerabilities require patch to be applied. Workaround should only be used as a temporary measure until patching can be completed. Refer to FAQ for additional information.

The key information to share is that IMMEDIATE ACTION IS REQUIRED. Apply the vCenter patch version now, or apply the workaround (and understand the impact to functionality) if you cannot patch immediately.

VMware has released a very detailed blog and FAQ for this VMSA, which should help clarify questions that are sure to arise. These resources are linked above.

Birmingham AL VMUG Meeting – December 2018

Birmingham AL VMUG Meeting – December 2018

Presentation resources:

VMware Product Interoperability Matrices

vCenter Server 6.7 Update 1 Release Notes

ESXi 6.7 Update 1 Release Notes

vSAN 6.7 Update 1 Release Notes

Upgrade Considerations for VMware vSphere 6.7 (VMware vSphere Blog)

What’s New in Performance – VMware vSphere 6.7 (PDF)

VMware Design Studio

vCommunity – Get involved on Twitter:

@vMiklm, @BhamVMUG, @myVMUG, @vExpert, @VMware



Find vCenter PSC

Find vCenter PSC

Often it is necessary to determine the PSC a vCenter server is pointed to.  Is it an external PSC or an internal PSC?

In vSphere client, look at the vCenter Advanced Settings. Find the setting:


This URL will contain the hostname of the PSC.

VCSA – Moving Behind A Firewall

VCSA – Moving Behind A Firewall

We have a situation where we have to deploy VMware vCenter Server Appliance (VCSA), then move it to a secured network behind a firewall.

I have not (yet) had success changing the hostname, including the FQDN, so make sure you can create proper DNS entries on both sides of the firewall and can do the initial deployment with the intended final FQDN. Our VCSA’s FQDN is of the format “” so this was achievable (the segmented domain is a subdomain of the company domain)

Deploy the appliance, then access the VCSA console and press F2, then login as root. At this point you may also need to Edit the VM Settings and change it to the new network (behind the firewall, in my case).
– Configure Management Network
– Set IP Configuration, IPv6 Configuration, DNS Configuration, Custom DNS Suffixes as required.
– (Esc) Exit, (Y) Yes Apply changes and restart management network

At this point, I got the following 2 screens. IPv6 is understandable; we disabled it. The DNS error appears even though we have validated the DNS entries/servers.

Now, to access the shell console. Login as root.

Command> shell.set --enabled True
Command> shell
# vi /etc/sysconfig/networking/devices/ifcfg-eth0

Quick vi reminder: hit (Insert) to edit the line, then (Esc), :wq! to save and exit.

Make sure all the IP information is correct in this file. I had to update the broadcast & gateway for sure. Then,

# vi /etc/hosts

Fix the entry here to reflect the new IP.

Validate settings:

# ifconfig eth0
# route -n

At this point, we were missing the default gateway in the route table, even thought it was defined in the ifcfg-eth0 file and in the IP Configuration screen of the console. Also the Broadcast address still reflects the old network, but this is less of a problem.

To temporarily fix the default gateway, do # route add default gateway XXX.YYY.ZZZ.1, using the correct gateway IP obviously.

To permanently resolve the gateway issue, log into the web console (https://vcenterserver:443/vsphere-client/) as Administrator@vsphere.local or whatever you defined as your SSO domain.
– Go to System Configuration under Administration in the main panel
– Nodes (in left column, under System Configuration)
– Select your vCenter server under Nodes
– “Edit” in the upper right corner of the main panel
– Expand nic0 & define Default gateway
– Ok
– Reboot to validate configuration persists