Virtual system configuration

Read the information about the configuration of the virtual systems used in the test scenario.

All virtual systems running Linux™ had the following in common:

One of the following disk configurations:
- One full-pack minidisk on a FICON® attached 3390 Model 27 DASD, formatted with two partitions: one partition for the root file system, and one as a Linux swap device.
- Two full-pack minidisks on a FICON attached 3390 Model 9 DASD, formatted with one partition each. The first disk was used for the root file system, the second disk was used as a Linux swap device.
  Note: Even though Linux swap devices were configured, the virtual machines, the Linux systems and the workloads were configured such that Linux swapping did not occur.
For each virtual full-pack minidisk, four virtual HyperPAV devices were configured in the z/VM® directory definition for the virtual system containing the minidisk, as follows:
```
USER LE2EPxxx
…
COMMAND DEFINE HYPERPAVALIAS aaa1 FOR base bbbb
COMMAND DEFINE HYPERPAVALIAS aaa2 FOR base bbbb
COMMAND DEFINE HYPERPAVALIAS aaa3 FOR base bbbb
COMMAND DEFINE HYPERPAVALIAS aaa4 FOR base bbbb
…
MDISK bbbb 3390 DEVNO bbbb
```
In this example, bbbb is the device number used for both the real disk and the virtual full-pack minidisk, and aaa1–4 are the devices numbers of the virtual HyperPAV devices.
A virtual NIC was attached to a z/VM Virtual Switch (VSWITCH), connected through an OSA adapter to an internal network.

Table 1 lists the virtual system configurations that were used throughout the tests.

Table 1. Virtual system configuration variants (constant for all performed tests)
Table with seven columns describing the virtual system configuration variants which are constant for all tests performed. The columns denote number of the workload, the workload, the level, the component or variant, the number of CPUs, the memory amount, and additional resources.
Workload				# CPUs	Memory	Additional resources
#	Type	Level	Component or variant	# CPUs	Memory	Additional resources
1	Database		Database server	4	300 GiB	2 * 256 GiB SCSI disks (DATA) 3 * 10 GiB SCSI disks (LOG)
2	Transactional	medium	IHS	1	700 MiB
3			WAS	2	4 GiB
4			DB2®	1	2 GiB
5		high	IHS	1	700 MiB
6			WAS	4	4 GiB
7			DB2	2	2 GiB
8	File system	medium	page cached	2	16 GiB	4 * 3390 Model 9 (fio data files)
9		medium	direct I/O	2	16 GiB	4 * 3390 Model 9 (fio data files)
10		high	page cached	4	16 GiB	4 * 3390 Model 9 (fio data files)
11		high	direct I/O	4	16 GiB	4 * 3390 Model 9 (fio data files)
12	Java™	high		2	4 GiB
13	Java™	medium		1	4 GiB
14	Network	medium	client	1	1 GiB	1 VNIC to QDIO based guest LAN
15		medium	server	1	1 GiB	1 VNIC to QDIO based guest LAN
16		high	client	2	1 GiB	1 VNIC to QDIO based guest LAN
17		high	server	2	1 GiB	1 VNIC to QDIO based guest LAN

Assignment of relative shares to virtual systems

In z/VM, virtual systems are assigned relative shares that control the allotment of resources such as CPU, real storage, or paging capacity, when these resource are constrained at the z/VM level (for details, see z/VM 6.3 Performance). Relative means that when virtual systems compete for a constrained resource, the resource is allotted by factoring in the relative shares assigned to the competing virtual systems. For example, if a virtual system A was assigned twice the relative share assigned to a virtual system B, then A receives twice as much resource as B.

It is important to realize that the treatment of shares for the resource type CPU does not depend on the amount of virtual CPUs assigned to a virtual system. For example, if virtual system C had one virtual CPU, and virtual system D had four virtual CPUs assigned, but both virtual systems had the same relative share assigned, then, - when z/VM runs into a CPU constrained situation -, both systems would receive the same amount of CPU, irrespective of their number of virtual CPUs. For example, if in this situation z/VM had two CPUs available for dispatching virtual system work, then on average both virtual systems would receive a processing power of one CPU. If all virtual CPUs were active all the time, then C's only virtual CPU would receive a processing power of one real CPU, but each of D's four virtual CPUs would receive a processing power of only 0.25 real CPUs.

In order to achieve a distribution of processing power with respect to the amount of virtual CPUs defined for a virtual system, in the test environment, virtual systems were assigned relative shares with their number of virtual processors factored in. For example, a virtual system with one virtual CPU was assigned a relative share of 100, a virtual system with two virtual processors was assigned a relative share of 200, and so forth. With this approach, in the situation described in the previous paragraph, the one virtual CPU of virtual system C would then receive a processing power of 0.4 CPUs, and each of virtual system D's virtual CPU would also receive a processing power of 0.4 CPUs.

However, a virtual CPU can never consume more than one real CPU, regardless of the share. So if z/VM in the same situation had six real CPUs available for dispatching virtual system work, then each virtual CPU would receive the processing power of one real CPU, and the equivalent of one real CPU would remain more or less unused.