Microsoft UEFI Secure Boot Certificate Expiration in vSphere VMs

Broadcom KB 423893 remains the single source of truth for the Microsoft certificate expiration topic in UEFI Secure Boot VMs.

Important: even if the Microsoft KEK certificate expires, affected VMs will continue to boot. The impact is mainly that the VM may not be able to update Microsoft KEK, DB and DBX certificates, which can block future Secure Boot related security updates. Guest OS updates not relying on these Secure Boot databases should continue to work.

This topic only concerns VMs with UEFI Secure Boot enabled. The KB also includes PowerShell scripts to identify Secure Boot / vTPM VM status and to reboot VMs.

ScenarioSecure BootvTPMRemediation Action
ESXi 8.0 U3i (P08) and lower builds & ESX 7.xESXi 8.0 U3j (P09)ESX 9.x
1DisabledDisabledNo ActionSilentPK Update

Note: This is optional as Secureboot & vTPM are disabled
No Action
2EnabledDisabledManual Update from vUEFI interfaceSilentPK UpdateManual Update from vUEFI interface
3EnabledEnabledManual Update from vUEFI interfaceManual Update from VMX Configuration(preferred for Non Windows VMs)

For Windows VMs, wait for the automated PK update solution (to be available in an upcoming 8.x patch release)
Manual Update from VMX Configuration(preferred for Non Windows VMs)

For Windows VMs, wait for the automated PK update solution (to be available in an upcoming 9.1.x patch release)
4DisabledEnabledNo ActionNo ActionNo Action

Summary:

  • Secure Boot enabled without vTPM: patch ESXi hosts to 8.0 U3j and reboot the VMs to remediate PK automatically.
  • Secure Boot enabled with vTPM: follow the KB carefully. For Windows VMs, Broadcom recommends waiting for the automated remediation in a future ESXi patch.
  • After PK remediation, follow the guest OS vendor guidance to update KEK, DB and DBX certificates.

vCenter STS Signing Certificate Expiration: Small Certificate, Big Outage

Certificates in vCenter are usually associated with Machine SSL, Solution Users, or trusted roots. However, there is another certificate that can have a very large operational impact: the Security Token Service signing certificate, commonly known as the STS signing certificate.

The STS certificate is not the certificate you see in your browser when opening the vSphere Client. It is part of the vCenter Single Sign-On authentication flow. When a user or internal service authenticates, STS validates the primary credentials and issues a SAML token containing user or service attributes. That token is then used by vCenter services to trust the authenticated identity.

In short: if STS cannot issue valid tokens, vCenter authentication starts to break.

Broadcom describes the STS certificate as critical for vSphere SSO because it is responsible for issuing, validating, and renewing security tokens.


What is the STS signing certificate?

The Security Token Service is part of vCenter Single Sign-On. Its job is to issue signed SAML tokens after successful authentication.

By default, the VMware Certificate Authority, or VMCA, generates the STS signing certificate. In most environments, the default VMCA-issued STS certificate is sufficient. You can refresh it with a new VMCA-issued certificate, or import a custom / third-party STS signing certificate if your company security policy requires all certificates to be replaced.

However, replacing the STS certificate should not be treated as a routine cosmetic change. Broadcom specifically warns that refreshing the STS certificate with a vCenter-issued certificate can replace third-party/custom certificates and may take the environment out of compliance if custom certificates are required.


Why does STS expiration matter?

When the STS signing certificate expires, vCenter may no longer be able to issue valid SAML tokens. This affects both users and internal solution users.

The result can be severe:

  • vSphere Client login failures
  • vCenter services failing to start after reboot
  • vmware-stsd service not starting
  • vpxd authorization errors
  • Signing certificate is not valid
  • No Healthy Upstream
  • failures in Enhanced Linked Mode environments
  • problems exporting OVF templates
  • certificate replacement workflows failing because authentication itself is broken

Broadcom’s KB for "Signing certificate is not valid" or "No healthy upstream" explains that these issues occur when the STS certificate or its signing root certificate has expired, preventing internal services and solution users from acquiring valid tokens.

This is why an STS certificate problem can look much bigger than a normal certificate warning. It can make the entire vCenter feel broken.


Typical symptoms

If the STS certificate is already expired, you may see errors such as:

HTTP Status 400 – Bad Request
Signing certificate is not valid
Cannot connect to vCenter Single Sign-On server
https://VC_FQDN/sts/STSService/vsphere.local
503 Service Unavailable
No Healthy Upstream

You may also see service startup failures after reboot. Broadcom notes that an expired STS certificate can prevent the vmware-stsd service from starting, which then causes dependent vCenter services to fail as well.


