After recently sharing my automation for deploying the vDefend Security Services Platform (SSP) 5.2 Installer, the next logical step was automating the configuration of the SSP Installer and deployment of an SSP Instance. To make this easy and reusable, I have created a new PowerShell Module for vDefend SSP that automates these workflows from end to end.
After successfully deploying the vDefend Security Services Platform (SSP) 5.2 Installer, which I recently built some automation for, the next step is to deploy an SSP Instance. I was surprised to see there was a fairly hefty minimum storage pre-check of a little over 3.5TB, something I certainly hope my lab never gets close to consuming! Since thin provisioning is already used by default, ideally the minimum storage requirement should simply reflect what is needed for the selected form factor.
😅Fortunately, there is a workaround to skip the minimum storage pre-check and allow us to proceed with the SSP Instance deployment.
Disclaimer: This is not officially supported by Broadcom, please use only in a non-production environment for lab and learning purposes.
Unfortunately, one of my consumer-grade NVMe SSD devices that I had configured for NVMe Tiering (Memory Tiering) in my VMware Cloud Foundation (VCF) 9.1.1 environment had recently degraded. While vCenter Server had raised an alarm stating “NVMe Memory Tiering device is not healthy.”, I had dismissed it since the alarm did not provide any additional details about the underlying issue.
In VCF 9.1, NVMe Tiering usage can be conveniently viewed inn the vSphere UI under the Memory tile for either a selected ESX host or vSphere Cluster, which summarizes both Tier 0 (DRAM) and Tier 1 (NVMe Tiering) usage.
When it comes to understanding the actual health of an NVMe device used for NVMe Tiering, I was not sure whether looking at the SMART data was still the recommended approach or if there was a better way?