IBM Z and LinuxONE - IBM Z

IBM Z

The enterprise platform for mission-critical applications brings next-level data privacy, security, and resiliency to your hybrid multicloud.

 View Only

Making CPU and memory sharing easy on z/VM with IBM Cloud Infrastructure Center

By Anjali Singh posted 19 hours ago

  

Imagine you have one very powerful mainframe computer, but you’re sharing it among several virtual machines (VMs). An analogy would be a big family sharing a meal at the dinner table. Just as everyone should get enough food so no one goes hungry (but also so nothing is wasted), each VM needs a fair share of the system’s CPU (its “energy” to do work) and its memory (the “space” it uses) to run properly. When multiple VMs run on the same hardware, they all compete for those resources. If one VM hogs the CPU or RAM, the others slow down. That wouldn’t feel very fair in our dinner-analogy: one person taking all the food means the others go without. So, much like making sure everyone at the table has enough to eat, the system needs rules to distribute CPU cycles and memory fairly among all VMs.

That’s precisely what IBM z/VM handles — it determines how much CPU and memory each VM gets. And with IBM Cloud Infrastructure Center (ICIC), you can easily adjust those resource allocations (CPU share, maximum memory, etc.) when you create a VM.

In this blog, we will cover:

  • The meaning of CPU sharing in z/VM
  • The difference between Relative and Absolute CPU share
  • How maximum memory limits are treated
  • How ICIC enables setting all of this when creating a VM

CPU Sharing: Relative vs Absolute

When multiple VMs are running, z/VM must allocate CPU fairly. You define resource sharing in one of two ways:

Relative Share

Think of it like splitting a pizza by slices.

  • If VM A has 200 slices and VM B has 100, then VM A gets twice as much CPU time as VM B when both are busy.
  • It’s flexible — if VM B isn’t using its CPU time, VM A can take more.
  • Ideal for development, testing, or workloads without strict performance requirements.

Absolute Share

Think of it like giving someone a fixed monthly salary.

  • If VM A is assigned 50% absolute, it’s guaranteed at least half of the CPU, regardless of what other VMs are doing.
  • It’s guaranteed, excellent for critical workloads where performance consistency is essential.

📊 Comparison at a glance:

Model Range Allocation Style Typical Use Case
Relative 1–10,000 Proportional share Shared, dynamic systems
Absolute 0.1%–100% Guaranteed minimum Critical workloads

Memory Caps: Why they matter

Memory (RAM) is just as important as CPU. In z/VM, you can set a maximum memory limit for each VM:

  • This prevents one VM from grabbing too much memory, protecting other VMs and the host from resource exhaustion.
  • Helps to keep the overall system stable by avoiding overcommitment that can lead to paging or performance degradation.
  • Particularly useful in multi-tenant setups (where many users share the same system) to enforce fairness and isolation.

How ICIC makes it simple

Normally, you would define CPU share and memory directly in z/VM’s USER DIRECT file (a system definition file). But ICIC makes life easier by letting you:

  • Set Relative or Absolute CPU shares.
  • Set Max Memory.
  • Add comments for documentation.

And you can do this from the User Interface (UI), Command Line Interface (CLI), or API.

Default Behavior

If no custom values are defined, ICIC calculates CPU share as:

user_default_share_unit × vCPU count

Checking user_default_share_unit

To view the value of user_default_share_unit, log in to the compute node and check the configuration file:

cat /etc/zvmsdk/zvmsdk.conf | grep "user_default_share_unit"

File location: /etc/zvmsdk/zvmsdk.conf

image

Figure 1: Output of the grep command showing the user_default_share_unit parameter in the configuration file.

Example: If user_default_share_unit=100 and the VM has 1 vCPUs, the default share is 100.

image

Figure 2: The left panel shows the VM details in the ICIC console, including the VM name (anjali-user-direct), resource utilization, and configuration. The right panel displays the API response, confirming the VM properties, including the Instance ID (ANJA0034) and a vCPU count of 1.

How to Check Your Settings

After deployment, administrators can validate the settings using the smcli Image_Query_DM command:

smcli Image_Query_DM -T <userid>

You’ll see something like:

USER ZWICIC60 LBYONLY 4G 20G G
...
SHARE RELATIVE 100

This confirms your VM is set up with 20 GB memory and 100 relative CPU share.

image

Figure 3: The output of the smcli Image_Query_DM -T ANJA0034 command displays the configuration details of the virtual machine identified by the Instance ID (ANJA0034). The line SHARE RELATIVE 100 indicates that the VM has been assigned a CPU share value of 100, which aligns with the default calculation (user_default_share_unit × vCPU count)

Customization options

ICIC allows administrators to override defaults with:

  • Absolute CPU share (0.1%–100%).
  • Relative CPU share (1–10,000).
  • Maximum memory.

