by William Lam // 4 Comments
I know many in the VMware Community have upgraded to vSphere 8.0 Update 3 to play with the exciting new NVMe Tiering feature, especially for testing various workloads including deploying VMware Cloud Foundation (VCF) for homelab or testing purposes.
A question that has come up a few times now is how do I check the amount of VM memory that has been offloaded to Tier 1 memory (NVMe Tiering) versus using Tier 0 memory (DRAM)?
by William Lam // 10 Comments
Since publishing my NVMe Tiering in vSphere 8.0 Update 3 is a Homelab game changer blog post, the feedback and responses have been absolutely phenomenal!
It will be just a matter of time until we can start using RAID with NVME Tiering !
When it happens, it will be a HUGR game change!
BTW, I'm already using it on my Lab Environment!!
It's F**** awesome! pic.twitter.com/h6Np972RcQ
— Chris ✈️🇧🇷🇵🇹🇺🇸🌍 (@crismsantos) September 4, 2024
In fact, during VMware Explore, I had a number of users share with me in person that they not only updated to vSphere 8.0 Update 3 after learning about the feature but they were extremely happy that they could have their hardware was even more capable with just a software upgrade and workloads varied from general infrastructure VMs to the full VMware Cloud Foundation (VCF) stack.
Right before VMware Explore, I did have a couple of users who reported that after successfully configuring NVMe Tiering and rebooting their ESXi host, they noticed the memory capacity did not change. After sharing the details along with vm-support bundles, Engineering has identified the root cause.
by William Lam // Leave a Comment
Whether you are applying a CPU microcode update through a hardware vendor's BIOS update or an ESXi update/upgrade, verifying the CPU microcode revision within ESXi is not as easy as it could be.
Today, if you wanted to get the current CPU microcode revision from ESXi, you would need to enable SSH and then use the vsish interface to retrieve this information by running the following command:
vsish -e cat /hardware/cpu/cpuList/0 | grep "microcode" -A2
While you can retrieve the CPU microcode revision, the method and required interfaces was less than ideal, especially at scale. Given ESXi already exposes a number CPU attributes via the ESXCLI interface, which includes programmatic access when using PowerCLI, I thought it would be a nice feature to also include the CPU microcode revision as part of the output and had filed an internal feature enhancement a few years back.