The warning: “STS Signing Certificates are about to expire”

In newer vCenter versions, you may receive the following alarm in the vSphere UI:

STS Signing Certificates are about to expire

This alarm means that the STS certificate for the vCenter Server Appliance is nearing expiration. Broadcom states that if the STS signing certificates expire without being replaced, vCenter will no longer be functional.

That warning should not be ignored.


How to check the STS certificate

For vCenter 7.0 Update 2 and later, the STS certificate can be checked from the vSphere Client:

vSphere Client
→ Administration
→ Certificates
→ Certificate Management
→ STS signing certificate

The UI shows the Valid until date, certificate status, and certificate chain details. Broadcom recommends checking the STS certificate periodically, because the general certificate expiry alarm does not account for the STS certificate in the same way.

For command-line or advanced checks, Broadcom now recommends using vCert instead of the older checksts.py script. The checksts.py script is deprecated, and vCert is the current recommended tool for certificate management and replacement workflows.


Recommended tool: vCert

Broadcom provides vCert.py, a menu-driven tool for certificate management on vCenter Server 7.0, 8.0, and 9.0. Its purpose is to simplify certificate replacement when certificates expire or are about to expire.

Basic usage:

unzip -q vCert-<version>.zip
cd vCert-<version>
chmod +x vCert.py
./vCert.py

Useful menu paths:

2. View certificate info
→ 8. STS signing certificates
3. Manage certificates
→ 8. STS signing certificates

Broadcom’s KB also states that vCert creates logs under:

/var/log/vmware/vCert

and uses a working directory under:

/root/vCert-master

for staging and backups.


Replacing or refreshing the STS certificate before it expires

If the STS certificate is still valid and the vSphere Client is accessible, the preferred approach is usually to refresh it from the UI.

Path:

vSphere Client
→ Administration
→ Certificate Management
→ STS signing certificate
→ Actions
→ Refresh with vCenter certificate

Broadcom marks Refresh with vCenter certificate as the recommended UI option. It generates a new VMCA-issued STS certificate.

There is also an Import and Replace Certificate option for custom or third-party certificates. Use this only when required by your company security policy.

Important: Before making certificate changes, create proper offline snapshots of all vCenter Server appliances in the environment. In Enhanced Linked Mode, this means all vCenter / PSC nodes in the same SSO domain. Broadcom explicitly recommends snapshots before STS certificate replacement operations.


What if vCenter is already broken?

If the STS certificate has already expired, the vSphere Client may not be usable. You may be stuck with:

No Healthy Upstream

or:

Signing certificate is not valid

In that case, use vCert directly on the VCSA via SSH. Broadcom recommends vCert for checking and replacing STS signing certificates when vCenter is inaccessible.

The high-level recovery flow is:

1. Take offline snapshot / backup.
2. SSH to VCSA as root.
3. Upload and extract vCert.
4. Run ./vCert.py.
5. Check STS signing certificate.
6. Replace STS signing certificate.
7. Restart services if required.
8. Validate vSphere Client login.

Never skip the snapshot step. Certificate repair can make the situation worse if performed incorrectly.


Important note for vSphere 8

In vSphere 8.0, vCenter Single Sign-On can automatically renew a VMCA-generated STS signing certificate before it expires. However, Broadcom has documented rare cases where an STS refresh happening during long-running vSphere Lifecycle Manager operations can cause task failures due to cached STS certificate data.

So even with automatic renewal, it is still useful to know where the STS certificate is, how to check it, and how it affects authentication.


Best practices

My practical checklist:

1. Check STS certificate validity regularly.
2. Do not wait until the last week before expiration.
3. Replace if the certificate expires within 6 months.
4. Use vSphere Client if vCenter is still healthy.
5. Use vCert if vCenter login or services are already broken.
6. Take offline snapshots before any certificate operation.
7. In ELM, snapshot all vCenter/PSC nodes in the SSO domain.
8. Be careful with custom/third-party STS certificates.
9. Document the certificate state before and after replacement.
10. Validate vCenter login, service health, and integrations after replacement.

Broadcom recommends replacing the STS certificate if it is set to expire within six months. If expiration is more than six months away, schedule the replacement for an appropriate maintenance window.


Summary

The STS signing certificate is easy to overlook because it is not the browser-facing Machine SSL certificate. But it is one of the most important certificates in vCenter authentication.

When it expires, the impact can be dramatic: broken SSO, failed service startup, Signing certificate is not valid, and even No Healthy Upstream.

The key lesson is simple:

Do not wait for STS expiration to become an outage. Check it, plan it, snapshot first, and use the supported Broadcom workflows.


