---
title: "Host Memory Mirroring: Capacity and the Pages Actually Protected"
description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/host-memory-full-partial-mirroring-capacity-placement"
last-updated: "2026-10-20"
---

# Host Memory Mirroring: Capacity and the Pages Actually Protected

Leviathan Systems — Technical content
Published 2026-10-20; updated 2026-10-20.

Compare host-memory mirroring offers in two steps: account for the capacity consumed by duplicate copies, then establish which required data actually resides in the mirrored range. Full mirroring halves distinct addressable capacity. Partial mirroring can retain more distinct capacity, but a mirrored-range size or reliable-memory usage total does not establish that every buyer-designated critical page is inside it. Assess the supported platform together with the operating system or hypervisor's actual placement behavior.

## Separate physical copies from distinct host data

Full host-memory mirroring keeps two physical copies of the same data. Two units of physical DRAM therefore expose one unit of distinct mirrored data. Partial, or address-range, mirroring duplicates a selected logical range and leaves an ordinary range without that duplicate. Ordinary means unmirrored here; it does not establish the absence of ECC or other memory protection. Lenovo Press LP1877, published December 27, 2023, explains these modes in its historical ThinkSystem and VMware ESXi context.

The buyer needs both quantities: how much distinct host data the arrangement can address, and how much of that distinct capacity belongs to the mirrored range. Adding the second physical copy to the logical capacity would count the same data twice. Calling the entire installed total mirrored would conceal the ordinary range in a partial arrangement.

This article compares those quantities and the residence of a buyer-defined data population. It supplies no BIOS, DIMM-population or allocation procedure.

