Using Oracle Linux Virtualization Manager (OLVM) to Restrict Cores

Organizations usually maintain Oracle licences for Oracle RDBMS Enterprise Edition on a per-core basis. It is possible to use Virtualization Managers to limit the resources assigned to virtual machine “guests”—and, subsequently, the databases within those guests. According to the Oracle Partitioning Policy, using Oracle Virtualization Manager (which has evolved into Oracle Linux Virtualization Manager, or OLVM) is authorised for hard-partitioning and CPU license boundaries. As a result, it can limit the license costs to resources used rather than licensing based on the resources of the underlying bare metal (BM) server.

This blog focuses on using Oracle Linux Virtualization Manager to limit CPU resources. To restrict the Virtual Machine to the correct number of cores used, each VM must specify the cores on which it may run. By default, if we restrict the number of VM CPUs to, let’s say, 20, then those CPUs get mapped to ANY of the BM CPUs. This breaks the number of cores licensed. The requirement is to ensure that the licensable number of cores is enforced. This is further complicated by hyper-threading, such that each CPU is a hyper-thread rather than a single core.

So, the first thing to find out is how the CPUs are mapped on the BM server. Here is a small AWK script (cpu.awk) to analyse the contents of /proc/cpuinfo. It was run against Oracle Enterprise Linux 8 on a Google Bare Metal Service server, and you may need to amend it for different Linux types and versions.

{
        if ( substr($1,0,9) == "processor" ) {
                proc=sprintf("%d",$2)
        }
        if ( substr($1,0,11) == "physical id") {
                phys=sprintf("%02d",$2)
        }
        if ( substr($1,0,7) == "core id" ) {
                cid=sprintf("%02d",$2)
                ind=phys cid
                if ( core[ind] == "" ) {
                        core[ind]=proc
                } else {
                        core[ind]=core[ind] "," proc
                }
        }
}
END {
        n=asorti(core, sorted)
        for( i=1; i<=n; i++ ) {
                numa=sprintf("%i",substr(sorted[i],1,2))
                coreid=sprintf("%i",substr(sorted[i],3))
                print "numa " numa " core " coreid " : processors " core[sorted[i]]
        }
}

To run it, use:

awk -F: -f cpu.awk /proc/cpuinfo

The output from the 24-core, 48 hyper-thread Google BMS server running OEL 8 was:

numa 0 core 0 : processors  0, 24
numa 0 core 2 : processors  1, 25
numa 0 core 3 : processors  2, 26
numa 0 core 4 : processors  3, 27
numa 0 core 9 : processors  4, 28
numa 0 core 10 : processors  5, 29
numa 0 core 11 : processors  6, 30
numa 0 core 16 : processors  7, 31
numa 0 core 17 : processors  8, 32
numa 0 core 18 : processors  9, 33
numa 0 core 19 : processors  10, 34
numa 0 core 24 : processors  11, 35
numa 1 core 1 : processors  12, 36
numa 1 core 2 : processors  13, 37
numa 1 core 4 : processors  14, 38
numa 1 core 10 : processors  15, 39
numa 1 core 11 : processors  16, 40
numa 1 core 16 : processors  17, 41
numa 1 core 17 : processors  18, 42
numa 1 core 20 : processors  19, 43
numa 1 core 24 : processors  20, 44
numa 1 core 25 : processors  21, 45
numa 1 core 26 : processors  22, 46
numa 1 core 27 : processors  23, 47

Here, we have 2 physical processors mapped to different memory locations (numa) with 12 cores each. The cores are rather randomly numbered in this example, but the important thing is that they have unique numa and core numbers. The last 2 numbers on each line are the hyper-thread numbers assigned to each.

In the list, numa 0 core 0 has hyper-thread numbers 0 and 24, which are associated with that core.

The license requirement is 10 cores in this case, so 20 CPUs (hyper-threads) can be used. Ideally, we would like half of them to be in numa 0 and half in numa 1 to make the most of the architecture. The same hyper-threads associated with individual cores must be pinned for use in the VM.

The list of cores used in this example are the first 5 in numa 0; i.e. cores 0, 2, 3, 4 and 9 have hyper-thread numbers 0 to 4, and 24 to 28. And the first 5 cores in numa 1; i.e. cores 1, 2, 4, 10 and 11 have the hyper-thread numbers 12 to 16, and 36 to 40.

These represent the 10 cores to be licensed and the associated 20 CPU (hyper-thread) numbers. If required, other CPU (hyper-thread) numbers could be chosen as long as the correct hyper-thread doublets are selected.

To put this into OLVM, we must assign each VM CPU to a range that fits into the selected list of BM CPUs. The format is:

&ltVM CPU Number&gt#&ltBM CPU Range From&gt-&ltBM CPU Range To&gt

with each VM CPU definition delimited by an underscore.

Instead of just providing a one-to-one mapping of VM CPUs to BM hyper-threads, it is better to allow each VM CPU to be mapped to a range of BM hyper-threads. This will help to spread CPU load across the cores. Remember, the underlying BM server can also use these cores for its own routines and processes.

So to define the first VM CPU – the numbering starts from 0. In this example, this VM CPU (0) will map to BM hyper-threads 0 to 4. That configuration is specified like this

0#0-4

The sixth VM CPU (5) is to be mapped to the range 12 to 16, and so the configuration for that CPU looks like

5#12-16

So to concatenate all the VM CPUs delimited by underscore results in the following string

0#0-4_1#0-4_2#0-4_3#0-4_4#0-4_5#12-16_6#12-16_7#12-16_8#12-16_9#12-16_10#24-28_11#24-28_12#24-28_13#24-28_14#24-28_15#36-40_16#36-40_17#36-40_18#36-40_19#36-40

The first 5 VM CPUs (0-4) can use the BM CPUs (0-4), the 2nd set of 5 VM CPUs (5-9) can use the BM CPUs (12-16), the 3rd set of 5 VM CPUs (10-14) can use the BM CPUs (24-28), and the last 5 VM CPUs (15-19) can use the BM CPUs (36-40).

Once we have the string, it can be input into the OLVM console.

In the System tab for Edit Virtual Machine, enter the number of CPUs required

Then in the Resource Allocation tab in the CPU Allocation section, enter the CPU string previously defined

The Virtual Machine CPUs should now be pinned to the Bare Metal CPUs and should all be ok for Oracle licenses.

Note that OLVM is free to use, but if you require support, you must purchase the Linux Premier Support option.

For more information, here are two links you may find helpful:
https://www.oracle.com/a/ocom/docs/oracle-linux-virtualization-manager-ds-final.pdf
https://www.oracle.com/a/ocom/docs/linux/value-of-oraclelinux-support.pdf

Please be aware that Pythian is not an Oracle licensing authority or Oracle license re-seller. Pythian is not in a position to present licensing position information directly but can assist through partner resources. To ensure you have the correct license arrangement, you should always confirm with an Oracle Sales Representative.

Thank you for reading!