References

  • Broadcom KB 318197 — "STS Signing Certificates are about to expire" alert received in vSphere UI
  • Broadcom KB 316619 — "Signing certificate is not valid" or "No healthy upstream" error in vCenter Server Appliance
  • Broadcom KB 385107 — vCert - Scripted vCenter expired certificate replacement
  • Broadcom KB 318968 — Checking the STS certificate expiration and replacing expired STS certificates on vCenter Servers
  • Broadcom KB 423367 — How to Export the STS Certificate from vCenter Server

VCF 9.x Upgrade Stuck on vRNI / Aria Operations for Networks SSL Thumbprint Validation


During a VMware Cloud Foundation upgrade, you may hit a situation where the upgrade workflow fails on validation of the vRNI / Aria Operations for Networks certificate thumbprint.

Even after replacing the certificate directly on the vRNI appliance, clicking Retry in SDDC Manager may continue to fail with the old certificate thumbprint.

This can be confusing because the certificate on the vRNI side is already correct, but SDDC Manager still validates against the previous thumbprint.

Root Cause

The root cause is that SDDC Manager caches the SSL thumbprint either in its internal database, platformdb, or in the LCM / Domain Manager service memory when the upgrade task is first initialized.

As a result, even if the certificate is replaced on the vRNI / Aria Operations for Networks appliance, the Retry button does not automatically rediscover the new certificate thumbprint.

Instead, the retry operation may continue to use the old cached value.

To resolve this, the thumbprint stored in the SDDC Manager inventory database must be updated manually.

Warning:
This procedure modifies the internal SDDC Manager database. Use it only when you fully understand the impact. Always take a backup or snapshot of the SDDC Manager appliance before making manual database changes. In production environments, validate with VMware/Broadcom support first.


Step 1: Extract the New Certificate Thumbprint from vRNI

Log in to the SDDC Manager appliance via SSH.

Usually this means logging in as vcf and then switching to root:

su -

Now retrieve the SHA-256 fingerprint of the currently installed certificate on the vRNI / Aria Operations for Networks appliance:

echo -n | openssl s_client -connect <VRNI_FQDN_OR_IP>:443 2>/dev/null | openssl x509 -noout -fingerprint -sha256

Example output:

sha256 Fingerprint=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX

Copy only the thumbprint value, without the prefix:

XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX

Step 2: Check the Current Thumbprint in SDDC Manager Database

Connect to the SDDC Manager PostgreSQL database:

psql -h localhost -U postgres -d platformdb

Now locate the vRNI / Aria Operations for Networks resource record:

SELECT id, type, status, ssl_thumbprint
FROM resource
WHERE type LIKE '%VRNI%'
OR type LIKE '%ARIA%';

Identify the row that belongs to your vRNI / Aria Operations for Networks appliance.

You should see that the ssl_thumbprint column still contains the old thumbprint, for example:

EF:0B:A2:15:...

Step 3: Update the Stored Thumbprint

Update the resource record with the new thumbprint:

UPDATE resource
SET ssl_thumbprint='<NEW_THUMBPRINT>'
WHERE id='<COMPONENT_ID>';

Example:

UPDATE resource
SET ssl_thumbprint='=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX'
WHERE id='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx';

Verify the change:

SELECT id, type, status, ssl_thumbprint
FROM resource
WHERE id='<COMPONENT_ID>';

Exit PostgreSQL:

\q

Step 4: Restart LCM and Domain Manager Services

SDDC Manager may still cache inventory data in memory, so restart the relevant services:

systemctl restart lcm
systemctl restart domainmanager

Wait a few minutes until the services are fully initialized.

You can monitor the LCM service log with:

tail -f /var/log/vmware/vcf/lcm/lcm.log

Step 5: Reset a Stuck Upgrade Task if Needed

In some cases, the upgrade task may remain stuck in an IN_PROGRESS state or the Retry button may stay unavailable.

If this happens, check the active execution tasks in the SDDC Manager database.

Connect again to PostgreSQL:

psql -h localhost -U postgres -d platformdb

Find tasks that are still marked as running:

SELECT id, status, action
FROM execution_task
WHERE status='IN_PROGRESS';

Identify the specific stuck task related to the failed upgrade validation.

Then manually mark it as failed:

UPDATE execution_task
SET status='FAILED'
WHERE id='<TASK_ID>';

Exit PostgreSQL:

\q

Step 6: Resume the Upgrade

Return to the SDDC Manager UI and refresh the upgrade page.

The upgrade workflow should now allow you to click Retry again.

This time, SDDC Manager should read the corrected thumbprint from the database, validate it against the current vRNI / Aria Operations for Networks certificate, and continue with the VCF 9.x upgrade.


