A DR cluster was sized using only the primary production VM disk allocation. When forecasting storage runway for DR expansion, which DR-specific capacity component must be added?
Select an answer to reveal the explanation.
Short Explanation
Think of DR sizing like packing a suitcase: if you only pack the clothes you wear at home, you forget the raincoat and emergency snacks. Your DR forecast must add replica data, snapshot space, and failover headroom, not just the primary production disk number. The trap is treating the primary VM allocation as the whole DR footprint.
Full Explanation
DR storage runway must model the actual bytes resident on the DR cluster, not a copy of the production allocation. Replicated VM data consumes capacity because protection domains create and maintain remote copies; local snapshots on the DR cluster consume additional capacity as they age; failover headroom is needed because workloads may run at DR during a failure and may generate writes, logs, and temporary files. A forecast that uses only the primary VM disk allocation understates used capacity and produces a misleading runway. The primary site's CVM metadata and hypervisor reservation overhead describes management plane and host reservation consumption, which is not the missing DR workload capacity being asked for. The primary cluster's SSD cache and metadata disk capacity refers to storage tier resources on the source cluster, not the remote replica, snapshot, or failover space on the DR cluster. Local VM memory and vCPU reservation values copied from production are compute resources, not storage capacity, so they do not correct a storage runway forecast. Exam caveat: distinguish source-cluster capacity metrics from DR-cluster resident capacity when forecasting expansion. Operational check: compare the DR cluster's used capacity with the sum of replicated VM disks, DR-local snapshots, and an agreed failover growth buffer before approving additional nodes.