Tag: 8.0

ESXi 8.0 ESXCLI Command Reference

Microsoft Secure Boot Certificate Expiration in vSphere VMs (KB 423893): What to Do in 2026

Microsoft KEK and UEFI CA 2011 expired in June 2026. What it means for vSphere VMs with Secure Boot, and how SilentPK (8.0 U3j) and Capsule PK (9.1.1) fix it.

The Microsoft KEK CA 2011 and UEFI CA 2011 certificates expired in June 2026, and Windows Production PCA 2011 expires in October 2026. vSphere VMs with UEFI Secure Boot keep booting, but VMs without the Microsoft 2023 certificates can’t take future Secure Boot database updates. The fix is two steps: update the VM’s Platform Key (PK) first, using SilentPK on ESXi 8.0 U3j (P09) and later or Capsule PK on ESX 9.1.1.0 for Windows VMs with vTPM, then update KEK and DB through the guest OS vendor. Broadcom KB 423893 is the source of truth and was last updated on 2 September 2026.

Which Microsoft certificates expire, and when

CertificateExpires
Microsoft Corporation KEK CA 2011June 2026
Microsoft Corporation UEFI CA 2011June 2026
Microsoft Windows Production PCA 2011October 2026

What happens to VMs after the certificates expire

The VMs continue to boot. The impact is that a VM whose KEK and DB don’t contain the Microsoft 2023 certificates can’t apply future Secure Boot database updates, which can block Secure Boot-related security updates in the guest. Guest OS updates that don’t depend on these databases keep working.

Which VMs are affected

  • VM hardware version 13 or newer (Secure Boot starts at version 13)
  • UEFI Secure Boot enabled
  • KEK and DB without the Microsoft 2023 certificates: typically VMs on hardware version 13, VMs created on ESXi hosts earlier than 8.0 U2, or VMs deployed from templates that carry an old NVRAM

VMs on hardware version 13 need an upgrade to version 14 or later before their PK can be updated.

How to find affected VMs

  • Fleet-wide: KB 423893 attaches PowerCLI scripts (SecureBootExportVMList.ps1, SecureBootExportVMListv2.ps1) that export Secure Boot and vTPM status for all VMs.
  • Inside a Windows guest: Get-SecureBootUEFI -Name PK
  • Inside a Linux guest: mokutil --pk
  • vCenter and ESX 9.1.1.0: the alarm “Virtual Machine UEFI Secure Boot Platform Key is out of date. Refer KB 423893” flags affected VMs.

Remediation by ESXi version: 8.0 U3j (P09), 9.0 and 9.1.1

Secure BootvTPMESX 7.x, ESXi 8.0 U3i (P08) and earlierESXi 8.0 U3j (P09)ESX 9.0.x / 9.1.0ESX 9.1.1.0 and later
DisabledDisabledNo actionSilentPK update (optional)SilentPK update (optional)SilentPK update (optional)
EnabledDisabledManual update from the vUEFI interfaceSilentPK updateSilentPK updateSilentPK update
EnabledEnabledManual update from the vUEFI interfaceManual update from VMX configuration (preferred for non-Windows VMs)Manual update from VMX configuration (non-Windows VMs)Capsule PK update (Windows) / manual VMX update (non-Windows)
DisabledEnabledNo actionNo actionNo actionNo action

Source: KB 423893, as of its 2 September 2026 update. ESX 7.x gets only the manual vUEFI method; no automated fix is planned for it.

SilentPK vs Capsule PK

  • SilentPK update (ESXi 8.0 U3j and later): the hypervisor adds the missing Windows OEM Devices PK certificate automatically during a guest reboot or VM power cycle. No guest OS action is needed. It is used for VMs without vTPM.
  • Capsule PK update (ESX 9.1.1.0 and later, Windows): an OS-coordinated firmware update that changes the PK during a guest reboot while preserving vTPM measurements, so BitLocker and other vTPM-dependent features don’t lock you out. It requires VMware Tools 13.1.5 or later and the July 2026 Windows cumulative update (earlier for Windows Server 2025 and Windows 11 24H2/25H2).

The order that matters

  1. Patch hosts to ESXi 8.0 U3j (P09), or to ESX 9.1.1.0 if you have Windows VMs with vTPM.
  2. Update the Platform Key first, with SilentPK, Capsule PK or the manual method from the table.
  3. Then update KEK and DB following the guest OS vendor’s guidance.

Related: this article is about guest (VM) Secure Boot. For host-level Secure Boot on Cisco UCS, see how to run the Secure Boot validation script on an ESXi host.

Support for nConnect Feature Added in ESXi NFS Client

Use nConnect in ESXi 8.0 U1+ for several TCP connections per NFSv3 datastore: esxcli syntax, limits (4/8/256), runtime changes in 8.0 U2 and how to check.

Short answer: since ESXi 8.0 Update 1 the NFS client supports nConnect: several TCP connections per NFSv3 datastore. Mount with esxcli storage nfs add ... -c <connections> (default 1, up to 4 per datastore, or 8 with /NFS/MaxConnectionsPerDatastore, and 256 per host in total). Since 8.0 Update 2 you can change it on a mounted datastore with esxcli storage nfs param set -v <label> -c <n>. It’s NFSv3 only and CLI only.

With the release of VMware ESXi 8.0 Update 1, VMware quietly introduced nConnect support in the NFS client — a long-awaited enhancement for environments using NFSv3 datastores.

