WilliamLam.com

Quick Tip: Automating ESX System Resource Pool Workaround Prior to 8.0 Update 3g

by // Leave a Comment

For users running ESX 8.0 Update 3 releases prior to Update 3g, applying patches may result in a pre-check failure with a SHA-1 signature error due to memory exhaustion, as outlined in KB 433124. The knowledge base article also describes a resolution that involves increasing the memory limit for one of the ESX system resource pools by using localcli.

Since localcli is the local version of ESXCLI, the command must be executed directly on the ESX host, typically requiring SSH access. An alternative approach is to use the vSphere API, which exposes the ESX system resource pool configuration, which means we can use tools like PowerCLI. This allows the same workaround to be applied remotely without requiring SSH or direct access to the ESX host.

[Read more...]

VCF 9.1 - Deploying the VCF License Server Directly to an ESX Host

by // 2 Comments

For most customers, a single VCF License Server, which is automatically deployed as part of a VMware Cloud Foundation (VCF) or VMware vSphere Foundation (VVF) deployment, is sufficient to provide centralized license management for all VCF components. A single VCF License Server and VCF Operations instance can manage both VCF and VVF entitlements, so deploying additional VCF License Servers provides no additional benefit.


While additional VCF License Servers (LS) can certainly be deployed, the primary use cases are replacing an existing VCF LS or supporting extreme edge deployments where vCenter Server has limited connectivity to the primary data center and requires a VCF LS to be co-located with the edge deployment.

The VCF LS is provided as a virtual appliance in OVA format. The typical deployment workflow uses vCenter Server, where the VCF LS uses OVF properties, like most virtual appliances, to configure itself during deployment.

With that said, if you need to deploy the VCF LS directly to an ESX host, this is certainly possible using OVF Tool, which can inject the required OVF properties as part of the deployment workflow.

[Read more...]

VCF 9.1 - Are You Using the Correct ESXCLI Command to Enable NVMe Tiering?

by // 2 Comments

Historically, enabling NVMe Tiering prior to VMware Cloud Foundation (VCF) 9.1 was not very user friendly, as it required users to remember three distinct ESXCLI commands.

# Enable or Disable NVMe Tiering
esxcli system settings kernel set -s MemoryTiering -v TRUE

# Configure the Tiering % 
esxcli system settings advanced set -o /Mem/TierNvmePct -i 100

# Configure NVMe device for with NVMe Tiering
esxcli system tierdevice create -d /vmfs/devices/disks/${NVME_TIERING_DEVICE}

By now, most users have probably made a mental note of these commands, with some even incorporating them into their automated ESX Kickstart deployments (example), so it is something you do not have to remember.

VCF 9.1 introduces a new method for enabling and configuring NVMe Tiering that is significantly simpler and no longer requires a system reboot. As a result of these improvements, the ESXCLI commands used in previous releases will no longer properly enable NVMe Tiering in VCF 9.1 and later.

I have seen an increasing number of users, both internally and externally, report that they have enabled NVMe Tiering, only to discover that it was never properly activated due to the use of the legacy ESXCLI commands.


Users will typically share a screenshot from vCenter Server similar to the one above, and there are two dead giveaways that NVMe Tiering was not properly enabled.

  • The first is the traditional memory capacity view, which does not reflect the combined memory capacity based on the configured NVMe Tiering ratio.
  • The second is the new Memory Tiering widget in the vSphere UI, where the Tier 1 capacity, representing the NVMe Tiering device capacity, shows a value of 0.

[Read more...]