Summary

If a VCF 9.x upgrade continues to fail on vRNI / Aria Operations for Networks certificate validation even after the certificate has been replaced, the issue may not be the certificate itself.

The problem can be caused by a stale SSL thumbprint cached in SDDC Manager.

The fix is to:

  1. Extract the new SHA-256 certificate thumbprint from vRNI.
  2. Update the corresponding ssl_thumbprint value in platformdb.
  3. Restart the lcm and domainmanager services.
  4. Reset the stuck execution task if required.
  5. Retry the upgrade from the SDDC Manager UI.

This is a useful recovery procedure when the UI retry mechanism continues to use stale inventory data instead of the actual certificate currently installed on the vRNI appliance.

Holodeck 9.0.2 with VCF 9.0.2.0 Stuck at Install-VcfInstallerBundles


Bug VCF 9.0.2.0 with Holodeck 9.0.2

While deploying VMware Cloud Foundation 9.0.2.0 with Holodeck 9.0.2, I hit an interesting issue during the bundle download phase.

The deployment did not fail with a clear error. Instead, it stalled indefinitely at:

Install-VcfInstallerBundles

At first glance, everything looked fine. The VCF Installer depot UI showed all required components as downloaded successfully. However, the Holodeck deployment kept waiting forever.

The root cause turned out to be a hardcoded bundle count check inside the Holodeck PowerShell module.


Environment

The issue was observed with the following setup:

Holodeck:        9.0.2
HoloRouter OVA: 9.0.2.0424
VCF Installer: 9.0.2.0
Target VCF: 9.0.2.0
Deployment: Full VCF, ManagementOnly
Depot: Online depot

Important detail: this was full VCF, not VVF.


Symptom

During deployment, the log repeatedly showed:

SddcMgmtDomain[<pid>]: [INFO] Received Bundles. Checking if all VCF 9 bundles are available
SddcMgmtDomain[<pid>]: [INFO] Didn't receive all bundles. Received 8 bundle details. Trying again after 10 seconds

This message repeated every 10 seconds.

At the same time, the VCF Installer UI showed all visible components as successfully downloaded:

SDDC Manager 9.0.2.0
VMware Cloud Foundation Automation 9.0.2.0
VMware Cloud Foundation Operations 9.0.2.0
VMware Cloud Foundation Operations Collector 9.0.2.0
VMware Cloud Foundation Operations fleet management 9.0.2.0
VMware NSX 9.0.2.0
VMware vCenter 9.0.2.0

So from the UI perspective, everything looked complete. However, Holodeck was still waiting.


Root Cause

The problematic logic is inside the Holodeck PowerShell module on the deployed HoloRouter:

/root/.local/share/powershell/Modules/HoloDeck/Modules/SddcMgmtDeployment.psm1

The affected function is:

Install-VcfInstallerBundles

Holodeck queries the VCF Installer API:

https://${HostName}/v1/bundles/download-status?imageType=INSTALL

Then it filters bundles matching the selected VCF version:

}elseif($Version -eq "9.0.2.0"){
$vcf9_bundle_details = $bundle_details.elements | Where-Object {$_.version -match "9\.0\.2\.0\.*"}
}

The problem is the final count check:

elseif($vcf9_bundle_details.count -eq 7){
Write-Log -Message "Received all Bundle Details"
$bundle_api_response = $true
}
else{
Write-Log -Message "Didn't receive all bundles. Received $($vcf9_bundle_details.count) bundle details. Trying again after 10 seconds"
Start-Sleep -Seconds 10
}

For VCF 9.0.2.0, the API returns 8 matching bundle entries, not 7.

That means this condition never becomes true:

$vcf9_bundle_details.count -eq 7

Holodeck receives 8 bundles, but waits for exactly 7.

Result: an infinite loop.


Why Does the API Return 8 Bundles?

In VCF 9.0.2.0, the bundle structure changed compared to earlier VCF 9 versions.

The depot UI shows 7 visible rows, but the API response contains 8 entries matching:

9.0.2.0.*

The 9.0.2 BOM appears to split some components more granularly, for example around VCF Operations, Operations Collector, and Fleet Management. The UI abstracts this nicely, but the API exposes one additional bundle-level entry.

The important part is this:

VCF Installer UI: 7 visible downloaded components
VCF Installer API: 8 matching bundle entries
Holodeck logic: expects exactly 7

That mismatch is enough to block the deployment.


Workaround

Edit the Holodeck module directly on the HoloRouter.