Deployment Scenarios

1. From the UI

On the Images > Deploy page, specify custom values in Instance Extra Specs:

{"general:max_mem": "20G", "general:cpu_share": "ABSOLUTE 50%"}

This means:

  • VM can use max 20 GB memory.
  • It always gets at least 50% of CPU.

Example for only absolute share: {"general:cpu_share": "ABSOLUTE 50%"}

image

Figure 4: ICIC UI Image Deployment page showing deployment of an image with extra specs for absolute CPU share.

image

Figure 5: The left panel displays VM details in the ICIC console, including the VM name (rh92-dasd), resource utilization (memory 4 GB, processor 1 Online CPU, etc.), and configuration. The right panel shows the API response confirming the VM properties, including the instance extra spec (cpu_share=50% absolute), the Instance ID (ANJA0035), and a vCPU count of 1.

image

Figure 6: User direct view for instance ANJA0035, confirming the CPU share is set to absolute 50%.

Example for CPU Share REL with max_memory: {"general:max_mem": "20G", "general:cpu_share": "RELATIVE 150"}

image

Figure 8: The left panel displays VM details in the ICIC console, including the VM name (user-direct-cpu--mem), resource utilization (memory 4 GB, processor 1, etc.), and configuration. The right panel shows the API response confirming the VM properties, including the instance extra specs (cpu_share=RELATIVE 150 and max_mem=20G), the Instance ID (ANJA0036), and a vCPU count of 1.

image

Figure 9: User direct view for instance ANJA0036, confirming the CPU share is set to RELATIVE 150. The second line confirms the maximum memory is 20 GB, and the fourth line confirms the vCPU count as 1.*

RESIZING to vCPU = 2

image

Figure 10: The left panel shows the VM state as Resizing or Migrating for the VM (user-direct-cpu--mem), with resource utilization (memory 4 GB, processor 2, etc.) and configuration. The right panel displays the API response confirming the VM properties, including the instance extra specs (cpu_share=RELATIVE 150 and max_mem=20G), the Instance ID (ANJA0036), and a vCPU count of 2.

image

Figure 11: The left panel shows the VM state as Active after resizing for the VM (user-direct-cpu--mem), with resource utilization (memory 4 GB, processor 2, Online CPUs 2, etc.) and configuration.

image

Figure 12: User direct view for instance ANJA0036, confirming the CPU share is set to RELATIVE 150. The second line confirms maximum memory as 20 GB, and the fourth line confirms a vCPU count of 2.

2. From the CLI

Use the authorized username and password to access the IBM Cloud Infrastructure Center CLI according to Setting environment variables.

Create the virtual machine with openstack server create command:

For Absolute CPU Share

openstack server create --image <image> --flavor <flavor> --network <network> --property 'general:cpu_share=ABSOLUTE 50%' --property 'general:comment=CPU
Share with Absolute' <vm-name>

This gives the VM an absolute CPU share of 50%.

Figure 13: An example for creating a Virtual Machine with an ABSOLUTE CPU share of 50% through CLI.

Screenshot 2025-11-04 at 1 42 58 PM

Figure 14: User direct for Virtual Machine(rxf00009) deployed with an ABSOLUTE CPU share of 50% through CLI.

 Screenshot 2025-11-04 at 2 55 00 PM

Figure 15: The deployed Virtual Machine(rxf00009) with an ABSOLUTE CPU share of 50% through CLI can be seen on UI

Use openstack server show command to see the properties of the virtual machine

 openstack server show anjali-vm-absolute-share -f json
Click to see output for the above command

