NUMA placement and memory backing
Configure guest memory locality, CPU pinning, and huge-page reservations.
Memory backing defines how a node supplies physical memory to a droplet. NUMA placement and CPU pinning can improve locality for specialized workloads while reducing the number of eligible placement destinations.
Select a memory policy
Under Droplet → Hardware → Memory, choose ordinary pages or a supported huge-page size. Ordinary pages use the pool's normal admission policy. Huge-page backing requires a preallocated host page pool of the requested size; free ordinary memory cannot satisfy that reservation automatically.
A request pins the backing mode and page size in the droplet configuration. The scheduler reports separate missing-page capacity when total memory would fit but the required page pool would not. Changing backing mode requires a stopped droplet.
NUMA locality
The default placement leaves host NUMA selection to the supported hypervisor policy. Preferred locality ranks placements that keep vCPU and memory near each other. Required single-domain locality requires the configured guest CPU and memory to fit within one eligible NUMA domain.
Required locality can reject placement on a host with enough total resources but insufficient capacity in any one domain. It is not relaxed automatically during a drain. The placement explanation includes the eligible domain and reservation totals used by the check.
CPU pinning
Dedicated CPU mode reserves physical CPU capacity for the selected guest vCPUs. The pool defines whether sibling threads can be shared with another workload. Pinning requests must satisfy that pool policy; selecting a host CPU model does not itself request dedicated scheduling.
A pinned guest is still subject to storage and network contention. CPU pinning does not reserve device bandwidth or prevent the application from blocking on an external dependency. Test the application's actual workload before applying these settings across a pool.
Ballooning and overcommit
Guest-assisted ballooning is available only for ordinary memory where both image and pool support it. It changes observed guest memory availability without changing the configured memory quota. It does not convert a configured memory size into a promise that the guest will always have that much physical RAM under an overcommitted policy.
Huge-page and locked-memory policies reject unsupported ballooning combinations. The hardware preview shows the effective memory reservation rather than silently removing the requested backing mode.
Migration and recovery
A migration destination must supply the same CPU contract, backing mode, page size, and locality constraints. Dedicated CPU reservations and huge pages are held at the destination while the source still runs. A region with spare ordinary memory can therefore remain unable to evacuate this guest.
Recovery from a disk backup does not preserve host page allocations. It reapplies the guest hardware policy and can fail until suitable capacity exists. Use Hardware policy API for exact request fields, CPU profiles for feature compatibility, and capacity planning for overlap reservations.