Change this:

}elseif($vcf9_bundle_details.count -eq 7){

To this:

}elseif($vcf9_bundle_details.count -ge 7){

One-liner:

sed -i 's/$vcf9_bundle_details.count -eq 7/$vcf9_bundle_details.count -ge 7/' \
/root/.local/share/powershell/Modules/HoloDeck/Modules/SddcMgmtDeployment.psm1

This changes the check from “exactly 7 bundles” to “at least 7 bundles”.


Restart the Running PowerShell Session

The currently running pwsh process already has the old function loaded in memory.

After patching the file, kill the running PowerShell process:

pkill -9 -f pwsh

Then start a fresh PowerShell session and resume the deployment:

Import-HoloDeckConfig -ConfigID <id>

New-HoloDeckInstance -Version 9.0.2.0 -InstanceID <same-as-before> <original flags>

For example:

New-HoloDeckInstance -Version 9.0.2.0 -InstanceID 1 -ManagementOnly

Use the same flags you used in the original deployment.


What Happens After the Patch?

After applying the workaround, Holodeck resumes at the existing deployment state.

In my case, the state engine resumed at:

Install-VcfInstallerBundles

The patched function immediately accepted the 8 returned bundle entries and logged:

Received all Bundle Details

The deployment then moved forward.

Some bundle download calls may return:

BUNDLE_DOWNLOAD_ALREADY_DOWNLOADED

That is expected because the bundles are already present in the depot. The existing try/catch handling allows the phase to complete quickly.

After that, the deployment advanced to the management-domain phase.


Suggested Proper Fix

The quick fix is:

- }elseif($vcf9_bundle_details.count -eq 7){
+ }elseif($vcf9_bundle_details.count -ge 7){

A version-specific fix would also work, for example:

VCF 9.0.0.0 / 9.0.1.0 -> expect 7
VCF 9.0.2.0 -> expect 8

However, that would likely reintroduce the same type of bug in a future VCF BOM revision.

A better long-term approach would be to avoid a hardcoded count completely and validate the actual bundle download state instead.

For example, Holodeck should check that all required bundles for the selected deployment type and version are present and successfully downloaded, instead of assuming that the bundle count is always static.

Still, as an immediate workaround, changing -eq 7 to -ge 7 is enough to unblock the deployment.


Important Notes

This is an unofficial workaround.

The affected PowerShell module is not part of the public Holodeck documentation repository. It is bundled inside the HoloRouter OVA distributed through the Broadcom Support Portal.

Before editing vendor-supplied files, it is always a good idea to make a backup:

cp /root/.local/share/powershell/Modules/HoloDeck/Modules/SddcMgmtDeployment.psm1 \
/root/.local/share/powershell/Modules/HoloDeck/Modules/SddcMgmtDeployment.psm1.bak

Then apply the patch.


Summary

This is a good example of a small hardcoded assumption causing a deployment to stall without an obvious fatal error.

The VCF Installer API was returning valid data. The depot was populated. The UI showed the bundles as successfully downloaded. But Holodeck was waiting for an exact number of bundle entries that no longer matched the VCF 9.0.2.0 BOM.

For affected Holodeck 9.0.2 users deploying VCF 9.0.2.0, the key symptom is:

Didn't receive all bundles. Received 8 bundle details. Trying again after 10 seconds

If you see this message, check the bundle count logic in:

SddcMgmtDeployment.psm1

The workaround is small, but it can save a lot of troubleshooting time.


Quick Reference

cp /root/.local/share/powershell/Modules/HoloDeck/Modules/SddcMgmtDeployment.psm1 \
/root/.local/share/powershell/Modules/HoloDeck/Modules/SddcMgmtDeployment.psm1.bak

sed -i 's/$vcf9_bundle_details.count -eq 7/$vcf9_bundle_details.count -ge 7/' \
/root/.local/share/powershell/Modules/HoloDeck/Modules/SddcMgmtDeployment.psm1

pkill -9 -f pwsh

Then resume:

Import-HoloDeckConfig -ConfigID <id>
New-HoloDeckInstance -Version 9.0.2.0 -InstanceID <same-as-before> <original flags>

KB 406901: Fix “Certificate authorities update failed” in the VCF Management CA Wizard (VCF 9.0)

When integrating a Microsoft Certificate Authority (CA) with VMware Cloud Foundation (VCF) Operations / Fleet Management in VCF 9.0, you may hit a frustrating blocker: the “Configure Certificate Authority for VCF Management” wizard fails with:

“Certificate authorities update failed”

This is documented in Broadcom KB 406901 and, importantly, it’s not always a connectivity or permissions problem—it can be a password character parsing issue.


What you’ll see

UI symptom

In the Configure Certificate Authority for VCF Management wizard, the validation/update step fails with:

  • Certificate authorities update failed

Log symptom (Fleet Management / VCF Operations appliance)

On the VCF Operations appliance, you’ll typically find a 401 Unauthorized in:

  • /var/log/vrlcm/vmware_vrlcm.log

Example (as shown in the KB):

  • Exception occurred while trying to validate Microsoft CA
  • HttpClientErrorException$Unauthorized: 401 Unauthorized
  • 401 - Unauthorized: Access is denied due to invalid credentials.

At first glance, this looks like wrong credentials or insufficient permissions. But KB 406901 highlights a very specific trigger.


Root cause (the “gotcha”)

This is a known issue with special characters in the CA service account password, specifically:

  • # or &

Even if the username/password are correct, the wizard’s CA validation request can fail in a way that surfaces as a 401 Unauthorized.


Resolution / Workaround (what to do now)

1) Reset the service account password