{
  "OS-DCF:diskConfig": "MANUAL",
  "OS-EXT-AZ:availability_zone": "Default_Group",
  "OS-EXT-SRV-ATTR:host": "BOEM5403",
  "OS-EXT-SRV-ATTR:hostname": "anjali-vm-absolute-share",
  "OS-EXT-SRV-ATTR:hypervisor_hostname": "BOEM5403",
  "OS-EXT-SRV-ATTR:instance_name": "rxf00009",
  "OS-EXT-SRV-ATTR:kernel_id": "",
  "OS-EXT-SRV-ATTR:launch_index": 0,
  "OS-EXT-SRV-ATTR:ramdisk_id": "",
  "OS-EXT-SRV-ATTR:reservation_id": "r-0f8tpj62",
  "OS-EXT-SRV-ATTR:root_device_name": "/dev/sda",
  "OS-EXT-SRV-ATTR:user_data": null,
  "OS-EXT-STS:power_state": 1,
  "OS-EXT-STS:task_state": null,
  "OS-EXT-STS:vm_state": "active",
  "OS-SCH-HNT:scheduler_hints": null,
  "OS-SRV-USG:launched_at": "2025-10-31T10:39:47.000000",
  "OS-SRV-USG:terminated_at": null,
  "accessIPv4": "",
  "accessIPv6": "",
  "access_ipv4": "",
  "access_ipv6": "",
  "addresses": {
    "ZVM-FLAT": [
      "172.26.53.101"
    ]
  },
  "adminPass": null,
  "admin_password": null,
  "attached_volumes": [],
  "availability_zone": "Default_Group",
  "block_device_mapping": null,
  "block_device_mapping_v2": null,
  "compute_host": "BOEM5403",
  "config_drive": "True",
  "created": "2025-10-31T10:36:18Z",
  "created_at": "2025-10-31T10:36:18Z",
  "description": null,
  "disk_config": "MANUAL",
  "fault": null,
  "flavor": "tiny (tiny)",
  "flavorRef": null,
  "flavor_id": null,
  "has_config_drive": "True",
  "hostId": "a680a519b14b2e253cd98962db6c1200c9d2ffecb6be7d29b2301587",
  "host_id": "a680a519b14b2e253cd98962db6c1200c9d2ffecb6be7d29b2301587",
  "host_status": "UP",
  "hostname": "anjali-vm-absolute-share",
  "hypervisor_hostname": "BOEM5403",
  "id": "23142d91-4249-4797-8458-92a4a3a0b018",
  "image": "rh92_dasd (76c83865-2922-45b4-9d96-93498250267c)",
  "imageRef": null,
  "image_id": null,
  "instance_name": "rxf00009",
  "interface_ip": "",
  "is_locked": false,
  "kernel_id": "",
  "key_name": null,
  "launch_index": 0,
  "launched_at": "2025-10-31T10:39:47.000000",
  "location": {
    "cloud": "",
    "region_name": "RegionOne",
    "zone": "Default_Group",
    "project": {
      "id": "4af7582630964e7ca1de92ce4baedb88",
      "name": "ibm-default",
      "domain_id": null,
      "domain_name": "Default"
    }
  },
  "locked": false,
  "max_count": null,
  "min_count": null,
  "name": "anjali-vm-absolute-share",
  "networks": null,
  "power_state": 1,
  "private_v4": "",
  "private_v6": "",
  "progress": 0,
  "project_id": "4af7582630964e7ca1de92ce4baedb88",
  "properties": {
    "general:cpu_share": "ABSOLUTE 50%",
    "general:comment": "CPU Share with Absolute",
    "os_distro": "rhel9.2",
    "disk_pool": "ECKD:ICICPL",
    "online_cpu_num": "1",
    "kernel_info": "Linux 5.14.0-284.11.1.el9_2.s390x s390x"
  },
  "public_v4": "",
  "public_v6": "",
  "ramdisk_id": "",
  "reservation_id": "r-0f8tpj62",
  "root_device_name": "/dev/sda",
  "scheduler_hints": null,
  "security_groups": [
    {
      "name": "default"
    }
  ],
  "server_groups": [],
  "status": "ACTIVE",
  "tags": [],
  "task_state": null,
  "terminated_at": null,
  "trusted_image_certificates": null,
  "updated": "2025-11-04T07:48:05Z",
  "updated_at": "2025-11-04T07:48:05Z",
  "user_data": null,
  "user_id": "0688b01e6439ca32d698d20789d52169126fb41fb1a4ddafcebb97d854e836c9",
  "vm_state": "active",
  "volumes": [],
  "volumes_attached": []
}

For Relative CPU Share

 openstack server create --image <image> --flavor <flavor> --network <network> --property 'general:cpu_share=RELATIVE 150' --property 'general:comment=CPU Share with Relative' <vm-name>

This gives the VM a relative CPU share of 150.

Screenshot 2025-11-04 at 1 22 49 PM

Figure 16: An example for creating a Virtual Machine with RELATIVE CPU share of 150 through CLI.

Screenshot 2025-11-04 at 1 42 18 PM

Figure 17: User direct for Virtual Machine(rxf0000a) deployed with an RELATIVE CPU share of 150 through CLI

Use openstack server show command to see the properties of the virtual machine

