LPAR is a way to slice one powerful physical server into several completely independent virtual computers. Unlike software virtualization, isolation here is handled by the processor’s built-in firmware, which prevents neighboring partitions from affecting the performance and security of your memory area or cores.
LPAR (Logical Partition) technology is widely used in IBM Z mainframes and servers based on the POWER architecture. It is the standard for building consolidated data centers in banking, insurance, and retail, where predictable performance is critically important. The solution is used to run different operating systems (IBM i, AIX, Linux) simultaneously on the same physical chassis without interference and with guaranteed resource allocation for production databases and transaction systems.
Typical problems
Improper planning leads to resource fragmentation, where the total amount of free cores and memory is sufficient but they are distributed across different processor modules and cannot be assembled into a single logical partition. Excessive capacity reservation results in expensive equipment sitting idle, while errors in configuring weights and time-sharing modes cause I/O latency that mimics hardware failures under peak loads on shared adapters.
How LPAR works
The operating principle is based on a hypervisor embedded directly into the hardware platform and managed by a service processor. The firmware initializes partitions before the operating systems start, assigning strictly defined physical cores, RAM ranges, and I/O slots to each LPAR. The central arbitration element is the partition dispatcher, operating at millisecond time quantum levels. It ensures that a virtual processor gains access to a physical execution unit strictly according to its assigned share of clock cycles. There are two core allocation modes: dedicated, where a processor core belongs entirely to one partition, and micro-processor share mode, where a single core can serve multiple LPARs down to hundredths of a percent.
Memory is protected by a hardware controller that prevents one partition from addressing another partition’s physical pages, using access-right keys on the data bus for verification. For peripheral communication, virtual adapters, a server I/O pool, or direct assignment of physical cards are used. Hardware interrupts are routed directly to the target partition without an emulation layer, eliminating the delays typical of software intermediaries. Thus LPAR achieves a level of isolation certified by security standards for mixed environments where open and critical systems coexist in the same chassis.
LPAR features
- Dynamic reallocation of processor resources. The mechanism allows changing the number of cores assigned to a partition and the share of computing power without rebooting the guest OS. Weight coefficients and pool shares determine the guaranteed minimum that a partition receives during periods of contention for clock cycles.
- Processor partitioning modes. Dedicated and shared pools are supported. In dedicated mode, entire cores are exclusively assigned to an LPAR, eliminating neighbor interference. The shared pool activates micro-processor scheduling, where the hypervisor dispatches logical processors with quantization in tens of milliseconds.
- Memory titling and binding. Physical RAM is mapped into the LPAR address space through logical block maps. The partition receives a contiguous range of logical addresses starting from zero, and the hypervisor transparently translates these to physical frame numbers using translation tables.
- Reserved pages. The memory management subsystem allows marking critical guest OS pages as pinned. This prevents their eviction and blocks migration, guaranteeing deterministic access latency for timing-sensitive workloads such as real-time databases.
- Dynamic memory addition. The function of expanding RAM without reboot is achieved by activating logical blocks from the LPAR reserve pool. The OS detects new resources via a machine check interrupt signal and hands them over to the memory manager in a hot-swap manner.
- Virtual Ethernet adapters. An internal system network is organized through the hypervisor’s virtual switches, where each LPAR port has its own MAC address. The adapters support load-balanced aggregation, multiple transmit queues, and hardware encapsulation acceleration to minimize CPU load.
- Virtual I/O based on VIOS. A specialized service partition owns the physical adapters and exports them to logical partitions via the virtual SCSI protocol. This architecture allows multiplexing a single expensive Fibre Channel adapter among hundreds of LPARs while providing isolation by initiator ID.
- NPIV and port assignment. The N-Port ID Virtualization mechanism gives each virtual Fibre Channel adapter a unique global identifier WWPN. This allows zoning the LPAR at the storage fabric level as a separate physical node, retaining all the advantages of hardware QoS for storage networks.
- Virtual device bus. Control messages and data exchange between the LPAR and the hypervisor occur via a shared-memory synchronous protocol. Each partition receives a dedicated channel for configuration commands, requiring no emulation of console interfaces and operating at internal bus speed.
- Hardware Management Console (HMC). A dedicated management processor complex provides a REST API and graphical interface for server resource decomposition. The HMC encrypts management traffic, stores partition profiles, and acts as a trusted intermediary during logical partitioning.
- Partition profiles and activation attributes. The LPAR configuration is saved as a named profile containing desired, minimum, and maximum values for each resource. Upon profile activation, the hypervisor checks for free resources and reserves them via an atomic transaction, preventing races for the hardware.
- Dedicated donor pools. Physical processors can be grouped into several non-overlapping pools with their own allocation rules. This allows segregating license-dependent Oracle or SAP loads from other systems at the scheduler level, physically restricting thread migration.
- Failure isolation and electrical protection. The primary function of LPAR is galvanic isolation of subsystems. A single-bit error in a memory module belonging to partition A does not cause partition B to fail, because the memory controllers physically block the propagation of poison bits and machine check signals.
- Group capacity capping. The Group Capacity feature sets a hard ceiling on CPU time consumption for several LPARs simultaneously. It is used to limit lab environments and control billing in a cloud paradigm, preventing exceedance of the paid computing resource package.
- Partition power management. The hypervisor can transition idle partitions into a standby state with core parking and frequency reduction. An independent power domain for each LPAR allows energy savings while maintaining full computing readiness for the rest of the system board.
- Active partition mobility. The Live Partition Mobility function moves a running LPAR between physical servers without stopping applications. Processor state, memory contents, and I/O adapter context are transferred over a dedicated synchronous channel with finalization within a single quantum.
- Virtual persistent storage. Each LPAR has access to a protected area of the hypervisor’s non-volatile memory for storing license keys and boot variables. Even during a complete system disk failure, the partition retains the information needed for cluster identification.
- On-demand provisioning and instant recovery. The LPAR activation code permits instant allocation of resources from a reserve pool. The monitoring system can initiate a CPU capacity boost to absorb a transaction load peak with a step time of a few seconds.
- Compatibility with nested virtualization. The architecture allows nested hypervisor execution inside an LPAR provided the processor supports virtualization acceleration. A nested partition receives a truncated set of hypervisor instructions while retaining full compatibility at the paravirtualized driver level.
Comparisons
- LPAR vs VMware ESXi Hypervisor. LPAR is a hardware isolation technology embedded in the IBM POWER and Z firmware, where resources are shared without a host OS layer, yielding low overhead and EAL5 certification. VMware ESXi is a software hypervisor installed on top of x86 hardware, where the abstraction level is higher but there is fundamental overhead for hardware emulation under full virtualization.
- x86 (Execution of instructions based on CISC architecture)
- LPAR vs IBM Micropartition. A classic LPAR on POWER systems operates with whole processor cores and hard affinity, guaranteeing predictable performance without hypervisor context-switch overhead. The micropartition, introduced in POWER5, allows splitting a core down to 0.05 CPU, creating up to 10 partitions per processor. Micropartitions use a shared resource pool, increasing flexibility and utilization but creating a noisy neighbor risk.
- LPAR vs Dynamic LPAR (DLPAR). A static LPAR requires a planned OS shutdown to add memory or processors, which limited mainframe flexibility in early versions. DLPAR is a logical evolution of LPAR, allowing processor boards and memory modules to be moved between running partitions without a system restart. DLPAR technology is critical for variable-load systems where static utilization would be unjustifiably low due to over-reservation.
- LPAR vs System WPAR (Workload Partition). LPAR virtualizes physical hardware through a hypervisor, isolating entire OSes with their kernels and memory in separate address spaces. A system WPAR is OS-level virtualization inside AIX, running isolated user-space environments under a single shared kernel. Unlike LPAR, a WPAR cannot run different kernel versions and has a single point of failure, which is impossible in LPAR with its full electrical and software isolation.
- LPAR vs Solaris Zone (Container). LPAR emulates a complete hardware environment, allowing AIX, Linux, or IBM i to run on one machine with hard isolation by processors and I/O channels. Solaris Zones (non-global zones) operate as lightweight isolated environments within a single Solaris OS instance, sharing the same kernel. Technically this is closer to WPAR than to LPAR: zones do not emulate hardware but filter access to system calls, reducing flexibility in OS choice.
OS and driver support
The implementation of LPAR support depends on the hypervisor (PR/SM on mainframes and PHYP on POWER), which provides the OS with a standardized virtual hardware interface, eliminating the need for specific drivers to access physical resources. Guest OSes such as AIX, IBM i, Linux, and z/OS integrate kernel modules for dynamically recognizing added or removed processors and memory without rebooting, using DLPAR events to automatically reconfigure I/O subsystems. For high-performance inter-partition networking, the HiperSockets function is implemented, enabling data exchange at system bus speeds via virtual adapters without physical cables, while QDIO drivers service direct I/O queues.
Security
LPAR security is built on partition isolation by a firmware-level hypervisor that manages page tables and address translation, ensuring that one partition’s processor and memory cannot be accessed by another. On mainframes, this technology is certified to Common Criteria EAL 5+, which treats logical partitions as physically separate servers and permits their use in military systems. Access control to I/O resources is enforced through hardware translation control entries (TCEs), blocking unauthorized data transfer between partitions even at the DMA request level.
Logging
LPAR event logging is performed centrally on the Hardware Management Console (HMC), where system errors, including CRC failures and hardware component state changes, are collected in the /var/hsc/log/ directory and visualized via the Service Focal Point utility for incident correlation. Inside guest systems, hardware error logs are aggregated by commands such as errpt on AIX, which records messages from subsystems in files like /var/adm/sni/sni_errpt_capture, allowing administrators to trace hardware defects of a specific processor or board at the LPAR level. Additionally, hypervisor logs record dynamic resource reallocation operations and partition migration failures, for example when an HSCL058A activation error occurs during LPAR relocation.
Limitations
A key limitation of LPAR is the cap on the number of usable processor cores depending on the hardware generation: for instance, IBM i on POWER8 supports up to 48 SMT8 cores, whereas on newer POWER10, expansion to 240 cores is possible only with IBM Lab Services approval. Although dynamic memory movement between partitions (DLPAR) was implemented in AIX on POWER4 processors, support for this feature in the Linux kernel for the POWER architecture appeared with a significant delay, limiting resource management flexibility in heterogeneous environments until 2009. The total number of LPARs on a single physical server is also capped: POWER5 supports up to 254 partitions with micropartitioning (10 LPARs per processor), and System z9 mainframes are hardware-limited to 60 LPARs.
History and development
The LPAR concept was implemented by IBM in 1988 as PR/SM on ESA/370 architecture mainframes, evolving from early experiments with the CP-40 and VM/370 hypervisors, and originally relied on VM/XA components to manage physical resource partitioning. Later, the technology was adapted for POWER4 servers in the early 2000s using the PHYP hypervisor, and the release of POWER5 introduced micropartitioning, allowing processor shares to be allocated down to 1/10, along with dynamic on-the-fly redistribution. Further development led to the Live Partition Mobility feature in POWER6 for moving running LPARs between servers and integration with Fujitsu and Hitachi x86-64 systems, and on mainframes, to the creation of Geographically Dispersed Parallel Sysplex for disaster-tolerant configurations.