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.
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.
Resources:
VMSA-2021-0028: https://www.vmware.com/security/advisories/VMSA-2021-0028.html
FAQ: https://via.vmw.com/vmsa-2021-0028-faq
Unaffected VMware products can be referred to on the Knowledge Base article: https://kb.vmware.com/s/article/87068
VMware Blog “Investigating the Log4j Vulnerability”: https://blogs.vmware.com/security/2021/12/investigating-cve-2021-44228-log4shell-vulnerability.html
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
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.
Resources:
VMSA-2021-0020: https://www.vmware.com/security/advisories/VMSA-2021-0020.html
Workaround*: VMware KB 85717: https://kb.vmware.com/kb/85717
FAQ: https://via.vmw.com/vmsa-2021-0020-faq
VMware Blog “VMSA-2021-0020: What You Need to Know”: https://via.vmw.com/vmsa-2021-0020-blog
VMware Communities: https://via.vmw.com/vmsa-2021-0020-community
*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.
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)
vCommunity – Get involved on Twitter:
@vMiklm, @BhamVMUG, @myVMUG, @vExpert, @VMware
Video:
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:
config.vpxd.sso.admin.uri
This URL will contain the hostname of the PSC.
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 “vcenterserver.securednet.companynet.org” 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,
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