The nConnect feature allows administrators to establish multiple parallel TCP connections per NFS datastore, significantly improving throughput, resiliency, and traffic isolation.

This guide walks you through how to configure nConnect, supported versions, and key operational tips.

🆕 What’s New in ESXi 8.0U1

From ESXi 8.0U1 onwards, a new parameter -c (number of connections) is available in esxcli when mounting NFSv3 datastores.

esxcli storage nfs add \
  -H <host> \
  -v <volume-label> \
  -s <remote_share> \
  -c <number_of_connections>

Key points:

  • Supported for NFSv3 only (NFSv4.1 not yet supported).
  • Currently available only via CLI, not via vCenter UI.
  • Host Profiles don’t officially support it yet (though there’s a workaround, see below).
  • Default max connections per datastore: 4
  • Adjustable up to 8 connections via advanced option:
esxcfg-advcfg -s 8 /NFS/MaxConnectionsPerDatastore

⚠️ The total number of connections across all mounted NFSv3 datastores is capped at 256.

Runtime Scaling in ESXi 8.0U2

The nConnect feature got a useful upgrade in VMware ESXi 8.0 Update 2.
You can now increase or decrease the number of TCP connections on an existing NFSv3 mount without unmounting the datastore:

esxcli storage nfs param set \
  -v <volume-label> \
  -c <number_of_connections>

This flexibility helps admins fine-tune NFS performance on the fly — for example, ramping up connections during heavy backup windows or scaling down during low I/O periods.

Note: In both 8.0U1 and 8.0U2, the default number of connections remains 1.

How to Check Active NFS Connections

To view the number of RPC clients currently used by mounted NFSv3 datastores, run:

vsish -e get /vmkModules/nfsclient/info

Sample output:

NFS Connections Info {
mountedVolumes:10
totalConnections 40
}

This command is particularly handy for performance troubleshooting and capacity planning.

🧪 Experimental: Host Profile Integration

Although official Host Profile support for nConnect is not yet released, VMware added an experimental field named “Number of TCP connections” in:

Host Profile → Storage Configuration → NFS

What it does:
When you set a value here, ESXi will use that number of parallel TCP sessions when mounting the NFS datastore during profile remediation.

This is ideal for consistent deployment across multiple hosts in larger clusters.

Best Practices & Tips

  • Start with 4 connections and scale up as needed after performance testing.
  • Keep the 256 connection limit in mind when mounting multiple datastores.
  • Use consistent configuration across hosts to avoid mount mismatches.
  • Monitor performance metrics via VMware vSphere or CLI.
  • If you’re using Host Profiles, experiment carefully with the TCP connection parameter.

Summary

The nConnect feature in ESXi’s NFS client marks a major step forward in improving NFSv3 performance and scalability in enterprise environments.

Whether you’re running backup workloads, large VMs, or latency-sensitive applications, multiple TCP connections per NFS datastore can make a measurable difference.

If you’re upgrading to VMware ESXi 8.0U1 or later, nConnect is worth testing and adopting in your storage strategy.

Links

lsdoctor: Check and Repair the vCenter Lookup Service (6.7 to 9.x)

Broadcom lsdoctor for vCenter 6.7-9.x: where to download it (KB 320837), how to run it safely, and which option fixes which Lookup Service problem.

lsdoctor (Lookup Service Doctor, lsdoctor.py) is Broadcom’s script for checking and repairing the vCenter Lookup Service: stale registrations, SSL trust mismatches, solution users and broken service registrations. The current build is lsdoctor-260716 (July 2026) and it supports vCenter 6.7 and later, including 7.x, 8.x and 9.x. Download it only from Broadcom KB 320837, take offline snapshots of every node in the SSO domain, and always start with the read-only --lscheck.

If the problem is an expired or mismatched certificate rather than the Lookup Service itself, check and replace certificates with vCert first.

lsdoctor at a glance

Current buildlsdoctor-260716.zip, added 16 Jul 2026 (always take the latest attachment from KB 320837)
SupportedvCenter Server 6.7 and later, VCSA or Windows-based, including 7.x, 8.x and 9.x. Support for the newest builds can lag behind a vCenter release.
DownloadOnly from Broadcom KB 320837. Verify the SHA256 listed in the KB.
Where to run itMost options run on any node in the same SSO site as the affected node. --stalefix and --solutionusers run on the affected node itself.
OutputFindings per node, shown as SSO site plus hostname/PNID, and the path to a JSON report
Safe first step--lscheck makes no changes

Before you run lsdoctor

  • Take offline snapshots of the whole SSO domain. KB 320837 is explicit: shut down all vCenter Servers and PSCs in the SSO domain at the same time, snapshot them, then power them on again. If you need to roll back, shut them all down and revert them together, otherwise replication between nodes breaks.
  • Pick the right node. Run checks from a node in the same SSO site as the one with the problem. For --stalefix and --solutionusers, log in to the affected node.
  • Check for a custom login banner. lsdoctor reads the vCenter version from /etc/issue. A custom banner makes it fail with IndexError: list index out of range (see fixing lsdoctor’s IndexError on 8.0.3).
  • Plan for follow-up work. Every option except --lscheck ends with a service restart, and most require re-registering external solutions such as backup, storage or monitoring plugins.

Download and install lsdoctor

Download the zip from KB 320837 and copy it to the node, for example with WinSCP. If WinSCP can’t connect to the appliance, set root’s login shell to bash first (chsh -s /bin/bash root). On the VCSA:

