content_image/980110.jpg
CPU, memory, and workload management are all provided by z/OS services. Memory is provisioned through the zCX address space by using private, above-the-2-GB-bar, fixed memory that is managed by VSM (Virtual Storage Manager) and RSM (Real Storage Manager). Virtual CPUI’s are provisioned to each zCX address space. Each virtual CPU is a dispatchable thread (in other words, MVS TCB) within the address space. zIIP access is provided by the MVS dispatcher. Multiple Docker container instances can be hosted within a single zCX instance. 

WLM policy and resource controls including service class association, goals, importance levels, tenant resource groups (including optional caps for CPU and ream memory) are extended to zCX. 

SMF data is available as well (Type, 30, 72, and so on), which enables z/OS performance management and capacity planning. Figure 1-12 provides more details. 

<img src='content_image/980110.jpg'>

Multiple z/CX instances can be deployed within a z/OS System. This allows for isolation of applications, different business/performance priorities (in other words, unique WLM service classes) and the capping of resources that are allocated to workloads (CPU, memory, disk, and so on). Each zCX address space has its own assigned storage, network, and memory resources. CPU resources are shared with other address spaces. Resource access can be influenced by configuration and WLM policy controls. 

In summary, zCX provides “hypervisor-like” capa bilities by using the z/OS Dispatcher, WLM, and VSM/RSM components to manage access to memory and CPU. The zCX virtualization layer manages the storage, network, and console access by using dedicated resources. There is no communication across zCX virtualization layer instances. Figure 1-13 provides more details. 

