Add value and cost optimisation section to the VCF library (#15)

Claude-Session: https://claude.ai/code/session_01GnmfunFwAkafLv2mJCaHC3

Co-authored-by: Claude <noreply@anthropic.com>

Author: Kninsay

src/content/articles/value/building-the-cost-case.mdx

@@ -0,0 +1,87 @@
+---
+title: "Building a cost case for VCF 9 optimisation without inventing numbers"
+description: "A savings figure that cannot be traced to measured data and written assumptions will not survive a finance review. The method used in this section: baseline from VCF Operations, levers applied in a fixed order, an assumptions table, and results shown at a pessimistic value as well as the expected one."
+category: value
+order: 11
+versions: ["9.0", "9.1"]
+level: Overview
+pubDate: 2026-11-02
+kbs: []
+sources:
+  - title: "VMware Cloud Foundation helps you optimally size VMs (potential savings metrics)"
+    url: "https://blogs.vmware.com/cloud-foundation/2025/08/12/vmware-cloud-foundation-helps-you-optimally-size-vms-and-keep-your-infrastructure-and-workloads-running-smoothly/"
+    by: "VMware Cloud Foundation blog"
+  - title: "Meet MTAT: memory tiering assessment for VCF 9"
+    url: "https://blogs.vmware.com/cloud-foundation/2026/07/31/meet-mtat-your-zero-friction-path-to-memory-tiering-in-vmware-cloud-foundation-9-0/"
+    by: "VMware Cloud Foundation blog"
+  - title: "Counting cores for VMware Cloud Foundation and vSphere Foundation"
+    url: "https://knowledge.broadcom.com/external/article/313548/counting-cores-for-vmware-cloud-foundati.html"
+    by: "Broadcom KB"
+  - title: "Memory tiering in VCF 9: a closer look at the TCO equation"
+    url: "https://www.wwt.com/blog/memory-tiering-in-vmware-cloud-foundation-9-a-closer-look-at-the-tco-equation"
+    by: "WWT"
+---
+
+<InShort>
+Most optimisation proposals fail review for the same reason: the number at the bottom cannot be traced back to anything. A cost case that holds up has four parts. A **baseline** measured from the estate. **Levers applied in order**, so the same capacity is not saved twice. An **assumptions table** that a reviewer can challenge line by line. And results shown at a **pessimistic** value next to the expected one. Express savings in cores, TiB and hosts first, then convert to money with the customer's own prices.
+</InShort>
+
+## The baseline
+
+Take every figure from a system of record, not from memory or a slide.
+
+| Figure | Where it comes from |
+|---|---|
+| Licensed cores and raw vSAN TiB | VCF Operations licence usage, or the counting script (<KB id={313548} />) |
+| Hosts per cluster and what each cluster runs out of first | VCF Operations capacity, time remaining per resource |
+| Allocated and active memory per cluster | VCF Operations, or MTAT for a tiering assessment |
+| Reclaimable capacity by category | Capacity > Reclaim, potential savings |
+| Oversized and undersized VMs | Optimisation reports |
+| Hands-on hours for recurring tasks | Change records |
+
+Record the date and the history window for each figure. A right-sizing result based on six weeks of data needs to say so.
+
+## Apply the levers in order
+
+Each lever changes the input to the next. Reclaiming an idle VM removes memory that right-sizing would otherwise also count, and memory tiering sized before right-sizing will be sized for waste. Applying them in a fixed order stops double counting.
+
+```mermaid
+flowchart TD
+  A[Measured baseline] --> B[Reclaim: powered-off, snapshots, orphaned disks, idle]
+  B --> C[Right-size: memory first, then vCPU]
+  C --> D[Recompute host count per cluster]
+  D --> E[Memory tiering where active memory fits DRAM]
+  E --> F[Merge clusters where nothing forces separation]
+  F --> G[CPU and drive choice at the next refresh]
+  G --> H[Cores and raw TiB at renewal]
+```
+
+Recompute the host count after each step, with the failover reserve included. The result of each step is a host count, a licensed core count and a raw TiB figure. Money comes last.
+
+## The assumptions table
+
+Every number in the case that is not measured is an assumption. Write them down where the reviewer can see them, with the source and the value you would use if you were wrong in the unhelpful direction.
+
+| Assumption | Expected | Pessimistic | Basis |
+|---|---|---|---|
+| Active memory share | Measured | Measured plus 10 points | MTAT, 30 days including month-end |
+| vSAN data reduction | Measured | 1.0:1 | Capacity view on a comparable cluster |
+| Share of oversized memory that owners agree to remove | From a pilot with a few owners | Half the pilot figure | Pilot results |
+| Free raw capacity kept | 30% | 30% | Design standard |
+| Per-core price | From quote | From quote | Reseller quote, dated |
+
+## Show both results
+
+Present the pessimistic result first. If the change is still worth doing on pessimistic assumptions, the decision is easy. If it is only worth doing on expected assumptions, say so, and say what measurement would settle it. The [memory tiering example](/vcf/library/value/nvme-memory-tiering/) shows the pattern: a three-host saving on measured active memory of 25%, with a check that the design still holds with a host failed.
+
+## One-time costs and timing
+
+Savings in a VCF estate arrive at specific events. Core counts fall at renewal or when hosts leave the estate. Raw TiB falls at the next storage purchase. Set against them the one-time costs: NVMe devices for tiering, migration effort to merge clusters, engineering time for right-sizing reviews, and any change to third-party licences that follow cluster boundaries. A case that shows savings in the year they land is more credible than one that annualises everything from day one.
+
+## Using vendor figures
+
+Broadcom quotes up to 40% lower total cost of ownership for memory tiering and publishes benchmark overheads. Partners publish models with their own price assumptions, such as WWT's comparison at roughly 40 US dollars per GB of DRAM and 1 dollar per GB of NVMe in early 2026. These are useful for deciding whether to investigate. They are not evidence for a specific estate. Cite them as context and build the case from your own baseline.
+
+<Callout title="A note on these examples">
+Every worked example in this section is constructed to show the arithmetic. None of them describe a real estate or customer. The method is the part to reuse. See also [decisions with evidence](/vcf/library/leadership/decisions-with-evidence/) for how to write the recommendation itself.
+</Callout>

src/content/articles/value/consolidation-and-headroom.mdx

@@ -0,0 +1,76 @@
+---
+title: "Consolidation: fewer, fuller clusters without losing failover headroom"
+description: "Every cluster carries its own failover reserve, and every VCF instance carries its own management stack. Merging small clusters, choosing the capacity model deliberately and separating compute from storage growth reduce the hosts you license without removing the headroom you need."
+category: value
+order: 9
+versions: ["5.x", "9.0", "9.1"]
+level: Practitioner
+pubDate: 2026-11-02
+kbs: []
+sources:
+  - title: "Configure admission control (vSphere availability)"
+    url: "https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-availability/GUID-C4059DB9-D673-45CB-918C-68C87FEB060A.html"
+    by: "VMware"
+  - title: "VMware Cloud Foundation helps you optimally size VMs (capacity models)"
+    url: "https://blogs.vmware.com/cloud-foundation/2025/08/12/vmware-cloud-foundation-helps-you-optimally-size-vms-and-keep-your-infrastructure-and-workloads-running-smoothly/"
+    by: "VMware Cloud Foundation blog"
+  - title: "vSAN storage clusters in VCF 9.1"
+    url: "https://blogs.vmware.com/cloud-foundation/2026/05/12/vsan-storage-clusters-in-vcf-9-1/"
+    by: "VMware Cloud Foundation blog"
+  - title: "Performance best practices for vSphere 9.0 (power management)"
+    url: "https://www.vmware.com/docs/vsphere-esxi-vcenter-server-90-performance-best-practices"
+    by: "VMware"
+---
+
+<InShort>
+A cluster that must survive a host failure keeps a host's worth of capacity in reserve, and that reserve is licensed like any other core. Two four-host clusters hold two hosts in reserve. One seven-host cluster running the same work holds one. Merging small clusters, where nothing forces them apart, is one of the simplest ways to remove a host. In 9.x two further levers apply: 9.1 lets compute-only clusters mount remote vSAN storage, so compute and storage can grow separately, and fewer VCF instances means fewer management stacks to run.
+</InShort>
+
+<Compare rows={[
+  ["Failover reserve", "Per cluster, through HA admission control", "The same"],
+  ["Storage and compute growth", "Tied together in HCI clusters. vSAN Max (5.2) for disaggregated storage.", "9.1 storage clusters, mountable by compute-only and HCI clusters of either vSAN architecture"],
+  ["Management overhead per site", "SDDC Manager, vCenter and NSX per instance, plus the Aria stack", "The same per instance, with VCF Operations and Automation shared across the fleet"],
+]} />
+
+## The reserve is per cluster
+
+HA admission control holds back capacity so that VMs from a failed host can restart elsewhere. With the cluster resource percentage policy you set that reserve directly. With one host failure to tolerate, the reserve is roughly one host's share of the cluster, which is a quarter of a four-host cluster and an eighth of an eight-host one.
+
+### Worked example: merging two clusters
+
+This example is constructed. Two clusters of four hosts each, every host with two 16-core CPUs. Each is designed for one host failure, so each runs on three hosts' worth of capacity.
+
+| | Two clusters | One merged cluster |
+|---|---|---|
+| Hosts | 4 + 4 = 8 | 7 |
+| Usable hosts with one failure | 3 + 3 = 6 | 6 |
+| Licensed cores | 256 | 224 |
+
+The merged cluster delivers the same usable capacity with one host fewer, 32 cores less to license. The calculation holds only if nothing requires the two clusters to stay separate. Check for:
+
+- **Separation required by someone else's licence.** Some database and operating system vendors license by the hosts a VM could run on. Moving those VMs into a larger cluster can raise that cost by more than the host saved.
+- **Compliance boundaries.** Payment card or classified workloads may need their own cluster by policy.
+- **Hardware mismatch.** Different CPU generations need EVC, and vSAN clusters need compatible devices and the same architecture.
+- **Failure tolerance.** A larger cluster loses the same single host, but a cluster-wide problem now affects more workloads. Consider whether one larger failure domain is acceptable.
+
+## Choose the capacity model deliberately
+
+VCF Operations can plan capacity by **demand**, from measured use, or by **allocation**, from configured sizes and overcommit ratios such as 8 vCPUs per core. Demand-based planning usually fits more work on each host. Allocation-based planning is easier to explain to application owners and protects against everyone using their full allocation at once. Neither is wrong, but the ratio you choose sets the host count. A cluster planned at 4 vCPUs per core needs twice the cores of one planned at 8 for the same VMs. Pick the ratio from measured CPU ready time and contention at current density, then raise it in steps while watching those figures.
+
+## Grow storage and compute separately
+
+In an HCI cluster, more storage means more disks in the same hosts, and when the hosts are full it means more hosts, each with cores to license. The 9.1 storage cluster model lets compute-only and HCI clusters mount remote vSAN datastores of either architecture. A cluster that needs capacity but not CPU can take it from a storage cluster. Check how storage cluster hosts are licensed under your agreement before relying on this, since the comparison depends on it.
+
+## Fewer management stacks
+
+Each VCF instance carries its own management domain with SDDC Manager, vCenter and NSX. VCF Operations and VCF Automation are shared across a fleet. Every instance therefore costs management hosts, cores and patching effort before it runs a single workload. Before creating a new instance for a new site or team, check whether a workload domain in an existing instance meets the need. The [VCF 9 mental model](/vcf/library/architecture/vcf9-mental-model/) explains the fleet, instance and domain boundaries.
+
+## Power
+
+The default host power policy is Balanced, which saves energy at little performance cost for most workloads. The vSphere performance guide recommends setting the BIOS to OS-controlled power management so ESX can use the processor's power states. Distributed Power Management can power off hosts that are not needed and bring them back as load rises. It reduces energy cost, not licence cost, because the powered-off hosts remain licensed.
+
+## Pitfalls
+
+- **Removing the reserve to hit a target.** A cluster with no failover headroom turns the next host failure into an outage. Show the reserve in the business case rather than hiding it.
+- **Consolidating before right-sizing.** Merge after [right-sizing](/vcf/library/value/rightsizing-with-vcf-operations/) and [reclamation](/vcf/library/value/reclaiming-idle-capacity/), or you will plan the merged cluster around waste.
+- **Forgetting maintenance.** Patching takes a host out of service. A cluster sized exactly for one failure cannot tolerate a failure during patching.

src/content/articles/value/core-counting-and-cpu-choice.mdx

@@ -0,0 +1,78 @@
+---
+title: "Counting cores: the 16-core floor, CPU choice and host count"
+description: "Every CPU is licensed for at least 16 cores, disabled cores still count, and one host's worth of cores is always held back for failover. Together these rules decide which server build carries a workload on the fewest licensed cores."
+category: value
+order: 2
+versions: ["5.x", "9.0", "9.1"]
+level: Practitioner
+pubDate: 2026-11-02
+kbs: [313548]
+sources:
+  - title: "Counting cores for VMware Cloud Foundation and vSphere Foundation"
+    url: "https://knowledge.broadcom.com/external/article/313548/counting-cores-for-vmware-cloud-foundati.html"
+    by: "Broadcom KB"
+  - title: "VMware Cloud Foundation 9 FAQ (VCF Edge minimums)"
+    url: "https://www.vmware.com/docs/vmware-cloud-foundation-9-0-general-faqs"
+    by: "VMware"
+  - title: "VMware 72-core minimum vs 16-core CPU floor"
+    url: "https://licenseware.io/major-update-for-vmware-customers-min-licensing-requirement-increases-from-16-to-72-cores/"
+    by: "Licenseware"
+  - title: "VCF 9 licensing explained: core counting and the vSAN TiB entitlement"
+    url: "https://drpranayjha.com/vcf-9-licensing-consumption-model/"
+    by: "Pranay Jha"
+---
+
+<InShort>
+VCF and VVF count **physical cores** on every licensed host, with a minimum of **16 per CPU**. A host with two 8-core CPUs is licensed for 32 cores, not 16. Cores disabled in the BIOS still count, so turning them off saves nothing (<KB id={313548} />). Hyper-threads are not counted. The cheapest build for a workload is the one that needs the fewest licensed cores **after** you set aside a host for failover, and that is rarely the smallest CPU or the largest one.
+</InShort>
+
+<Compare rows={[
+  ["Counting unit", "Per core under the 2024 subscriptions. Older estates: per CPU, or per component.", "Per core, reported from VCF Operations"],
+  ["Minimum per CPU", "16 cores", "16 cores. VCF Edge has its own rules (8 cores per CPU minimum, per the 9.x FAQ)."],
+  ["How you check", "PowerCLI counting script from <a href='https://knowledge.broadcom.com/external/article/313548' target='_blank' rel='noopener'>KB 313548</a>", "The same script before purchase. VCF Operations licence usage after."],
+]} />
+
+## The three rules that decide the count
+
+**The floor.** Any CPU with fewer than 16 cores is billed as 16. Single-socket 12-core hosts and dual-socket 8-core hosts pay for cores they do not have. Edge sites and small branch clusters are where this shows up most, because they tend to use small CPUs.
+
+**Disabled cores count.** The KB is explicit that the counting script needs all cores enabled, and that licensing is based on the physical cores present. Buying a 32-core CPU and disabling half of it to save licence cost does not work.
+
+**Failover capacity is licensed too.** A cluster designed to survive one host failure carries one host's worth of cores that does no work in normal running. The larger each host, the larger that reserve. With three hosts it is a third of the cluster. With eight hosts it is an eighth.
+
+## Worked example: same workload, five server builds
+
+This example is constructed. The workload needs **120 physical cores** of capacity with one host failed (N+1). It assumes every CPU option delivers the same work per core, which is not true in practice: compare per-core benchmark results for the actual CPU models before you use this method on a real purchase.
+
+| Host build | Cores per host | Hosts (N+1) | Licensed cores |
+|---|---|---|---|
+| 2 × 12-core | 24 (licensed 32) | 6 | 192 |
+| 2 × 16-core | 32 | 5 | 160 |
+| 2 × 20-core | 40 | 4 | 160 |
+| 2 × 24-core | 48 | 4 | 192 |
+| 2 × 32-core | 64 | 3 | 192 |
+
+The host count is the number needed to reach 120 cores, rounded up, plus one. For 2 × 20-core hosts that is 120 ÷ 40 = 3, plus one spare, so 4 hosts and 160 cores.
+
+Three things stand out. The 12-core build pays for 48 cores that do not exist, a third more than its physical count. The 32-core build reaches the target with the fewest hosts but holds 64 cores in reserve, so it licenses as many cores as the 12-core build. The 20-core build lands in the middle and needs the fewest licensed cores and fewest hosts at the same time. Change the target to 100 cores and the answer moves, which is why the calculation belongs in every hardware decision and not in a rule of thumb.
+
+## What else changes the answer
+
+- **Memory per host.** If the cluster runs out of memory before CPU, the core count is set by how much memory each host can hold. [NVMe memory tiering](/vcf/library/value/nvme-memory-tiering/) changes that limit.
+- **vSAN entitlement.** Fewer licensed cores also means less included vSAN capacity, at 1 TiB per VCF core. Check the result against the [vSAN entitlement](/vcf/library/value/vsan-entitlement/) before you settle on a build.
+- **vSAN protection.** From 9.1, vSAN ESA picks RAID-5 (2+1) for three to five hosts and RAID-6 (4+2) from six hosts. Both cost 1.5 times the data in raw capacity. Before 9.1, six or more hosts could use RAID-5 (4+1) at 1.25 times. See [space efficiency](/vcf/library/value/vsan-esa-space-efficiency/).
+- **Failure domains.** A design that needs to survive a host in maintenance and a host failure at the same time needs N+2, which favours more, smaller hosts.
+
+## Order minimums
+
+In April 2025 the trade press reported a 72-core minimum per order line, citing a distributor memo. Broadcom's published documentation, including the counting KB, states only the 16-core per CPU rule, and a Broadcom spokesperson told the German publication iX that the 16-core minimum had not changed. Treat any minimum order quantity as a commercial term and confirm it with your reseller for the specific quote.
+
+<Callout type="warn">
+Run the counting script against the real hosts before renewal. Estates that grew by adding hosts with whatever CPU was available often contain a few small-CPU hosts that are billed at the 16-core floor. Replacing or retiring them can reduce the count without touching the workloads.
+</Callout>
+
+## Pitfalls
+
+- **Counting logical processors.** Logical processor counts include hyper-threads and double the real figure on most hosts. Count physical cores with the script or from the host hardware summary.
+- **Ignoring the failover host in the business case.** A plan that removes two hosts from a five-host cluster also removes the ability to patch one host while tolerating a failure.
+- **Comparing CPUs on core count alone.** Two CPUs with the same core count can differ widely in throughput per core. Licence cost per unit of work is the number to compare.