Virtualization, NUMA and blade systems: capacity has a topology

Memory has a location

A virtual machine provides a virtual hardware boundary; containers generally share the host kernel. Neither label alone establishes a security guarantee. Match isolation to tenant trust, patching and device access. On a NUMA host, a virtual CPU and its working memory may sit on different sockets. Remote memory traffic can increase latency despite apparently free RAM. Measure the application before selecting pinning, huge pages or passthrough; each can constrain scheduling or migration.

Reserve room for the host that fails

Consider four hypothetical hosts with 256 GiB each. Raw capacity is 1,024 GiB, but reserving one host for failure leaves 768 GiB before hypervisor overhead and operational headroom. A packing plan that consumes all raw memory cannot also promise full N+1 recovery. CPU overcommit is a scheduling policy, not additional physical execution capacity. Test failure with representative concurrency, storage pressure and restart storms rather than a single idle virtual machine.

Look beyond the blade chassis

Blade chassis can simplify cabling and pool power or networking, while concentrating failure and maintenance domains. Compare chassis-level outages against rack-server independence; neither form factor is universally superior. Live migration requires compatible CPU features, networking, storage and device behavior.

GPU passthrough may change that capability. Document a supported compatibility matrix, firmware baselines, backup restoration and rollback. The acceptance test should demonstrate workload recovery within an agreed objective, not merely show a management console with green icons.