Archive for the ·

Virtualization

· Category...

AIX PowerVM Concepts in short

no comments

PowerVM concepts

 

CPU entitlement

One of the unique PowerVM unique features is the ability to give a VM an exact slice of CPU time. In PowerVM, this slice is called a CPU entitlement. Implicit in this concept is that an entitlement can be for less than one CPU. A VM with fractional entitlements is termed a micropartition. One question this article will answer is if micropartitions scale linearly; that is, is there any overhead running with fractional CPUs?

Virtual CPUs

In addition to specifying the CPU entitlement, a VM must also specify the number of vCPUs it will use. These vCPUs are what the VM operating system sees, regardless of the underlying CPU entitlement.

A VM can have up to ten times the number of vCPUs as its entitlement, rounded down. vCPUs must be specified as whole numbers. For example, a VM with 1 entitlement can have 10 vCPUs; a VM with a 0.25 entitlement can only have 2 vCPUs. In addition, a VM must have at least 1 vCPU for each whole-number entitlement. It is not possible to have 2 entitlements and only 1 vCPU for example.

The interesting question here is whether a multithreaded workload benefits from having PowerVM or the operating system manage threads. PowerVM manages a multithreaded workload by scheduling additional vCPUs for a VM. The AIX operating system handles multiple threads using context switching between its available CPU threads.

Capped compared to uncapped

Another feature of PowerVM is that it allows VMs to use more CPU processing time if needed. If one VM is not using its CPU for a given scheduling interval, other VMs are able to use this CPU time to do more work. In order to use additional processor cycles, the VM must be in uncapped mode, which means that it can use up to its vCPUs worth of entitlement. For example, a VM with a 0.25 entitlement and 2 vCPUs in uncapped mode could use up to 2 CPU entitlements. If the VM only had 1 vCPU, it could only use 1 CPU entitlement. In capped mode, the same VM would never use more than 0.25 entitlement, regardless of its vCPU count. A separate set of benchmarks was run to measure how VMs with 2 vCPUs scale with different entitlements and uncapped settings.

The extra CPUs used by uncapped virtual machines can come from either other shared CPU VMs or from dedicated CPUs VMs that allow processor sharing. For dedicated CPU VMs, this is called donating mode.

How many virtual processors are active in my AIX LPARs?

no comments

Question:

 

How many virtual processors are active in my AIX LPARs?

 

Solution:

 

You can use kdb command and the sub-command vpm:

As you see, the number of active virtual processors is 4.

# echo vpm | kdb
 START END <name>
0000000000001000 0000000004090000 start+000FD8
F00000002FF47600 F00000002FFDF9C0 __ublock+000000
000000002FF22FF4 000000002FF22FF8 environ+000000
000000002FF22FF8 000000002FF22FFC errno+000000
F1000F0A00000000 F1000F0A10000000 pvproc+000000
F1000F0A10000000 F1000F0A18000000 pvthread+000000
read vscsi_scsi_ptrs OK, ptr = 0x0
(0)> vpm
VPM Tunables
vpm_interval............... 000003E8 schedp.vpm_fold_threshold.. 00000031
vpm_fold_limit............. 00000008 vpm_unfold_limit........... 00000002
vpm_be_threshold........... 0000000A
VPM Data
.........................vpm_mgmt :01
........................vpm_flags :01 USE_BEST_ENERGY
....................vpm_prev_time :1368736952449027431 ns
.....................vpm_interval :1001004500 ns
....................vpm_prev_intr :20125205922335 ns
.........................vpm_intr :11899421 ns
VPM Core Buckets
INDX ID TYPE SR CORE LAST ACTI HEAD UTIL STATE
 0 0 SRAD 1 1 1 0 0 51844765
VPM Core State
 POS CORE NEXT PRIO BEST C STATE
 0 0 NONE 0 0 0 GP ACTIVE
VPM Sleep Data.
........................vsd_state :03
..............vsd_sleep_specifier :00000002
................vsd_sleep_latency :0000000000000000 sec 00989680 nsec
....................vsd_min_sleep :0000000000000000 sec 1DCD6500 nsec
....................vsd_prod_lock :@F100010021622400
....................vsd_prod_head :0000000000000000
VSD Thread State.
 CPU VP_STATE SLEEP_STATE PROD_TIME: SECS NSECS CEDE_LAT
0 ACTIVE AWAKE 0000000000000000 00000000 00
 1 ACTIVE AWAKE 0000000000000000 00000000 00
 2 ACTIVE AWAKE 0000000000000000 00000000 00
 3 ACTIVE AWAKE 0000000000000000 00000000 00
(0)>

How to migrate an existing VIO server using Hitachi Dynamic Link Manager version 5.6 to Dynamic Link Manager version 5.9

Comments Off

 

The procedures are in the Hitachi Dynamic Link Manager User Guide. The installation procedure is basically the same as for a standalone AIX server.

You must use the special VIO command oem_setup_env to get into the root shell to uninstall and reinstall Dynamic Link Manager. The recommended procedure is to shut down the client prior to the upgrade.The virtual (mapped) devices must either be removed or put in a defined state.

You must also be aware that the pvid method of identifying the disks is the default with Dynamic LinkManager version 5.6,however, with Dynamic Link Manager version 5.6.1 the option to specify the unique_id method was available. If you are using unique_id, then no changes are required.
However,if you are using the pvid method, then a backup and restore(orreload) is required.If you have dual VIO servers, you can migrate one server at a time,however, care must be taken to ensure the paths areavailable and
there are no path errors in the client. Also, ensure that you are using the unique_id method of identifying the disks. The reserves must be disabled on all the hdisks prior to remapping the devices for the client partitions.

Comments Off