> ## Content Index > Fetch the complete content index at: https://www.mohammadsiddiqui.com/llms.txt > Use this file to discover other available public pages before exploring further. # The Sources Behind the Design Gaps Checklist What Each One Is, and When You'd Actually Read It - URL: https://www.mohammadsiddiqui.com/the-sources-behind-the-design-gaps-checklist-what-each-one-is-and-when-youd-actually-read-it/ - Published: 2026-08-22T08:52:42.000Z - Updated: 2026-08-29T03:59:35.000Z - Author: Mohammad Siddiqui *Twelve Broadcom documents sit behind the eighteen gaps in the checklist. Here's what each one covers, which gap it backs, and the reason you'd open it yourself.* The checklist cites twelve Broadcom sources. Most people won't click any of them, which is a shame, because a few are worth reading end to end and the rest are worth knowing exist so you can find them when a specific question comes up. This is the annotated version: what each document actually is, what it covers, which gaps it backs, and when you'd go to it yourself. One thing worth saying up front about source types. Broadcom publishes in three broad categories and they age differently. Blog posts are point-in-time and don't get revised, so a post from February describes February. TechDocs pages are living documents that change without announcement. Security advisories get revised in place with version numbers (VMSA-2026-0006.1, for instance). If you're citing something in an HLD, note which type you're citing and when you checked it the difference matters when someone reads your document a year later. ## Upgrade and Migration **VCF 5.2.x to 9.1 Upgrade Guide** Broadcom blog, 5 June 2026 · Backs Gaps 11 and 12 **Link:** [blogs.vmware.com/cloud-foundation/2026/06/05/modernizing-infrastructure-vmware-cloud-foundation-5-2-x-to-9-1-upgrade-guide](https://blogs.vmware.com/cloud-foundation/2026/06/05/modernizing-infrastructure-vmware-cloud-foundation-5-2-x-to-9-1-upgrade-guide/?ref=mohammadsiddiqui.com) This is the most operationally honest document Broadcom has published on the 9.x transition. It walks the ordered upgrade sequence, names the preconditions that actually fail deployments, and reads like it was written by people who have carried customers through it rather than by someone summarising a product spec. Two things in it feed the checklist directly. The strictly-lowercase FQDN requirement, which sounds like trivia until a single capital letter in a DNS record breaks VCF Operations integration mid-deployment. And the syslog change, where unencrypted vCenter syslog on port 514 is blocked in 9.1 and logging moves to TLS on 1514\. The second one is the more dangerous of the two because it fails quietly nothing errors, logs just stop arriving at your SIEM. When to read it: before any 5.2.x upgrade, in full. Also worth a skim even if you're greenfield, because the preconditions section tells you what the platform is fussy about. ## Lifecycle and Patching **Faster Security Patching with Fewer Disruptions in VCF 9.1** Broadcom blog, 30 June 2026, by Adam Hawley and Luca Camarda · Backs Gaps 4 and 5 **Link:** [blogs.vmware.com/cloud-foundation/2026/06/30/security-patching-in-vcf-9](https://blogs.vmware.com/cloud-foundation/2026/06/30/security-patching-in-vcf-9/?ref=mohammadsiddiqui.com) The three-layer patching model comes from here. Management plane, control plane, data plane, each with a different disruption profile and a different mechanism. It also carries the time-to-exploit numbers that make the whole argument land: over a year in 2020, around 21 days in 2025, under two days in 2026\. The post announces a companion whitepaper on non-disruptive patching, which goes deeper on the same model. The reason this backs a design gap rather than just being interesting: once you accept that patching is three mechanisms rather than one, a change management process that treats them identically stops making sense. That's Gap 4. When to read it: before you write or revise patching policy, and again before you take that policy to a change advisory board. It's the source that makes the case for you. **Strengthen Zero Trust Platform Security and Resilience with VCF 9.1** Broadcom blog, 5 May 2026 · Backs Gaps 5 and 10 **Link:** [blogs.vmware.com/cloud-foundation/2026/05/05/platform-security-vcf-9-1](https://blogs.vmware.com/cloud-foundation/2026/05/05/platform-security-vcf-9-1/?ref=mohammadsiddiqui.com) A broad security roundup that happens to contain two specific things the checklist needs. First, that Live Patch extends to TPM-enabled hosts in 9.1 the gap that previously meant your most security-hardened hosts had your worst patching experience. Second, that the VIDM to Identity Broker migration is a scripted, non-disruptive workflow that runs after the upgrade completes rather than during it. That second detail is why Gap 10 exists. Because the migration is easy and non-disruptive, it's equally easy to carry years of accumulated group sprawl straight across without anyone stopping to ask whether it should survive. When to read it: during security architecture design, and specifically before planning an identity migration. ## Storage and Memory **More Memory, Less Effort: Configuring Memory Tiering in VCF 9.1** Broadcom blog, 19 May 2026, by Dave Morera · Backs Gap 14 **Link:** [blogs.vmware.com/cloud-foundation/2026/05/19/more-memory-less-effort-configuring-memory-tiering-in-vcf-9-1](https://blogs.vmware.com/cloud-foundation/2026/05/19/more-memory-less-effort-configuring-memory-tiering-in-vcf-9-1/?ref=mohammadsiddiqui.com) A configuration walkthrough rather than a concept piece. It covers enabling memory tiering through vSphere Configuration Profiles, the one-NVMe-minimum requirement, the software mirroring option added in 9.1, and the fact that applying the configuration is non-disruptive hosts enter maintenance mode in sequence, VMs migrate off, no reboot needed. The detail the checklist leans on is the distinction between VM Memory Reservation and "Reserve all guest memory (All Locked)". Reservation is a scheduler guarantee and tiering still applies. All Locked pins pages in DRAM at the hardware level and excludes the VM from tiering entirely. If your consolidation numbers come in under projection, this is the first thing to check. When to read it: before enabling tiering on any cluster, and when tiering results don't match the What-If projection. **vSAN Compression and Global Deduplication in VCF 9.1** Broadcom blog, 7 May 2026, by Pete Koehler · Backs Gap 13 **Link:** [blogs.vmware.com/cloud-foundation/2026/05/07/vsan-compression-and-global-deduplication-in-vcf-9-1](https://blogs.vmware.com/cloud-foundation/2026/05/07/vsan-compression-and-global-deduplication-in-vcf-9-1/?ref=mohammadsiddiqui.com) Covers the move from LZ4 to zStandard compression for vSAN ESA, and global deduplication reaching general availability in 9.1 after being limited-availability in 9.0\. It gives the supported scope: HCI clusters from 3 to 64 hosts, vSAN storage clusters, and compatibility with data-at-rest encryption. It also names what isn't supported yet, which is the part that matters for design. Stretched clusters and 2-node topologies are excluded from global dedup. If your capacity model assumes dedup savings on a stretched cluster, the model is wrong, and it's much cheaper to find that out before the business case goes to a steering committee than after. When to read it: before building any storage capacity or TCO model that assumes data reduction. ## Hardware and Certification **VCF 9.0 Server Certification: Preserving Your Hardware Investment** Broadcom blog, 25 February 2026, by Sandeep Byreddy and Rakesh Radhakrishnan · Backs Gaps 16 and 18 **Link:** [blogs.vmware.com/cloud-foundation/2026/02/25/vcf-9-0-server-certification-preserving-your-hardware-investment-and-giving-the-best-roi](https://blogs.vmware.com/cloud-foundation/2026/02/25/vcf-9-0-server-certification-preserving-your-hardware-investment-and-giving-the-best-roi/?ref=mohammadsiddiqui.com) The single most useful document on this list for anyone with a hardware budget conversation coming up. It explains how certification actually works evaluated at both component level and server-model level, with automatic carry-forward where underlying components remain supported and gives the number: 3,148 server models listed for ESXi 9.0/9.1 after the majority of 8.x-certified servers carried forward. It also explains the three Broadcom Compatibility Guide listing states, which most people don't know exist. "VCF Supported" is the default. "VCF Supported, Confirm w/Vendor" means Broadcom supports the software on that hardware but you need to confirm hardware support separately with the OEM. Unlisted generally means a core component has hit end of service life. And it notes the vSAN hardware requirement reduction of nearly 50 percent, which means a lot of existing servers can run vSAN by adding NVMe rather than being replaced. When to read it: before budgeting a refresh. The answer to "do we need new servers for 9.x" starts here, and for a lot of estates the answer is smaller than expected. ## Compliance and Recovery **Continuous Compliance, Integrated Cyber Recovery and Enhanced Platform Security** Broadcom blog, 5 May 2026 · Backs Gaps 8 and 9 **Link:** [blogs.vmware.com/cloud-foundation/2026/05/05/continuous-compliance-integrated-cyber-recovery-and-enhanced-platform-security-for-vcf-9-1](https://blogs.vmware.com/cloud-foundation/2026/05/05/continuous-compliance-integrated-cyber-recovery-and-enhanced-platform-security-for-vcf-9-1/?ref=mohammadsiddiqui.com) Covers Advanced Cyber Compliance and the Cyber Recovery blueprint, including the Isolated Recovery Environment pattern. The important architectural point for Gap 9 is that Fleet DR and Cyber Recovery are different blueprints solving different failure modes. Fleet DR handles infrastructure loss. Cyber Recovery handles a compromised estate that is still technically running, where the problem is that you can't trust what's there. Most estates design and test one of these and quietly assume it covers the other. It doesn't. When to read it: during recovery architecture design, and before any regulator or auditor asks what happens after ransomware. **Securing the Foundation: VCF 9.1 STIG Compliance** Broadcom blog, 14 July 2026 · Backs Gap 8 **Link:** [blogs.vmware.com/cloud-foundation/2026/07/14/securing-the-foundation-vmware-cloud-foundation-9-1-stig-compliance](https://blogs.vmware.com/cloud-foundation/2026/07/14/securing-the-foundation-vmware-cloud-foundation-9-1-stig-compliance/?ref=mohammadsiddiqui.com) Written for US Department of Defense contexts, covering Security Technical Implementation Guide hardening baselines on VCF. Worth reading even if STIG doesn't apply to you, because it shows what compliance-as-continuous-operations looks like when the requirements are at their most demanding. The direction APRA and DORA supervision is heading looks a lot like this. When to read it: if you're in defence or government, immediately. If you're in financial services, read it as a preview of where your own regulator's expectations are going. ## Consumption and Adoption **VCF Automation at Explore 2026** Broadcom blog, 3 August 2026 · Backs Gaps 1, 2, 3 and 6 **Link:** [blogs.vmware.com/cloud-foundation/2026/08/03/the-future-of-cloud-infrastructure-deep-dive-into-vmware-cloud-foundation-automation-at-explore-2026](https://blogs.vmware.com/cloud-foundation/2026/08/03/the-future-of-cloud-infrastructure-deep-dive-into-vmware-cloud-foundation-automation-at-explore-2026/?ref=mohammadsiddiqui.com) Nominally a session guide, but useful for what its structure reveals. Broadcom runs separate expert roundtables for building a self-service private cloud and for consuming one, which is a tacit acknowledgment that provider-side design and consumer-side experience are different disciplines. That split is the whole basis of Gaps 1 through 3. It also introduces App Stack Formation, which lets a provider admin turn a running VM into a reusable catalog item. That capability is what makes Gap 2 solvable rather than just identifiable. When to read it: when designing tenancy and self-service, particularly if you have a large existing estate that needs to end up in the catalog. **VCF Breakroom Chats Episode 92: Install and Brownfield Import** Broadcom video/blog, 3 August 2026, with Puneet Chawla · Background for Gaps 1 and 16 **Link:** [blogs.vmware.com/cloud-foundation/2026/08/03/vcf-breakroom-chats-episode-92-simplifying-vcf-9-1-install-and-brownfield-import](https://blogs.vmware.com/cloud-foundation/2026/08/03/vcf-breakroom-chats-episode-92-simplifying-vcf-9-1-install-and-brownfield-import/?ref=mohammadsiddiqui.com) Product management walking through the 9.1 Installer and the brownfield import path that converts existing vCenter estates into VCF domains. Twenty minutes, conversational, and the current authoritative narrative on both paths. Useful because most VCF adoption starts from infrastructure that already exists rather than from empty racks. When to read it: before scoping any brownfield adoption, and before assuming a migration is required where an import might do. ## The Living Documents **VCF 9.1 Design (Modern Private Cloud design guide)** Broadcom TechDocs, continuously updated · Backs Gap 15 **Link:** [techdocs.broadcom.com VCF 9.1 Design](https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/design.html?ref=mohammadsiddiqui.com) The reference design documentation, structured around the Modern Private Cloud model: consumption, operations, security and compliance, virtual infrastructure, physical infrastructure. The same five-layer structure the checklist and its logical diagram are organised around, which is deliberate when your HLD, the official guide, and the Designs and Solutions deck all share a skeleton, reviews get faster and updates map cleanly. The six supported network connectivity models live here, which is what Gap 15 points at. When to read it: continuously. This is the document your HLD structure should mirror. **VCF 9.1 Release Notes** Broadcom TechDocs, continuously updated · Backs Gap 7 **Link:** [techdocs.broadcom.com VCF 9.1 Release Notes](https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/release-notes.html?ref=mohammadsiddiqui.com) Not a launch-day artefact. In the 9.x era this is a living document covering the Bill of Materials, the 9.1.0.x patch stream, async component releases, and known issues. Four sections carry real design signal: the BOM is the authoritative version matrix your HLD should trace to, the patch stream tells you your fleet's monthly target state, async releases are how capability arrives between platform versions, and known issues are field experience someone else already paid for. Gap 7 exists because this document changes and most estates have nobody explicitly watching it. When to read it: monthly, on a schedule, with a named owner. Fifteen minutes against your estate is enough. ## If You Only Read Three For an architect starting a VCF 9.1 design from scratch: the Modern Private Cloud design guide for structure, the server certification post for the hardware conversation, and the 5.2.x to 9.1 upgrade guide for what the platform is actually fussy about. Those three cover more ground per hour than anything else on the list. For someone already running 9.1: the release notes on a monthly rhythm, the patching post before your next change policy review, and the memory tiering configuration post if you have tiering anywhere in the estate.