Change the Microsoft CA service account password to a value that does NOT contain:

  • #
  • &

Use a “safe” password character set (letters + numbers is the simplest) to avoid re-triggering the issue.

2) Re-run (or re-save) the CA configuration in the wizard

Go back to the Configure Certificate Authority for VCF Management wizard, enter the updated credentials, and run the validation/update again.

Link: Configure Certificate Authority for VCF Management fails with error, “Certificate authorities update failed”

Accelerating AI Workloads: Mastering vGPU Management in VMware Environments

Explore 2025 Session Recap – INVB1158LV

Are you looking to maximize AI/ML performance in your virtualized environment? At VMware Explore 2025, I attended a compelling session — INVB1158LV: Accelerating AI Workloads: Mastering vGPU Management in VMware Environments — that unpacked how to effectively configure and scale GPUs for AI workloads in vSphere.

This blog post shares key takeaways from the session and outlines how to use vGPU, MIG, and Passthrough to achieve optimal performance for AI inference and training on VMware Cloud Foundation 9.0.


vGPU Configuration Options in VMware vSphere

🔹 1. DirectPath I/O (Passthrough)

  • A dedicated GPU is assigned to a single VM or containerized workload.
  • Ideal for maximum performance and full GPU access (e.g., LLM training).
  • No sharing or resource fragmentation.

🔹 2. NVIDIA vGPU – Time Slicing Mode

  • Shares one physical GPU across multiple VMs.
  • Each VM gets 100% of GPU cores for a slice of time, while memory is statically partitioned.
  • Supported on all NVIDIA GPUs.
  • Useful for efficient GPU sharing, especially for model inference and dev/test setups.

✅ Example profiles: grid_a100-8c, grid_a100-4-20c

🔹 3. Multi-Instance GPU (MIG)

  • Available on NVIDIA Ampere & Hopper (e.g., A100, H100).
  • Splits GPU into isolated hardware slices (compute + memory).
  • Offers deterministic performance and better isolation.
  • Best for multi-tenant AI inference, production-grade deployments.

✅ Example profiles: MIG 1g.5gb, MIG 2g.10gb, MIG 3g.20gb
✅ Assignable via vSphere UI with profiles like grid_a100-3-20c


Time Slicing vs. MIG – When to Use What?

ModeBest ForSharing Type
Time SlicingLLM training, dev/test environmentsTime-shared
MIGProduction inference, multitenancySpatial (hardware)
PassthroughMaximum performance for single workloadNot shared

Smarter vMotion for AI Workloads in VCF 9.0

One of the standout improvements presented during session INVB1158LV was the vMotion optimization for VMs using vGPUs. With vSphere 8.0 U3 and VMware Cloud Foundation 9.0, the way vMotion handles GPU memory has been completely reengineered to minimize downtime (stun time) during live migration.

Instead of migrating all GPU memory during the VM stun phase, 70% of the vGPU cold data is now pre-copied in the pre-copy stage, and only the final 30% is checkpointed during stun. This greatly accelerates live migration even for massive LLM workloads running on multi-GPU systems.

📊 Example results with Llama 3.1 models:

  • Migrating a VM using 2×H100 GPUs (144 GB vGPU memory) saw stun time drop from 24.5s to just 6.3s.
  • Migrating a large model on 8×H100 (576 GB) now completes in 21s, compared to 325s for a power-off-and-reload approach — that’s a 15× improvement.

These enhancements make zero-downtime AI infrastructure upgrades and scaling possible, even for large language model deployments

Deploying a Minimal VCF 9.0 Lab – Insights from Explore 2025

I had the pleasure of attending the excellent session “Deploying Minimal VMware Cloud Foundation 9.0 Lab” by Alan Renouf and William Lam at VMware Explore 2025. It was packed with practical advice, hardware insights, and field-tested tips on how to stand up a fully functional VCF environment—even on a tight budget.

