Similar to the case of shared processors, a so-called shared memory pool can be created for sharing memory. In contrast to shared processor pools, there is only one shared memory pool at most. In principle, almost any number of LPARs (maximum 1000) can then be assigned to the shared memory pool. The sum of the main memory sizes of these LPARs may exceed the main memory size of the shared memory pool. For example, in the situation in figure 6.2, a shared memory pool of 200 GB could be created and all 6 LPARs shown with a total of 248 GB of memory could be assigned. Since it cannot be ruled out that all LPARs together use more than 200 GB of memory, the missing memory of 248 GB – 200 GB = 48 GB must of course be provided in some form. This is where paging devices known from operating systems come into play. A separate paging device (with a capacity of at least the maximum memory size of the LPAR) must be provided for each LPAR that uses the shared memory pool. Missing physical main memory is then replaced by memory on the paging devices.

Figure 6.3 shows a shared memory pool with 2 shared memory LPARs. The memory of the LPARs consists of physical main memory from the shared memory pool and possibly memory from paging devices. For the LPARs themselves, it cannot be determined whether a memory area uses physical memory or memory on a paging device. The hypervisor assigns physical memory from the shared memory pool to the individual LPARs dynamically. After relocating physical memory pages to a paging device, the hypervisor can assign the released physical memory to another LPAR. If the original LPAR accesses the paged-out memory pages again, the hypervisor assigns free physical memory pages, starts I/O on the paging device to read the paged-out data and then saves them on the new physical memory pages. The processes on the associated LPAR are not aware of these background actions. The memory access simply takes a little longer.