openstack server show anjali-vm-relative-share -f json
Click to see output for the above command
{
  "OS-DCF:diskConfig": "MANUAL",
  "OS-EXT-AZ:availability_zone": "Default_Group",
  "OS-EXT-SRV-ATTR:host": "BOEM5403",
  "OS-EXT-SRV-ATTR:hostname": "anjali-vm-relative-share",
  "OS-EXT-SRV-ATTR:hypervisor_hostname": "BOEM5403",
  "OS-EXT-SRV-ATTR:instance_name": "rxf0000a",
  "OS-EXT-SRV-ATTR:kernel_id": "",
  "OS-EXT-SRV-ATTR:launch_index": 0,
  "OS-EXT-SRV-ATTR:ramdisk_id": "",
  "OS-EXT-SRV-ATTR:reservation_id": "r-jd62g1cy",
  "OS-EXT-SRV-ATTR:root_device_name": "/dev/sda",
  "OS-EXT-SRV-ATTR:user_data": null,
  "OS-EXT-STS:power_state": 1,
  "OS-EXT-STS:task_state": null,
  "OS-EXT-STS:vm_state": "active",
  "OS-SCH-HNT:scheduler_hints": null,
  "OS-SRV-USG:launched_at": "2025-10-31T10:50:48.000000",
  "OS-SRV-USG:terminated_at": null,
  "accessIPv4": "",
  "accessIPv6": "",
  "access_ipv4": "",
  "access_ipv6": "",
  "addresses": {
    "ZVM-FLAT": [
      "172.26.53.156"
    ]
  },
  "adminPass": null,
  "admin_password": null,
  "attached_volumes": [],
  "availability_zone": "Default_Group",
  "block_device_mapping": null,
  "block_device_mapping_v2": null,
  "compute_host": "BOEM5403",
  "config_drive": "True",
  "created": "2025-10-31T10:47:25Z",
  "created_at": "2025-10-31T10:47:25Z",
  "description": null,
  "disk_config": "MANUAL",
  "fault": null,
  "flavor": "tiny (tiny)",
  "flavorRef": null,
  "flavor_id": null,
  "has_config_drive": "True",
  "hostId": "a680a519b14b2e253cd98962db6c1200c9d2ffecb6be7d29b2301587",
  "host_id": "a680a519b14b2e253cd98962db6c1200c9d2ffecb6be7d29b2301587",
  "host_status": "UP",
  "hostname": "anjali-vm-relative-share",
  "hypervisor_hostname": "BOEM5403",
  "id": "8561c1c3-e49e-47d9-ab1b-af53e6682476",
  "image": "dasd_rhel_88 (5ea6d12c-dbd6-42f5-9ee7-1fbc73d828d0)",
  "imageRef": null,
  "image_id": null,
  "instance_name": "rxf0000a",
  "interface_ip": "",
  "is_locked": false,
  "kernel_id": "",
  "key_name": null,
  "launch_index": 0,
  "launched_at": "2025-10-31T10:50:48.000000",
  "location": {
    "cloud": "",
    "region_name": "RegionOne",
    "zone": "Default_Group",
    "project": {
      "id": "4af7582630964e7ca1de92ce4baedb88",
      "name": "ibm-default",
      "domain_id": null,
      "domain_name": "Default"
    }
  },
  "locked": false,
  "max_count": null,
  "min_count": null,
  "name": "anjali-vm-relative-share",
  "networks": null,
  "power_state": 1,
  "private_v4": "",
  "private_v6": "",
  "progress": 0,
  "project_id": "4af7582630964e7ca1de92ce4baedb88",
  "properties": {
    "general:cpu_share": "RELATIVE 150",
    "general:comment": "CPU Share with Relative",
    "os_distro": "rhel8.8",
    "disk_pool": "ECKD:ICICPL",
    "online_cpu_num": "1",
    "kernel_info": "Linux 4.18.0-477.10.1.el8_8.s390x s390x"
  },
  "public_v4": "",
  "public_v6": "",
  "ramdisk_id": "",
  "reservation_id": "r-jd62g1cy",
  "root_device_name": "/dev/sda",
  "scheduler_hints": null,
  "security_groups": [
    {
      "name": "default"
    }
  ],
  "server_groups": [],
  "status": "ACTIVE",
  "tags": [],
  "task_state": null,
  "terminated_at": null,
  "trusted_image_certificates": null,
  "updated": "2025-11-04T07:46:05Z",
  "updated_at": "2025-11-04T07:46:05Z",
  "user_data": null,
  "user_id": "0688b01e6439ca32d698d20789d52169126fb41fb1a4ddafcebb97d854e836c9",
  "vm_state": "active",
  "volumes": [],
  "volumes_attached": []
}


Check Status of Deployed Virtual Machines

Screenshot 2025-11-04 at 1 14 47 PMFigure 20: Use openstack server list to see the list and status of deployed VMs

Conclusion

CPU and memory sharing might sound complex, however, think of it this way: it’s like splitting pizza (relative share) vs giving someone a salary (absolute share). What makes ICIC great is that you don’t have to edit z/VM configs manually — you just pick which sharing mode you want when creating a VM.

That means resource allocation becomes easier, fairer, and more predictable. Whether you’re spinning up test workloads or running mission-critical apps, ICIC helps make sure your VMs always get the right amount of CPU and memory.

0 comments
3 views

Permalink