References: [MM1](https://lenovopress.lenovo.com/lp1877-using-memory-mirroring-and-address-range-mirroring-in-esxi)

## Keep support attached to the complete offered platform

A named product example makes the capacity consequence concrete. The Lenovo ThinkSystem SR650 V3 Product Guide, LP1601 updated October 13, 2026, lists memory mirroring and states that channel mirroring leaves 50% of installed capacity available to the operating system. Its Memory options section attaches mirroring to DIMM-pair conditions and excludes 9x4 DIMMs.

Those conditions matter before arithmetic: an installed-capacity total cannot establish support for the feature. The guide's full-mirroring statement also does not establish partial-mirroring support for every configuration. Confirm applicability against the actual CPU, server, memory arrangement, firmware and operating-system combination being offered. An older explanation of a feature cannot establish support for a newer combination.

For an AI host, the comparison concerns host DRAM. Duplicating host data does not add capacity to GPU-local HBM. Preserve the selected complete configuration when comparing offers rather than treating a generic memory-protection label as a complete specification.

References: [MM2](https://lenovopress.lenovo.com/lp1601-thinksystem-sr650-v3-server), [N1](https://docs.nvidia.com/cuda/archive/13.1.0/cuda-programming-guide/02-basics/understanding-memory.html)

## Account for the same 256 GiB before assessing placement

Consider two fictional alternatives, each starting with 256 GiB of installed host DRAM. Support for each conceptual mode is stipulated. No processor, DIMM layout or actual SR650 V3 build is proposed. Use the same binary unit, GiB, throughout. Exclude every reservation and overhead other than duplication solely to isolate this account; the results are distinct addressable capacity after duplication, not measured free memory available to an application.

The invented workload needs 150 GiB of distinct resident host data. Its owner designates 40 GiB of that total as requiring mirrored residence; the other 110 GiB has no such stipulated requirement. These are this example's requirements, not general requirements for AI workloads.

Full mirroring uses 128 GiB for one physical copy and another 128 GiB for its duplicate. Physical consumption is 128 + 128 = 256 GiB, while distinct mirrored capacity is 128 GiB, with no ordinary range in this alternative. Because 128 GiB is less than 150 GiB, the arrangement fails the gross total-capacity requirement before any omitted reservations are considered.

The partial alternative has a 64 GiB logical mirrored range. Its two physical copies consume 64 + 64 = 128 GiB, leaving 128 GiB of physical DRAM for an ordinary logical range. Physical conservation is 64 + 64 + 128 = 256 GiB. Distinct addressable capacity is instead 64 + 128 = 192 GiB.

The partial alternative clears two initial capacity comparisons: 192 GiB can contain 150 GiB in total, and a 64 GiB mirrored range can contain the designated 40 GiB. Neither inequality establishes where that data actually resides. The selected range size is a fictional accounting premise, not a recommended percentage or module arrangement.

HM-01: conceptual capacity after duplication, with all other deductions excluded
| Alternative | Installed physical DRAM (GiB) | Distinct mirrored range (GiB) | Distinct ordinary range (GiB) | Total distinct capacity (GiB) | Source |
| --- | --- | --- | --- | --- | --- |
| Full mirroring | 256 | 128 | 0 | 128 | Planning analysis |
| Partial mirroring | 256 | 64 | 128 | 192 | Planning analysis |
Original fictional arithmetic. The mirrored-range column counts each logical byte once; its duplicate consumes physical DRAM without adding a distinct byte.

## Compare identical totals with different critical-page coverage

Now consider two independent fictional returned placements for the partial alternative. Each contains all 150 GiB of distinct resident data: 60 GiB in the mirrored region and 90 GiB in the ordinary region. Both fit within the conceptual range capacities of 64 GiB mirrored and 128 GiB ordinary. These are stipulated observations for explanation, not software measurements, a report format or a sequence moving pages from A to B.

Return A places 24 GiB of the designated critical population in mirrored memory and 16 GiB in ordinary memory. Its other data occupies 36 GiB mirrored plus 74 GiB ordinary. The designated population still totals 40 GiB, and the other population still totals 110 GiB. Total capacity fits, but 16 GiB of the buyer-designated critical data sits outside mirroring.

Return B places all 40 GiB of the designated critical data in mirrored memory and none in ordinary memory. Its other data occupies 20 GiB mirrored plus 90 GiB ordinary. It preserves the same 40 + 110 = 150 GiB resident total and the same 60 GiB mirrored plus 90 GiB ordinary usage.

The aggregate totals cannot distinguish the returns. The association between the designated population and its range can: A does not meet the stipulated mirrored-residence requirement; B's stipulated map places the full designated population inside the mirrored range. B establishes that description of residence only.

HM-01: two independent placements inside the same partial-mirroring capacities
| Distinct resident population | A: mirrored (GiB) | A: ordinary (GiB) | B: mirrored (GiB) | B: ordinary (GiB) | Source |
| --- | --- | --- | --- | --- | --- |
| Designated critical: 40 GiB | 24 | 16 | 40 | 0 | Planning analysis |
| Other: 110 GiB | 36 | 74 | 20 | 90 | Planning analysis |
| Total: 150 GiB | 60 | 90 | 60 | 90 | Planning analysis |
Each return uses 60 of 64 GiB mirrored and 90 of 128 GiB ordinary. Identical range usage leaves different designated data outside mirroring.

## Read a placement policy separately from actual residence

LP1877 calls mirrored memory reliable memory in its described ESXi context. It explains best-effort critical-page placement and fallback to ordinary memory when reliable memory is insufficient. That December 2023 account is not a current support promise for another ESXi release or server.

The explanation identifies why the consumer matters. A platform may expose a mirrored range, while the operating system, hypervisor or application determines how the relevant allocations use it. The buyer's designated critical data must be tied to that consumer's supported behavior; a broad critical-services label does not establish that it includes the buyer's chosen population.

The fictional returns sharpen the point. Both leave 4 GiB of the mirrored range unused: 64 - 60 = 4 GiB. In A, that free capacity coexists with 16 GiB of designated critical data in ordinary memory. The free-space figure therefore cannot prove that the intended allocations occupy the range. Nor does 60 GiB of reliable-memory use establish coverage of a smaller, 40 GiB designated population: other data can account for part of that use.

A policy statement describes intended behavior and its conditions. A capacity figure describes space. To establish the stipulated requirement, the returned evidence must also identify the designated population's actual residence for the relevant workload state. A one-time placement description cannot establish that it remains true throughout an execution period unless the evidence supports that period.

References: [MM1](https://lenovopress.lenovo.com/lp1877-using-memory-mirroring-and-address-range-mirroring-in-esxi)

## Decide what each returned quantity establishes

Apply the comparison in order. First resolve whether the complete offered arrangement supports the claimed mode. Then distinguish installed physical DRAM, unique mirrored capacity, ordinary capacity and total capacity after duplication. Compare those quantities with the workload's distinct resident-data requirement before discussing coverage.

For an alternative that clears capacity, ask the responsible platform and application owners to identify the designated data population and explain its supported placement behavior. The useful return ties that population to mirrored or ordinary residence, with the configuration, software versions, workload state and evidence period identified. The article specifies the question to resolve, not an API, command or allocator to use.

In HM-01, full mirroring is excluded by the 150 GiB total requirement. Partial mirroring remains a capacity candidate. Return A supplies enough information to identify a 16 GiB coverage shortfall; a summary reporting only 150 GiB resident and 60 GiB reliable use would leave that coverage unresolved. Return B supports the stated residence of all 40 GiB in its stipulated state. A buyer requiring that residence throughout execution still needs evidence matching that requirement.

Keep the resulting claim bounded to what was established. Mirroring is not persistent storage, a complete checkpoint or a general backup. Neither range capacity nor a placement map proves survival of every fault, zero errors, whole-server availability, recovery time, identical training, performance gain or cost savings. Fault handling and workload acceptance require their own evidence; the comparison here establishes capacity and designated-page residence.

## Use the neighboring guides for different memory questions

The related DDR5 on-die ECC guide explains error locations, codewords and host-path protection. The DDR5 channel-population guide compares channels, DIMMs per channel and operating rates. Neither a checking mechanism nor a channel count identifies which data occupies a mirrored range.

The NUMA guide separates execution location from host-page residence and local capacity. That question can coexist with mirroring: evidence of locality alone does not identify a duplicate copy. The protected-storage capacity guide provides a useful comparison for counting original data separately from copies, while retaining storage allocation and persistence as different questions.

Use these linked guides where an offer raises those decisions. The mirroring comparison remains focused on distinct host capacity and coverage of the designated critical population.

## Carry the selected system into a defined physical project

After the appointed technical owners resolve the memory arrangement, retain the exact selected system and configuration revision in any receiving or rack-build brief. A substituted configuration needs its own technical resolution rather than inheriting the original mirroring description.

Leviathan's Rack Assembly & Preparation service is relevant when that selected equipment also needs an agreed physical receiving, preparation or rack-assembly package. The related service and project-inquiry links provide a place to discuss a nonconfidential equipment brief, delivery state, location, permitted remaining tasks and required handoff records.

The inquiry concerns that separate physical project. Memory administration, placement qualification and reliability acceptance remain with the appointed platform and application owners.

## Primary sources

- [MM1 — Lenovo Press LP1877: Using Memory Mirroring and Address Range Mirroring in VMware ESXi, December 27, 2023](https://lenovopress.lenovo.com/lp1877-using-memory-mirroring-and-address-range-mirroring-in-esxi). Checked 2026-10-20. Historical mechanism and ESXi placement explanation; feature support for an offered current configuration needs its applicable documentation.
- [MM2 — Lenovo Press LP1601: ThinkSystem SR650 V3 Product Guide, updated October 13, 2026](https://lenovopress.lenovo.com/lp1601-thinksystem-sr650-v3-server). Checked 2026-10-20. Memory options gives conditional mirroring support and 50% OS capacity under channel mirroring. The fictional case is not a product build.
- [N1 — NVIDIA CUDA Programming Guide 13.1: Unified and System Memory](https://docs.nvidia.com/cuda/archive/13.1.0/cuda-programming-guide/02-basics/understanding-memory.html). Checked 2026-10-20. Attached host and GPU memory are distinct physical resources even where software provides unified addressing. No capacity or performance specification is inferred.

## Related Leviathan resources

- [DDR5 on-die ECC versus protection of the host memory path](/articles/ddr5-on-die-ecc-versus-host-memory-path)
- [Host DDR5 channel population and supported operating rate](/articles/gpu-server-ddr5-channel-population)
- [NUMA-local host memory versus total RAM](/articles/gpu-server-numa-local-memory-versus-total-ram)
- [Raw, protected and client-usable storage capacity](/articles/gpu-storage-raw-versus-protected-usable-capacity)
- [Rack Assembly & Preparation](/services/gpu-assembly)
- [Discuss the physical package for the selected system](/contact?service=gpu-assembly&from=%2Farticles%2Fhost-memory-full-partial-mirroring-capacity-placement)

## Discuss the physical package for your selected system

Share the selected equipment, configuration revision, delivery state, proposed location, permitted physical tasks and required receiving or rack-assembly handoff records.

[Discuss the scope](/contact?service=gpu-assembly&from=/articles/host-memory-full-partial-mirroring-capacity-placement)