IBM zSystem Virtual Inventory

IT Asset Management (Cloud)

IT Asset Management provides visibility of Linux VMs deployed on IBM zSystem environments, allowing you to collect inventory and count licenses for IBM and non IBM products running on zSystem environments (such as Oracle database). After collecting the inventory, installs of software on these zSystem environments will consume correctly from all license types.

IBM zSystems architecture, is a mainframe architecture developed and supported by IBM, containing partitioned LPAR environments (similar to AIX) running on physical hardware. The LPAR layer can run a hypervisor (z/VM or zKVM) with the capability of running fully-functional Linux operating systems on zSystem environments as guests, or Linux guests can run directly on the LPAR without a hypervisor. These guests are VMs and perform as if they were completely independent machine environments.

zSystem inventory collected by IT Asset Management will consist of:

• Linux VMs running on z/VM or z/KVM hypervisors and respective hierarchy
• Linux VMs running directly on an LPAR and respective hierarchy.

How the inventory is collected

Important: To collect the IBM zSystem Virtual Inventory, the FlexNet Inventory Agent needs to be installed on the Linux guest VM(s). Core information for the VM(s) is collected by the agent using the qclib tool, the qc_num_cpu_total property from the guest layer outputs as the processor/core count for the VM. For the agent to successfully collect IFL/CP core information from the shared pool, the Global Performance Data (GDP) setting needs to be enabled in the LPAR's activation profile. If this setting is not enabled, the agent will still collect zSystem VMs hierarchy inventory and represent it in IT Asset Management, however the IFL or CP shared pool inventory will not be represented, which can cause licenses to be counted incorrectly.

Once installed, the agent can collect all the information needed to represent the entire IBM zSystem hierarchy in IT Asset Management and count licenses across the zSystem hierarchy correctly.

The inventory collection component (ndtrack) automatically collects IBM zSystem virtual hierarchy inventory when collecting hardware and software inventory of the IBM zSystem hosts discovered through the target (see Targets). The virtual hierarchy, is displayed on the Virtual Devices and Clusters page (you can filter by VM type = IBM zKVM and VM type = IBM zVM).

For details on how to install the FlexNet Inventory Agent, see Gathering FlexNet Inventory available at https://docs.flexera.com/.

Hierarchy structure

The following table details the IBM zSystem environment virtual hierarchy represented in the IT Asset Management UI:

Host

The IBM zSystem mainframe computer.

LPAR groups

Enables the management of capacity for multiple LPARs to a limit allowing better management of CPU usage.

LPAR (Logical partition)

IBM zSystem servers can be partitioned into separate logical computing systems. System resources (memory, processors, I/O devices) can be divided or shared among many such independent logical partitions (LPARs) under the control of the LPAR hypervisor, which comes standard on all zSystem servers. Each LPAR supports an independent operating system (OS) loaded by a separate initial program load (IPL).

z/VM or zKVM hypervisior (depending on what hypervisor is in use)

z/VM is an operating system implementation of IBM virtualization technology providing the capability to run full-function operating systems such as Linux on zSystem as guests of z/VM.

zKVM is an open source virtualization option for running Linux-centric workloads that uses common Linux-based tools and interfaces.

Linux VM guests

VMs that perform as if they were completely independent machine environments.

Under host, the shared pool sits at the top level of the virtual hierarchy, which is divided up between CPs and IFLs. LPARs come under CPs and IFLs respective of what core type they are using, followed by the hypervisor (if a hypervisor is in use) and lastly the VM.

In the case of a hypervisor not being used, the LPAR is not represented as a pool in the hierarchy, but instead is represented as a single LPAR type VM under a CP or IFL resource pool, or an LPAR group.

Note: Central Processor (CP) - zSystem servers exploit several types of processors, that are also called engines. Central Processor, also known as a General Purpose processor, can execute any kind of workload.

Integrated Facility for Linux (IFL) processor - Integrated Facility for Linux (IFL) processor which is limited to executing only Linux for zSystem workloads with or without the z/VM hypervisor.

Note: CPs and IFLs are represented separately in the grid view on the Virtual Devices and Clusters page, meaning it's possible for the same LPAR to be listed twice in the overall hierarchy. This can happen when VMs are dispatched from CP and IFL cores belonging to the same LPAR.

The below diagram visualizes the above hierarchy information:

Counting cores and capping

For partition based VMs where no host OS is available (such as LPARs), cores are counted differently to that of a physical device. LPAR VM inventory returns the number of virtual cores assigned to the partition, and may also return a core count for the underlying hardware. As a result, no separate inventory is required for the host server, although IT Asset Management synthesizes a host record to group together guest systems. In addition, for LPARs, it's possible for the sum of virtual cores for all the VMs on a host to exceed the core count for the host itself, because virtual cores can share physical cores.

For capping, everything above a VM is a type of resource pool that caps the amount of cores the VMs have access to. The installs of software on these VMs will consume from all license types, the same as any install on any device. IT Asset Management will count and apply capping where appropriate.

Capping is performed on the following layers:

• CP and IFL resource pools
• LPARs
• z/VM and z/KVM hypervisors.

Note: Although all the layers listed in the above zSystem hierarchy structure table are represented in IT Asset Management, only core values are populated, meaning capping is not performed on all the layers in the hierarchy.

The following layers will have no core count and will not cap:

• LPAR groups
• CPU pools (z/VM).

License types where capping is applied based on parent pool cores:

• Oracle Processor
• Oracle NUP
• PVU
• VPC.

Tip: Capping example 1: Three VMs each with two cores exist in a resource pool, bringing the total number of cores to six. However, the resource pool that the VMs are in, has a maximum of five cores. This means that the six cores belonging to the VMs will be capped at five, and the five core count will contribute to the overall license consumption for that license.

Tip: Capping example 2: Similar to the above, there are two resource pools, each capped at five cores, bringing both resource pools to a total of ten cores. However, both resource pools belong to the same parent LPAR which has eight cores. This means the LPAR layer will enforce capping, and instead of consuming ten cores for both resource pools, the cores are capped at eight.