Whether you’re a home lab enthusiast, enterprise architect, or just VCF-curious, here’s a recap of the key takeaways.


Key Changes: VCF 5.x vs VCF 9.x

VCF 5.x:

  • Required 4+ ESXi hosts
  • Monolithic installer
  • vSAN required
  • 3-node NSX cluster
  • 10GbE NICs mandatory

VCF 9.x:

  • More modular design
  • Only 2–3 ESXi hosts required
  • 1 x 10GbE NIC sufficient
  • Support for singleton appliances
  • Flexible storage (vSAN ESA, FC, NFS)

VCF 9.0 Tips & Tricks (with real CLI guidance)

Here’s the juicy part—real-world deployment tips and overrides:

1. Minimum ESXi Host Requirements

  • For vSAN/FC: 3 ESXi hosts
  • For NFS: 2 ESXi hosts
  • ⚠️ You can install VCF Installer + SDDC Manager even on a single ESXi host (great for nested labs!)
> cat /home/vcf/feature.properties

feature.vcf.internal.single.host.domain = true

> echo 'y' | /opt/vmware/vcf/operationsmanager/scripts/cli/sddcmanager_restart_services.sh

2. NIC Validation Bypass

If your ESXi host doesn’t have a 10GbE NIC:

> cat /etc/vmware/vcf/domainmanager/application.properties

enable.speed.of.physical.nics.validation = false

> echo 'y' | /opt/vmware/vcf/operationsmanager/scripts/cli/sddcmanager_restart_services.sh

3. vSAN HCL Override

VCF Installer will fail validation if your SSD or controller is not on the vSAN ESA HCL. Install a “mock” VIB to bypass:

esxcli software vib install -v /tmp/vsan-mock.vib

4. Offline Depot HTTPS Requirement

By default, the VCF installer requires HTTPS:

cat /opt/vmware/vcf/lcm/lcm-app/conf/application-prod.properties

lcm.depot.adapter.httpsEnabled=false

systemctl restart lcm

5. Basic Auth Requirement

You don’t need a full-blown web server:

python http_server_auth.py --bind 192.168.1.100 --user myuser --password mysecurepassword --port 443 --directory /myrepo

Reference Hardware for Minimal Lab

Here’s an example BOM shared by the presenters:

  • MinisForum MS-A2 w/ AMD Ryzen 7945HX (16c/32t)
  • 128GB DDR5 (2x64GB SODIMM)
  • 3x M.2 NVMe SSDs
  • 10GbE SFP+ NIC + 2.5GbE onboard
  • MikroTik 5-port 10GbE switch (for under $200)

This setup is small, powerful, and flexible enough for a complete VCF 9.0 deployment.


Deployment Walkthrough – TL;DR

Here’s the summarized 8-step flow:

  1. Install ESXi (kickstart from USB)
  2. Deploy VCF Installer VM
  3. Connect to Offline Depot
  4. Run Installer with JSON
  5. Configure vSAN ESA
  6. Deploy vCenter
  7. Update Storage Policies
  8. Deploy SDDC Manager, NSX, Fleet Manager, Automation, etc.

Summary

This session truly showcased how far VCF has come in terms of flexibility and accessibility. More info: VMware Cloud Foundation (VCF) 9.x in a Box.
All trademarks belong to their respective owners.

Automagically Deploy VMware Cloud Foundation 9.0 in Your Homelab with the Holodeck Toolkit

VMware Explore 2025 featured an exciting session, [CODEQT1247LV] Automagically Deploy VMware Cloud Foundation 9.0 in Homelab Using VMware Cloud Foundation Holodeck Toolkit. The presentation showcased how the VMware Cloud Foundation Holodeck Toolkit makes it easier than ever to deploy a fully functional nested VMware Cloud Foundation (VCF) 9.0 lab—in just a few commands.

For IT professionals, architects, developers, and homelab enthusiasts, this toolkit is a breakthrough. Instead of struggling with the complexity of a VCF deployment, Holodeck offers a repeatable, automated process that saves both time and effort.


What Is the VMware Cloud Foundation Holodeck Toolkit?

The Holodeck Toolkit is a PowerShell-based automation framework designed for building nested VCF environments on VMware ESXi or a vSphere cluster. It’s ideal for:

  • Proof-of-concept deployments
  • Technical demos and enablement sessions
  • Training environments
  • Hands-on testing of VCF 5.2.x and VCF 9.0 features

With just four PowerShell commands, users can deploy an entire VCF management domain and optional workload domains, complete with NSX, vCenter, SDDC Manager, and vSAN ReadyNodes.


Key Features of VMware Holodeck for VCF 9.0

