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. Figure 1-12 Availability of SMF data 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. 12  Getting started with z/OS Container Extensions