# cd /root
# sha256sum lsdoctor-260716.zip      # compare with the SHA256 in KB 320837
# unzip lsdoctor-260716.zip
# cd lsdoctor-*
# python lsdoctor.py --help

Always run lsdoctor from the extracted directory. On a Windows-based vCenter 6.7, extract the zip with Extract All, then run it with the bundled Python:

cd "C:\Program Files\VMware\vCenter Server\python"
.\python.exe <path_to_lsdoctor.py> <option>

lsdoctor options

OptionWhat it doesRun onFollow-up
-l, --lscheckChecks for common Lookup Service issues. Makes no changes.Any node in the SSO siteReview the output and the JSON report; it tells you which fix applies
-t, --trustfixCorrects SSL trust mismatches in the Lookup ServiceAny node in the SSO siteRestart services on all nodes in the SSO site; re-register external solutions
-s, --stalefixCleans up stale configuration left over from systems upgraded from 5.xThe affected nodeRestart all services; re-register external solutions
-u, --solutionusersRecreates the solution users for a nodeThe affected nodeRestart services on that node
-r, --rebuildRebuilds one or all service registrations for a nodeAny node in the SSO siteRestart services; re-register external solutions
-p, --pscHaUnconfigureRemoves a PSC High Availability (load balancer) configurationSee KB 320837Restart services on all PSCs; repoint vCenter; re-register external solutions

--rebuild uses registration templates that match your vCenter build. If lsdoctor has no template for your exact build, it asks you to pick the closest one. It also keeps automatic backups of the registrations it changes, and the same menu can restore them.

Which lsdoctor option for which problem

What you seeStart withThen
Upgrade, patch or repoint pre-checks fail with Lookup Service or registration errors--lscheckThe fix it recommends (usually --trustfix, --stalefix or --rebuild)
Plugins or solutions fail after replacing the Machine SSL certificate; certificate mismatch in Lookup Service registrations--lscheck--trustfix, or vCert option 4 (Manage SSL trust anchors)
Leftover registrations from a vCenter upgraded from 5.x--lscheck--stalefix on the affected node
Solution user errors on one node--lscheck--solutionusers on that node
Missing or broken service registrations--lscheck--rebuild
Retiring a PSC HA load balancer–--pscHaUnconfigure, then repoint vCenter
lsdoctor itself fails with IndexError: list index out of rangeCheck /etc/issueRestore the default banner temporarily

lsdoctor vs vCert

ToolFixesUse it when
lsdoctorLookup Service data: registrations, trust in registrations, solution users, stale entriesServices can’t find or trust each other, or upgrades fail on registration checks
vCertThe certificates themselves: Machine SSL, Solution Users, STS, VMCA, ESXi, trust anchorsCertificates are expired, expiring or replaced, or you see no healthy upstream after an expiry

The two overlap on trust anchors. A common sequence is: fix the certificates with vCert, then run lsdoctor --lscheck to confirm the Lookup Service registrations trust the new certificate.

Related vCenter guides

Full reference: Broadcom KB 320837 – Using the lsdoctor tool.

Critical Security Alert: Update to Fixed Version 8.0 U3d Immediately

CVE-2024-38812 is a CVSS 9.8 vCenter RCE exploited in the wild. Versions before 8.0 U3d and 7.0 U3t are affected: patch steps with software-packages.

Urgent Notice from VMware by Broadcom

Short answer: CVE-2024-38812 (CVSS 9.8, a heap overflow in vCenter’s DCERPC implementation) and CVE-2024-38813 are covered by VMSA-2024-0019. All vCenter versions before 8.0 U3d and 7.0 U3t are affected, the September 2024 patches were incomplete, and Broadcom confirmed exploitation in the wild in November 2024. If you are still below those builds, patch now, and always take the latest build from the advisory’s Response Matrix.

VMware has announced that the security patches released on September 17, 2024, intended to address CVE-2024-38812, did not fully mitigate the vulnerability. As a result, all customers are strongly advised to update to the latest version, 8.0 U3d, immediately. Patches for the 8.0 U2 line are also available to address this issue.

This urgent advisory applies to all vCenter Server users, as the newly identified vulnerabilities pose a significant security risk. Notably, two critical vulnerabilities were reported in vCenter Server, including a heap-overflow vulnerability and a privilege escalation vulnerability. These have been responsibly reported to VMware, which has now provided updates to address them.

Key Vulnerability: Heap-Overflow in vCenter Server (CVE-2024-38812)

Vulnerability Description:

A critical heap-overflow vulnerability was discovered in vCenter Server, specifically in its implementation of the DCERPC protocol. The issue has been assigned CVE-2024-38812 and carries a CVSSv3 base score of 9.8, placing it in the Critical severity range.

Known Attack Vectors:

This vulnerability can be exploited by a malicious actor who has network access to the vCenter Server. By sending a specially crafted network packet, the attacker could trigger the heap-overflow, potentially leading to remote code execution (RCE) on the affected system.

Why You Should Patch Now

This vulnerability could allow attackers to gain control over your vCenter Server environment, putting your infrastructure at risk for unauthorized access, data breaches, or service disruptions. Given the widespread use of vCenter Server for managing virtual environments, this threat is extremely serious, especially for businesses relying on VMware for critical operations.

Patch Availability

The new patches, which can be found in the Response Matrix, have been made available for both the 8.0 U3, 8.0 U2 and 7.0 U3 versions of vCenter Server. Customers should apply the new patches immediately to ensure their systems are protected.

What to Do:

  1. Check your version: Identify if your vCenter Server version is affected.
  2. Apply the patches: Use the Response Matrix provided by VMware to download and install the necessary updates.
  3. Follow VMware’s best practices: Regularly update your systems, review security advisories, and apply patches as soon as they are released to minimize security risks.

Mount VMware-vCenter-Server-Appliance-8.0.3.00400-24322831-patch-FP.iso to VCSA VM. Log in to the appliance shell as a user with super administrative privileges (for example, root) and run the following commands:

# To stage the ISO:
software-packages stage --iso

# To see the staged content:
software-packages list --staged

# To install the staged rpms:
software-packages install --staged

vCenter 8 Session Timeout Settings and the 8.0 U3b vSphere Client Idle Session Bug (Fixed in 8.0 U3c)

How to set the vSphere Client session timeout in vCenter 8.0 and 9.x, and why sessions broke after 50 idle minutes on 8.0 U3b until the 8.0 U3c fix.

Short answer: In vCenter 8.0, the vSphere Client session timeout is set in Administration > Deployment > Client Configuration > Edit > Session timeout (minutes, default 120). Alternatively, set session.timeout in /etc/vmware/vsphere-ui/webclient.properties. If sessions die after about 50 idle minutes on vCenter 8.0 U3b (8.0.3.00200), that is a Tomcat bug, not a setting. It is fixed in 8.0 U3c (build 24305161) and later.

vCenter 8 session timeout settings (vSphere Client)

By default, vSphere Client sessions close after 120 minutes of inactivity. You need the Global > Settings privilege to change it.

  1. In the vSphere Client Home menu, select Administration.
  2. Under Deployment, click Client Configuration.
  3. Click Edit. The Edit client configuration dialog opens.
  4. Enter the new value in minutes in Session timeout and click Save.
  5. Log in to the vSphere Client again for the change to take effect.

Alternative: webclient.properties

The same value lives in the vSphere Client properties file on the appliance. The file method is documented for vSphere 7.0 and 9.1:

# /etc/vmware/vsphere-ui/webclient.properties
session.timeout = 60

# apply
service-control --restart vsphere-ui

Uncomment the line if needed. The value is in minutes. The documentation says that a negative value or 0 means the client never times out. That is convenient in a lab but a bad idea in production. The vSphere Security guide recommends setting timeouts so that idle sessions cannot be misused.

vCenter 9 session timeout

The vSphere 9.1 documentation keeps both methods: Home > Administration > Deployment > Client Configuration > Edit, or session.timeout in /etc/vmware/vsphere-ui/webclient.properties. Default is still 120 minutes. After the change, restart the VMware vSphere Client service. Use service-control --restart vsphere-ui over SSH, or VAMI (https://<vcenter>:5480) > Services > VMware vSphere Client > Restart.

VersionUI pathFileApply
vCenter 8.0Administration > Deployment > Client Configurationwebclient.properties (session.timeout)Re-login (UI); restart vsphere-ui (file)
vCenter 9.xAdministration > Deployment > Client Configuration/etc/vmware/vsphere-ui/webclient.propertiesRestart VMware vSphere Client service

What went wrong in vCenter 8.0 U3b (8.0.3.00200)

vCenter Server 8.0 Update 3b (17 Sep 2024, build 24262322, patch VMware-vCenter-Server-Appliance-8.0.3.00200-24262322-patch-FP.iso) upgraded Apache Tomcat to 9.0.91. That Tomcat version changed the default of org.apache.catalina.connector.RECYCLE_FACADES from FALSE to TRUE. As a result, a vSphere Client session left idle for more than 50 minutes became invalid (PR 3439359). You could not log in or out, or use the client in that browser, until you cleared all cookies.

Symptoms listed in Broadcom KB 377734, usually after 1 to 2 idle hours:

  • The loading circle keeps spinning, and session timeouts occur.
  • Inventory errors: You have no privileges to view this object or it is deleted.
  • The login button is greyed out, or login fails with An error occurred while fetching identity providers.
  • ServiceClosedException: AsyncTokenProvider has been closed in /var/log/vmware/vsphere-ui/vsphere_client_virgo.log and /var/log/vmware/apig/apigw.log.

Raising the session timeout does not help here. The session breaks because of the Tomcat change, not because the configured timeout expires.

The fix: vCenter 8.0 U3c or later

vCenter Server 8.0 Update 3c (09 Oct 2024, ISO build 24305161, patch VMware-vCenter-Server-Appliance-8.0.3.00300-24305161-patch-FP.iso) contains only this fix (PR 3439359). Any later 8.0 U3 patch also includes it. Download the patch from the Broadcom Support Portal; this requires a login with an entitled account. If you patch now, go straight to the latest 8.0 U3 build rather than to U3c.

Workaround for 8.0 U3b (KB 377734)

If you cannot patch yet, disable RECYCLE_FACADES for the vSphere Client. SSH to vCenter as root:

root@vcsa-home [ ~ ]# cp /usr/lib/vmware-vsphere-ui/server/conf/catalina.properties /root/catalina.properties.bak

root@vcsa-home [ ~ ]# echo "org.apache.catalina.connector.RECYCLE_FACADES=false" >> /usr/lib/vmware-vsphere-ui/server/conf/catalina.properties

root@vcsa-home [ ~ ]# service-control --restart vsphere-ui

I ran exactly this on my home lab vCenter before 8.0 U3c was out. It only restarts the vSphere Client service.

Same symptoms on a newer build?

KB 377734 says that if you see this behaviour on a later version, you should hide third-party client plug-ins to find the cause. Go to Administration > Solutions > Client Plugins, select the third-party plug-in and click HIDE. This removes the plug-in’s UI extensions while its service keeps running.

Sources

Related on vdan.cz

Intel Skylake and ESX 9: Skylake-SP Supported in Deprecated Mode for VCF 9.x, Not Beyond

Is Intel Skylake supported in ESX 9? Skylake-SP runs in Deprecated mode for all VCF 9.x (KB 428874), not beyond. Skylake-W stays discontinued.

Illustration of an Intel Skylake server CPU reaching end of support in vSphere

Short answer: Yes, with limits. Broadcom KB 428874 was updated on 18 September 2026. Intel Skylake-SP (Xeon Scalable 1st generation: Platinum 8100, Gold 6100/5100, Silver 4100, Bronze 3100) is now supported in Deprecated mode for all of VCF 9.x, including 9.0 GA. Support depends on BCG listing and OEM hardware support. It will not be extended beyond 9.x. Skylake-W (Xeon W-2100) remains discontinued.

This post covers Skylake specifically. For the general installer warning (“may not be supported in future ESXi releases”) and the full CPU tables, see KB 82794 explained.

Intel Skylake ESXi 9 support at a glance

Skylake variantBCG CPU seriesCPU Info / CPUIDKB 318697 status for 9.x
Skylake-SPXeon Platinum 8100, Gold 6100/5100, Silver 4100, Bronze 31006.55.4 / 0x00050654See KB 428874: Deprecated mode for VCF 9.x
Skylake-DXeon D-21006.55.4 / 0x00050654See KB 428874
Skylake-SXeon E3-1200-v5, E3-1500-v56.5E.3 / 0x000506E3See KB 428874
Skylake-WXeon W-21006.55.4 / 0x00050654Discontinued

Note: the text of KB 428874 names only Skylake-SP explicitly. KB 318697 points the Skylake-D and Skylake-S rows to it as well. If you run Xeon D-2100 or E3 v5 systems, check the BCG listing for your exact server model. The other VCF 9 hardware checks (I/O devices, deprecated drivers, vSAN ESA) are in How to check VCF 9 hardware compatibility.

How Skylake support changed from vSphere 8 to VCF 9.x

  • vSphere 8.x: Skylake was on the deprecation list. The ESXi 8 installer warned that the CPU may not be supported in future releases, and installation continued. The original version of this post (October 2024) covered that stage.
  • VCF 9.0 GA: Skylake-SP was discontinued and not listed in the BCG for 9.0. In February 2026, Broadcom’s VCF blog still said Skylake needed an RPQ, with “VCF Software Only” support on approval.
  • KB 428874, 4 July 2026: the KB added Skylake-SP support for VCF 9.1.x.
  • KB 428874, 18 September 2026: support was expanded to VCF 9.x, including 9.0 GA. No TQ/RPQ is required for certain OEM server models marked “VCF Supported. Confirm w/ Vendor”.

Advice from older posts and forums, such as “Skylake does not install on ESX 9” or “file an RPQ”, may be out of date. Check the KB’s update date before you decide.

What Deprecated mode means for an Intel Skylake server

  • Deprecated means still supported. Per KB 318697, the CPU series is supported through the life of the VCF release, its updates and patches, or until End of General Support.
  • The OEM must list the server model in the Broadcom Compatibility Guide. KB 428874 links a BCG search for Skylake systems marked “VCF Supported. Confirm w/Vendor” on ESXi 9.0 and 9.1.
  • “VCF Supported. Confirm w/Vendor” means no further system-level driver enhancements and best-effort fixes or workarounds for the VCF software only.
  • Hardware, BIOS, firmware and microcode support comes from the server OEM and Intel under your contract with them. If you have no such support, you carry the risk.
  • vSAN OSA and ESA ReadyNodes with Skylake-SP are also in Deprecated mode and still supported.

Installing or upgrading ESX 9 on Skylake-SP

KB 428874 says the specific install and upgrade paths for VCF 9.x are described in its attached document, ESX_9.x_Install_Upgrade_using_OVERRIDE_on_Skylake_CPU_based_Servers-v1.3-09182026.pdf. Download it from the KB page and follow it for your path (fresh install, ESX upgrade, or a VCF-managed upgrade). I have not reproduced its steps here because they are versioned and still changing. This is Broadcom’s supported procedure. Don’t confuse it with the unsupported homelab boot option allowLegacyCPU=true.

Is it Skylake or Cascade Lake? Check the stepping

Skylake-SP and Cascade Lake-SP use the same family and model (hex 6.55, decimal model 85). Only the stepping tells them apart: 4 is Skylake-SP, and 6 or 7 is Cascade Lake. Cascade Lake is Deprecated in 9.x and listed as Discontinued for the next major release.

esxcli hardware cpu list
# look at: Brand, Family, Model, Stepping (decimal values)
# Family 6, Model 85, Stepping 4    -> Skylake-SP (6.55.4)
# Family 6, Model 85, Stepping 6/7  -> Cascade Lake (6.55.6 / 6.55.7)

What happens after 9.x

KB 428874 is explicit: Skylake-SP support will not be extended to VCF releases beyond 9.x. In KB 318697’s definitions, a “future major release” is the release after the 9.x series. The same table lists Cascade Lake, AMD EPYC 7001 (Naples) and 7002 (Rome), Coffee Lake Xeon E-2100/E-2200 and Atom C3000 as discontinued in that release. For planning:

  1. Inventory hosts by CPU stepping, not only by server model.
  2. Treat Skylake-SP hosts as “last stop: VCF 9.x” and track the 9.x End of General Support date in the Broadcom Product Lifecycle Matrix.
  3. Confirm OEM hardware and firmware support for the remaining lifetime. KB 428874 puts this responsibility on the OEM and Intel.
  4. Plan the refresh so the cluster does not block the next major upgrade. Avoid mixing in new Cascade Lake purchases, which hit the same wall.

Sources

Related on vdan.cz

vSphere Client Instability After vCenter 8.0.3.00200 (8.0 U3b): Moved

This note moved. The full article covers the vCenter 8.0 U3b idle session bug, KB 377734, the 8.0 U3c fix and vCenter session timeout settings.

This note has been merged into a single, updated article.

After upgrading to vCenter Server 8.0.3.00200 (8.0 Update 3b), the vSphere Client could become unresponsive after a long idle period. The cause was a changed Tomcat default (RECYCLE_FACADES), described in Broadcom KB 377734. It is fixed in vCenter 8.0 Update 3c and later.

The full article covers the symptoms, the KB workaround, the fixed builds and how to set the vSphere Client session timeout in vCenter 8.0 and 9.x:

vCenter 8 Session Timeout Settings and the 8.0 U3b vSphere Client Idle Session Bug (Fixed in 8.0 U3c)

VMSA-2024-0019: Critical VMware vCenter Server Vulnerabilities (CVE-2024-38812, CVE-2024-38813) Addressed

VMSA-2024-0019 covers vCenter heap-overflow CVE-2024-38812 and privilege escalation CVE-2024-38813. Affected versions and fixed builds (8.0 U3d, 7.0 U3t).

VMware has released an important security advisory, VMSA-2024-0019, detailing updates for VMware vCenter Server that address two significant vulnerabilities: a heap-overflow vulnerability (CVE-2024-38812) and a privilege escalation vulnerability (CVE-2024-38813). Both of these vulnerabilities could have severe implications if exploited, making it crucial for administrators to apply the necessary patches promptly.

Heap-Overflow Vulnerability (CVE-2024-38812)

Description: The first vulnerability, identified as CVE-2024-38812, is a heap-overflow vulnerability found in the vCenter Server’s implementation of the DCERPC protocol. This issue has been classified by VMware as Critical, with a maximum CVSSv3 base score of 9.8, indicating the potential for severe impact.

Known Attack Vectors: A malicious actor with network access to the vCenter Server can exploit this vulnerability by sending a specially crafted network packet. Successful exploitation could lead to remote code execution (RCE), allowing the attacker to execute arbitrary code on the vCenter Server with potentially full system privileges. This level of access could be used to disrupt services, exfiltrate sensitive data, or further compromise the virtual environment.

Privilege Escalation Vulnerability (CVE-2024-38813)

Description: The second vulnerability, CVE-2024-38813, is a privilege escalation flaw within the vCenter Server. VMware has rated this issue as Important, with a CVSSv3 base score of 7.5. While not as severe as the heap-overflow vulnerability, it still poses a significant risk.

Known Attack Vectors: An attacker with network access to the vCenter Server can exploit this vulnerability by sending a specially crafted network packet. If successful, the attacker could escalate their privileges to root, gaining full administrative control over the vCenter Server. This level of access could enable the attacker to make unauthorized changes, access sensitive information, or disrupt the entire virtual infrastructure.

More info VMSA-2024-0019:VMware vCenter Server updates address heap-overflow and privilege escalation vulnerabilities (CVE-2024-38812, CVE-2024-38813)

Add nConnect Support to NFS v4.1

vSphere 8.0 Update 3 adds nConnect for NFS v4.1 datastores: multiple connections per session on one IP, extending session trunking.

Starting with vSphere 8.0 Update 3, nConnect support has been added for NFS v4.1 datastores. This feature enables multiple connections using a single IP address within a session, thereby extending session trunking functionality to that IP. With nConnect, multipathing and nConnect coexist, allowing for more flexible and efficient network configurations.

Benefits of nConnect

Traditionally, vSphere NFSv4.1 implementations create a single TCP/IP connection from each host to each datastore. This setup can become a bottleneck in scenarios requiring high performance. By enabling multiple connections per IP, nConnect significantly enhances data throughput and performance. Here’s a quick overview of the benefits:

  • Increased Performance: Multiple connections can be established per session, reducing congestion and improving data transfer speeds.
  • Flexibility: Customers can configure datastores with multiple IPs to the same server and also multiple connections with the same IP.
  • Scalability: Supports up to 8 connections per IP, enhancing scalability for demanding workloads.

Configuring nConnect

Adding a New NFSv4.1 Datastore

When adding a new NFSv4.1 datastore, you can specify the number of connections at the time of the mount using the following command:

esxcli storage nfs41 add -H <host> -v <volume-label> -s <remote_share> -c <number_of_connections>

By default, the maximum number of connections per session is set to 4. However, this can be increased to 8 using advanced NFS options. Here’s how you can configure it:

  1. Set the maximum number of connections to 8: esxcfg-advcfg -s 8 /NFS41/MaxNConnectConns
  2. Verify the configuration: esxcfg-advcfg -g /NFS41/MaxNConnectConns

The total number of connections used across all mounted NFSv4.1 datastores is limited to 256.

Modifying Connections for an Existing NFSv4.1 Datastore

For an existing NFSv4.1 datastore, the number of connections can be increased or decreased at runtime using the following command:

esxcli storage nfs41 param set -v <volume-label> -c <number_of_connections>

Multipathing and nConnect Coexistence

There is no impact on multipathing when using nConnect. Both NFSv4.1 nConnect and multipaths can coexist seamlessly. Connections are created for each of the multipathing IPs, allowing for enhanced redundancy and performance.

Example Configuration with Multiple IPs

To add a datastore with multiple IPs and specify the number of connections, use:

esxcli storage nfs41 add -H <IP1,IP2> -v <volume-label> -s <remote_share> -c <number_of_connections>

This command ensures that multiple connections are created for each of the specified IPs, leveraging the full potential of nConnect.

Summary

The introduction of nConnect support in vSphere 8.0 U3 for NFS v4.1 datastores marks a significant enhancement in network performance and flexibility. By allowing multiple connections per IP, nConnect addresses the limitations of single connection setups, providing a robust solution for high-performance environments. Whether you’re configuring a new datastore or updating an existing one, nConnect offers a scalable and efficient way to manage your NFS workloads.

https://core.vmware.com/resource/whats-new-vsphere-8-core-storage

vmss2core: Where to Download It and How to Convert VM Snapshots (.vmsn/.vmss + .vmem) into Windows and Linux Memory Dumps

vmss2core in 2026: where to download it, which .vmsn/.vmss/.vmem files it needs, -W/-W8/-N commands, WinDbg analysis and common errors.

Short answer: vmss2core converts a VM checkpoint (a snapshot with memory, .vmsn + .vmem, or a suspend file, .vmss + .vmem) into a memory dump for WinDbg or the Linux crash utility. Get the current build from VMware Workstation Pro or Fusion; the standalone Fling in Broadcom’s Free Downloads is older (build 8456865) and does not support Windows 11, Server 2019 or Server 2025. Run vmss2core.exe -W8 vm.vmsn vm.vmem for modern Windows, -N for Linux.

vmss2core converting a VMware VM snapshot (.vmsn and .vmem) into a memory dump

What the vmss2core tool does and which files it needs

vmss2core reads VMware checkpoint state and writes a core or memory dump that standard debuggers understand: memory.dmp for Windows (WinDbg) or vmss.core for Linux (crash, GDB). It is useful when a guest hangs and you cannot force a crash dump from inside the OS.

MethodFiles to copyNotes
Snapshot with memory<name>-SnapshotN.vmsn + <name>-SnapshotN.vmemVM keeps running. Pick the newest pair by timestamp.
Suspend<name>.vmss + <name>.vmemHardware version 11 or newer, or VMs on vVols, write a separate .vmem. Hardware version 10 or lower keeps everything in the .vmss.

The .vmem file is the guest memory image. The .vmsn/.vmss file holds the device and CPU state. You always pass the state file first and the .vmem second.

vmss2core download: where to get it now

The old Flings site and vmwa.re/flings links are gone. Flings now live in the Free Downloads section of the Broadcom Support Portal, which needs a free Broadcom account (personal email addresses are accepted).

SourceVersionUse it for
Broadcom Support Portal > Free Downloads > Flings > VMSS2CoreLegacy standalone build 8456865 (Windows and Linux binaries)Older guests only. Not for Windows 11, Server 2019 or Server 2025.
VMware Workstation Pro (Free Downloads)Current, bundledAny supported guest, including Windows 11 and Server 2025
VMware Fusion Pro (Free Downloads)Current, bundledSame, on macOS

Once Workstation or Fusion is installed, the binary is here:

  • Windows 64-bit: C:\Program Files (x86)\VMware\VMware Workstation\vmss2core.exe
  • Windows 32-bit: C:\Program Files\VMware\VMware Workstation\
  • Linux: /usr/bin/ (Broadcom’s KB calls the Linux binary vmss2core-Linux64; same syntax)
  • macOS (Fusion): /Library/Application Support/VMware Fusion/

Get the latest vmss2core.exe without installing Workstation

  1. Download the VMware Workstation Pro installer from Free Downloads (Broadcom’s example: VMware-Workstation-Full-25H2u1-25219725.exe).
  2. Open the installer with 7-Zip, then open Workstation.cab inside it.
  3. Copy vmss2core.exe and _zlib1.dll to one folder, for example C:\Temp\vmss2core.
  4. Rename _zlib1.dll to zlib1.dll. Without this you get “The code execution cannot proceed because zlib1.dll was not found.”

Get the snapshot or suspend files from ESXi

vSphere Client datastore browser showing the .vmsn and .vmem snapshot files to download for vmss2core
  1. Reproduce the problem so the guest is in the state you want to capture. The guest kernel must be loaded; a VM stuck in BIOS/POST or before the OS boots gives no usable data.
  2. In the vSphere Client, right-click the VM and take a snapshot with the VM’s memory included, or suspend it (Power > Suspend). From the ESXi Shell you can suspend with vim-cmd vmsvc/getallvms and vim-cmd vmsvc/power.suspend <VMID>.
  3. Browse the datastore to the VM folder (/vmfs/volumes/<datastore>/<vm_name>/) and download the .vmsn or .vmss file and the matching .vmem.
  4. Copy them to the folder that contains vmss2core.

On vSAN the .vmem is an object; Broadcom KB 326327 describes reading its object ID and exposing it with objtool before copying. For Horizon desktops, put full clones in maintenance mode before suspending; for instant clones, use a memory snapshot instead. The Broadcom KBs are written for ESXi 8.x; memory snapshots and suspend work the same way in vSphere 9.

vmss2core for Windows: -W or -W8

OptionGuest OS (Broadcom KB 323788)
-WWindows 7, Windows 10, Windows Server 2008, 2008 R2
-W8Windows 8, 8.1, Windows 11, Windows Server 2012, 2016, 2019, 2025
-NLinux
vmss2core.exe -W8 test-vm.vmsn test-vm.vmem
vmss2core.exe -W8 test-vm.vmss test-vm.vmem
vmss2core.exe -W  old-vm.vmsn old-vm.vmem

KB 181598 phrases it slightly differently: -W8 for Windows 8 / Server 2012 and later, -W for older Windows. The two KBs disagree on Windows 10. Success produces memory.dmp in the current folder.

vmss2core for Linux guests: -N

./vmss2core-Linux64 -N vm-Snapshot1.vmsn vm-Snapshot1.vmem
vmss2core.exe -N vm-Snapshot1.vmsn vm-Snapshot1.vmem

The result is vmss.core, a Red Hat crash-format core. The tool’s help says -N uses kernel structure offsets passed with -l, generated by getlinuxoffsets. Here is my own -N run from the original version of this post (vmss2core build 20800274, about 2,000 MB written, progress lines shortened):

vmss2core.exe -N VM-Snapshot1.vmsn VM-Snapshot1.vmem
vmss2core version 20800274 Copyright (C) 1998-2022 VMware, Inc. All rights reserved.
Started core writing.
Writing note section header.
Writing 1 memory section headers.
Writing notes.
... 100 MBs written.
... 200 MBs written.
...
... 1900 MBs written.
... 2000 MBs written.
Finished writing core.

Analyze the VMware memory dump

  • Windows, WinDbg: windbg -y <SymbolPath> -z memory.dmp, or File > Open Crash Dump (Ctrl+D). Start with !analyze -v, then .bugcheck, lm and !process 0 0.
  • Linux, crash: crash vmlinux vmss.core. crash needs two arguments for a dump file: the uncompressed kernel (vmlinux with debug info matching the guest kernel) and the dump.

vmss2core errors and fixes

SymptomCause and fix
Unrecognized .vmss file (magic 4f434e45), 0 KB memory.dmpVM files are encrypted (Windows 11 / Server 2025 with vTPM). Suspend the VM, decrypt on ESXi with crypto-util (below), convert the decrypted files with the current vmss2core.
Error parsing Windows data. Cannot create memory.dmpWindows kernel was not loaded yet (stuck in POST, no boot device, boot failure). Capture again after the OS is up.
0 KB dump, or a .core file instead of memory.dmpVBS or Hyper-V is enabled in the guest. Check vhv.enable = "TRUE" in the .vmx; the KB says to set it to "FALSE". Also update old Windows builds.
Access is DeniedUse the latest vmss2core from Workstation Pro.
EFI VM freezes on a black screen, Cannot translate linear addressEFI SMM deadlock on hardware version below 14 (ESXi 7.0). Fixed in ESXi 8.0; workaround is hardware version 14 or later (KB 318382).
crypto-util encobj decrypt --related vm-###.vmx vm-###.vmem vm-###-decrypted.vmem
crypto-util encobj decrypt --related vm-###.vmx vm-###.vmss vm-###-decrypted.vmss
vmss2core.exe -W8 vm-###-decrypted.vmss vm-###-decrypted.vmem

Do not remove the vTPM to get around encryption: Broadcom warns that this makes encrypted data unrecoverable and stops Windows 11 from booting.

vmss2core options reference

Output of vmss2core.exe without arguments on my machine (build 20800274, abridged):

Usage:
GENERAL:  vmss2core [[options] | [-l linuxoffsets options]] \
          <vmss file> [<vmem file>]

Without options one vmss.core<N> per vCPU with linear view of
memory is generated.
-q      Quiet(er) operation.
-M      Create core file with physical memory view (vmss.core).
-l str  Offset stringset expressed as 0xHEXNUM,0xHEXNUM,... .
-N      Red Hat crash core file for arbitrary Linux version
        described by the "-l" option (vmss.core).
-N4     Red Hat crash core file for Linux 2.4 (vmss.core).
-N6     Red Hat crash core file for Linux 2.6 (vmss.core).
-O <x>  Use <x> as the offset of the entrypoint.
-U <i>  Create linear core file for vCPU <i> only.
-P      Print list of processes in Linux VM.
-P<pid> Create core file for Linux process <pid> (core.<pid>).
-S      Create core for 64-bit Solaris (vmcore.0, unix.0).
-S32    Create core for 32-bit Solaris (vmcore.0, unix.0).
-W      Create WinDbg file (memory.dmp) with commonly used
        build numbers ("2195" for Win32, "6000" for Win64).
-W<num> Create WinDbg file (memory.dmp), with <num> as the
        build number (for example: "-W2600").
-WK     Create a Windows kernel memory only dump file (memory.dmp).
-WDDB<num> or -W8DDB<num>
        Create WinDbg file (memory.dmp), with <num> as the
        debugger data block address in hex.
-WSCAN  Scan all of memory for Windows debugger data blocks
        (instead of just low 256 MB).
-W8     Generate a memory dump file from a suspended Windows 8 VM.
-X32    <mach_kernel> Create core for 32-bit Mac OS.
-X64    <mach_kernel> Create core for 64-bit Mac OS.
-F      Create core for an EFI firmware exception.

Sources

Related on vdan.cz