The session highlighted several powerful features included in Holodeck environments:

  • VCF 9.0 and 5.2.x support
  • Management Domain with 4 nested ESXi hosts, vSAN, vCenter, NSX, and SDDC Manager
  • Optional Workload Domain with 3 nested ESXi hosts and Supervisor services
  • vSAN ESA & OSA support
  • NSX Edge Clusters deployable in both management and workload domains
  • Provision-only mode for greenfield VCF Installer + ESXi testing
  • Custom CIDR support for flexible network design

This makes Holodeck an ideal solution for homelabs and VCF training environments, but it is not intended for production workloads.


The HoloRouter Appliance: Backbone of the Lab

At the core of every Holodeck deployment is the HoloRouter appliance, a Photon OS–based virtual appliance that provides critical networking and infrastructure services for the nested VCF environment:

  • DNS, DHCP, NTP
  • Firewall and BGP routing
  • Proxy services for VCF Installer
  • L3 routing between nested VLANs
  • Webtop GUI for easy access and management
  • Job scheduling and automation
  • Integrated PowerShell + PowerCLI

The HoloRouter ensures smooth connectivity between nested VCF environments and external networks, enabling realistic lab testing.


Pre-requisites

VCF 9.0Single SiteDual Site
CPU2448
Memory325 GB768 GB
Disk1.1 TB2.5TB

Links:

VMware Explore 2025 in Las Vegas | Day 1 Recap

VMware Explore 2025 in Las Vegas | Day 1 Recap

VMware Explore 2025 in Las Vegas | Day 1 Recap

VMware Explore 2025 in Las Vegas Day 1 Recap | August 25, 2025 If you heard the collective buzz across the Venetian Convention and Expo Center today, that was Day 1 of VMware Explore in Las Vegas coming to life. You crushed it—140 sessions across all four tracks, endless hallway conversations, and a few “just … Continued The post VMware Explore 2025 in Las Vegas | Day 1 Recap appeared first on VMware Explore Blog.


Broadcom Social Media Advocacy

From Aria Operations for Logs to VCF Ops for Logs: What You Need to Know About the Upgrade Path

With the release of VMware Cloud Foundation (VCF) 9.0, Aria Operations for Logs has officially been rebranded as VCF Operations for Logs. However, if you were expecting a simple in-place upgrade, there’s an important caveat: no direct in-place upgrade is supported.

Instead, administrators must deploy VCF Ops for Logs 9.0 as a fresh installation and gradually migrate integrations and data sources from their existing Aria Ops for Logs 8.18.x environment.


Why No In-Place Upgrade?

VMware Aria Operations for Logs version 8.18.x does not support an in-place upgrade path to version 9.0. The architectural and platform changes introduced in VCF 9.0 require a clean deployment.

This means that if you are currently running Aria Ops for Logs 8.18.3, you cannot simply apply an upgrade package. Instead, both versions must temporarily coexist while you complete the transition.


Recommended Migration Approach

Broadcom’s official upgrade guidance outlines the following steps:

  1. Deploy VCF Ops for Logs 9.0
  2. Unconfigure Integrations from 8.18.3
    • Keep your Aria Ops for Logs 8.18.3 instance online, but start unconfiguring existing integrations.
    • This ensures that historical log data remains accessible, even though new logs will be directed elsewhere.
  3. Reconfigure Integrations on 9.0
    • Point all your log sources, agents, and integrations to the new VCF Ops for Logs 9.0 instance.
    • Validate ingestion pipelines to confirm that logs are flowing properly.
  4. Leverage Log Transfer if Needed
    • Broadcom provides guidance for log transfer, allowing you to move log data from the old environment to the new one.
  5. Decommission the Old Instance
    • Once all integrations and data have been verified in the new platform, you can safely retire your 8.18.3 deployment.

Key Takeaways

  • Rebrand Only in Name? Not Quite. While the product name has changed from Aria Ops for Logs to VCF Ops for Logs, the lack of in-place upgrade means the transition is more than cosmetic.
  • Parallel Operations Are Required. You’ll need to run 8.18.3 and 9.0 side by side during the migration phase.
  • Fresh Deployment Is Mandatory. Treat this as a new installation rather than an upgrade.
  • Plan for Migration Effort. Reconfiguring all integrations and log sources can be time-intensive, so schedule accordingly.

Summary

If your organization relies heavily on VMware Aria Operations for Logs today, be prepared for a stepwise migration process rather than a straightforward upgrade. By planning the deployment of VCF Ops for Logs 9.0 carefully—and keeping the old instance online for historical data—you can ensure a smooth transition without losing valuable log visibility.

For more details, consult Broadcom’s official documentation: