Daniel Micanek virtual Blog – Like normal Dan, but virtual.
Thank you to everyone who applied for the vExpert program. A special thank you to the vExpert PROs for managing the application voting; it’s a lot of work! We are pleased to announce the list of 2025 vExperts. You can visit the vExpert Directory to see the list and profiles of each vExpert.
Setup NFS server on windows and setup vyos and networking on the physical ESXi host then mount NFS datasore with vmknic binding to confirm connectivity […]
Serve Keycloak or Authentik over HTTPS with a full certificate chain so vCenter or VCF identity federation works with YubiKey and passkeys. Lab setup.
Short answer: If you use Keycloak or Authentik as the OIDC identity provider for vCenter or VCF identity federation and want YubiKey or passkey (WebAuthn) logins, the IdP must be served over HTTPS, because browsers only expose WebAuthn in secure contexts. Give the IdP a certificate with a complete chain (leaf, intermediate, root), point vCenter at the HTTPS discovery URL, and upload the chain in the PingFederate-type provider wizard. Neither IdP is on Broadcom’s supported list, so treat this as a lab setup.
vCenter identity federation uses OAuth 2.0 with OpenID Connect. Broadcom TechDocs list these supported external IdPs:
| Identity provider | Supported since |
|---|---|
| AD FS | vSphere 7.0 |
| Okta | vSphere 8.0 Update 1 |
| Microsoft Entra ID | vSphere 8.0 Update 2 |
| PingFederate | vSphere 8.0 Update 3 |
Keycloak and Authentik are not in that list. They work in a homelab because they are standards-compliant OIDC providers, but Broadcom support will not help you with them. For production, use one of the IdPs above.
Password logins against an IdP running on plain HTTP may appear to work in a lab. Hardware keys, Face ID or Touch ID do not: per the Web Authentication API documentation, browsers make WebAuthn available only in secure contexts (HTTPS, with localhost as the exception). The login page served by the IdP must therefore come from an HTTPS URL with a certificate the browser trusts. vCenter also connects to the IdP’s discovery and token endpoints, so vCenter must trust the same chain.
Keycloak accepts a PEM certificate and key at startup (see the Keycloak TLS guide) and listens for HTTPS on port 8443 by default:
bin/kc.sh start \
--https-certificate-file=/path/to/certfile.pem \
--https-certificate-key-file=/path/to/keyfile.pemThe discovery URL then has the form https://keycloak.lab.local:8443/realms/<realm>/.well-known/openid-configuration.
https://authentik.lab.local:9443/application/o/<app-slug>/.well-known/openid-configuration.The new certificate may not be served immediately after the change, so verify what is actually presented before you configure vCenter.
Most failures come from an incomplete chain. Check what the IdP sends:
openssl s_client -connect keycloak.lab.local:8443 -servername keycloak.lab.local -showcerts </dev/nullIn Administration > Single Sign On > Configuration, William Lam’s lab approach uses the PingFederate provider type for a generic OIDC IdP, because its wizard asks for the OpenID address (the discovery URL) and lets you upload the IdP certificate chain. Per the PingFederate procedure, a certificate issued by a well-known public CA is trusted automatically; if you use intermediate signing authorities, include the entire chain. The same procedure requires vSphere 8.0 Update 3 or later. Also add the redirect URI shown by vCenter to the client configured in Keycloak or Authentik.
Certificate problems on the vCenter side can look similar to IdP trust issues; my articles on the vCert tool and the STS signing certificate help rule those out.
The long awaited 64GB DDR5 SODIMM memory modules from Crucial was just released this week! 😁 I was so excited about the news, I quickly splurged on a pair of these brand new modules, which are currently priced at $364 USD on Amazon! 😅💰 As of publishing this blog post, there is currently no […]
I had a customer that recently reached out asking how they could easily audit their entire ESXi infrastructure to determine which hosts was still booting using the legacy BIOS firmware, which has been deprecated and will be removed in a future vSphere release, in favor of the industry standard […]
Turning off vSAN on a cluster whose VMs live on other storage: HA, vCLS, performance service and disk group prerequisites, and a safe step-by-step order.
Short answer: Yes, if the vSAN datastore is truly empty. Anything still on vSAN becomes inaccessible the moment the service is turned off. In practice you must first move all VMs and files off vSAN, disable vSphere HA (the Turn Off button stays greyed out while HA is on), put vCLS into Retreat Mode, disable the vSAN performance service and remove the disk groups. Then turn off vSAN and re-enable HA so it uses the management network again.
A typical case: a cluster was built with vSAN, later all workloads moved to external NFS, iSCSI or FC storage, and vSAN is now empty but still configured. You want to turn it off to reclaim the disks, drop vSAN networking or tidy up licensing without taking the VMs down.
The Turn Off vSAN page in vSAN 8 TechDocs lists “verify that the hosts are in maintenance mode” as a prerequisite and warns that all VMs and data services on the vSAN datastore become inaccessible. KB 327002 adds that vSphere HA must be disabled first and that stretched and 2-node clusters must be converted back (stretch disabled, witness removed) before you start.
Duncan Epping (VMware by Broadcom) confirmed on Yellow Bricks that disabling vSAN on a cluster with running VMs on third-party storage works without workload impact, as long as vSAN holds nothing. Because that differs from the maintenance-mode prerequisite in TechDocs, treat it as a planned change: do it in a maintenance window and have a rollback plan. If you can afford rolling maintenance mode, the documented path is the conservative choice.
KB 390679 lists the common blockers:
| Blocker | Fix |
|---|---|
| vSphere HA enabled | Disable HA temporarily (Configure > Services > vSphere Availability) |
| VMs or files still on the vSAN datastore | Storage vMotion VMs; copy ISOs, templates and content library items elsewhere |
| vCLS VMs on vSAN | Put the cluster into Retreat Mode |
| vSAN performance service stats object | Turn off the performance service |
| Disk groups still claimed | Remove the disk groups (or storage pool) from every host |
das.isolationaddress to an address on the vSAN network, change it back to a management-network address.The VMware Cloud Foundation performance engineering team at Broadcom is pleased to announce an updated technical paper on tagging performance best practices for VMware vCenter 8.0 U3. The paper describes some improvements to the performance of various tagging APIs that are available for vCenter [..]
Rename or reorder vmnic aliases on ESXi with localcli deviceInternal alias list/store: update both PCI and logical aliases, then reboot.
Short answer: ESXi has no vSphere Client workflow for renaming a vmnic. The documented method is the internal localcli ... deviceInternal alias namespace: list the current aliases, store the new alias for the NIC’s PCI bus address and, for native drivers, also for its logical (uplink) address, then cleanly reboot. Work from the host console, because management networking can drop while uplinks are renumbered.
ESXi assigns vmnicN aliases from information the firmware provides. According to Broadcom KB 324534, onboard ports are named first, then ports the firmware does not describe, then ports in pluggable slots ordered by slot number. After that the names are largely static: when cards are added or removed, remaining ports keep their names and a new port gets the first free alias. A host that had a NIC replaced, a card moved to another slot, or a firmware change can therefore end up with numbering that no longer matches the other hosts in the cluster.
That is more than cosmetic. Host profiles, scripted vSwitch builds, VCF network profiles and vDS uplink mappings usually assume that vmnic0 and vmnic1 are the same physical ports on every host. Broadcom KB 409368 states there is no workflow in the vSphere environment to change the alias directly, and points to the CLI procedure below.
Open the DCUI shell or an SSH session (keep console access available) and run:
localcli --plugin-dir /usr/lib/vmware/esxcli/int/ deviceInternal alias listThe output has three columns: bus type, bus address and alias. A shortened example based on the KB:
Bus type Bus address Alias
------------------------------------
pci s00000002.00 vmnic0
pci s00000002.01 vmnic1
pci s00000008.03 vmnic7
logical pci#s00000008.03#0 vmnic7Cross-check which physical port is which with esxcli network nic list (PCI address, driver, MAC, link state) before changing anything.
A NIC controlled by a native driver has two aliases: a pci alias for the PCI function and a logical alias for the uplink object the driver creates. The logical bus address wraps the PCI address, for example pci#s00000008.03#0. If a logical alias exists for the device, rename both, otherwise the result is inconsistent.
| Bus type | Bus address format | When present |
|---|---|---|
| pci | s00000008.03 | Always |
| logical | pci#s00000008.03#0 | NICs using native drivers |
To give the port at s00000008.03 the name vmnic0 (the KB’s own swap example), run both commands:
localcli --plugin-dir /usr/lib/vmware/esxcli/int/ deviceInternal alias store --bus-type pci --alias vmnic0 --bus-address s00000008.03
localcli --plugin-dir /usr/lib/vmware/esxcli/int/ deviceInternal alias store --bus-type logical --alias vmnic0 --bus-address "pci#s00000008.03#0"If you are swapping two names, also store the old name on the other port in the same session so that no two devices end up claiming the same alias. Quote the logical address, because it contains # characters.
alias store commands, perform a clean shutdown and reboot. The new names only apply after the reboot.alias list command and esxcli network nic list again and confirm the mapping.For other everyday host commands see my esxcli commands for ESXi 8.0 reference.
Several weeks back I had shared a solution in which you can install a hardware mock VIB for Nested ESXi when using vSAN Express Storage Architecture (ESA) and VMware Cloud Foundation (VCF) to work around the vSAN ESA certified disks pre-check validations. While the majority of my testing uses […]
This plugin elevates GPU metrics to the cluster level in vSphere, which is compatible with vSphere 7 and 8. And it only supports NVIDIA GPUs at the time. We can collect the GPU utilization monitoring, temperature tracking and capacity planning. Download the Plugin […]
