Hard partitioning with Oracle VM Server for x86so i guess the doc stating that editing the vm.cfg is not supported is a doc bug - can this be fixed?
With Oracle VM server for x86, guests are allowed to be pinned or bound to specific physical cores in a single Oracle VM server, see "Hard Partitioning with Oracle VM <http://www.oracle.com/technetwork/topics/virtualization/ovm-hardpart-167739.pdf>". Once hard partitioned, the VM guest application only needs to be licensed for the number of physical cores it is pinned to, see Oracle's licensing policies for partitioned environments <http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf> . Note that once a VM guest is pinned or bound to physical cores within a server, Oracle licensing restricts that guest from being live migrated to another VM server in the pool.
Martin Brambley wrote:If you edit vm.cfg on an HT-enabled machine, with cpus = '0-3', you'll be running on 2 cores, 4 threads. So, you can set it to 0-7 to run on 4 cores/8 threads. This is a bonus with hyperthreading: because we license by core, not thread, you can effectively double the vCPU count of your guests with the same core licensing. Another reason not to disable hyperthreading. :)
if i edit vm.cfg to to enable hard partitioning and say cpus = '0-3' does that fix the guest to using 4 cores (which would be 8 out of the 80 recognised by ovm) or 4 of the entities seen as cores to ovm (4 threads out of the 80)
the new doc states that editing vm.cfg is not supportedThe documentation will be updated with the release of 3.0.3 to specifically allow editing of vm.cfg for hard partitioning purposes.
so whats the deal? do i have to revert to ovm2?No.
if i have a 10 core server without HT turned onThe effective CPU capacity of your guests has not been reduced, but your overall capacity has increased. If you disable HT, then the server was only running a single thread per core anyway. So, if you enable HT without changing your guests, you're still only running on a single thread per core. You can now double your vCPU counts in the guests to 10 and still sit within your license requirements (as you're still only using 10 cores on the physical server).
and i have 2 guests configured to use 5 processors
if i then enable HT so that ovm then reports there are 20 cores available
has the effective CPU capacity of my guests just been reduced as they still say 5 processors (out of the now 20 reported for the vmserver?)
Martin Brambley wrote:It already has been fixed. The fix will be published with 3.0.3.
so i guess the doc stating that editing the vm.cfg is not supported is a doc bug - can this be fixed?
user10786594 wrote:I believe with OVM3, the threads/cores are numbered sequentially, so 0-1 are threads on core 0 and 2-3 are threads on core 1. However, I'm not 100% sure, so I'm double-checking with the development team.
With HT on, will vcpus 0-1 be the two threads on core 0? Or could, say, vcpus 0+8 be the two threads of core 0?
user10786594 wrote:xm info on OVM3 shows you the node (socket) and core/thread mapping. Here's an Intel Westmere-EP box with 2 sockets:
I recall someone mentioning some time ago that the way the virtual cores are numbered can, depending on CPU model, not necessarily be obvious?
So, cpus 0-5 are the first threads on the first 6 cores of socket 0. The second 6 threads on socket 1 are numbered 12-17. On node 1, we have 6-11 being the first six threads and 18-23 being the second.
nr_cpus : 24 nr_nodes : 2 cores_per_socket : 6 threads_per_core : 2 ... node_to_cpu : node0:0-5,12-17 node1:6-11,18-23
The development guys tell me this numbering is stable for a given machine, but may not be stable between machines.
node_to_cpu : node0:0,4,8,12,16,20 node1:1,5,9,13,17,21 node2:2,6,10,14,18,22 node3:3,7,11,15,19,23
This will show you the exact logical CPU to core/socket mapping:
# xenpm get-cpu-topology
CPU core socket CPU0 0 0 CPU1 1 0 CPU2 2 0 CPU3 8 0 CPU4 9 0 CPU5 10 0 CPU6 0 1 CPU7 1 1 CPU8 2 1 CPU9 8 1 CPU10 9 1 CPU11 10 1 CPU12 0 0 CPU13 1 0 CPU14 2 0 CPU15 8 0 CPU16 9 0 CPU17 10 0 CPU18 0 1 CPU19 1 1 CPU20 2 1 CPU21 8 1 CPU22 9 1 CPU23 10 1
Julian Mccoy-Daly wrote:Correct.
On the subject of hard-partitioning licensing a subset of cores of a physical OVM server, and pinning all VMs using the product to those same cores, where you are running a pool with multiple VM servers does this not suggest that you should also be using a placement policy to run them on the same physical server? Otherwise you would be licensing these same cores over all machines in the pool - 4 cores x 5 potential servers = 20 cores *0.5 processor factor = 10 cores.
As far as I can see, placement policy has disappeared from OVM 3 and affinity and anti-affinity policies would not seem to offer the required functionality.You can use storage repositories as a method of placement policy in OVM3: create a storage repository for those specific guests and only present it to a subset of servers in the pool. Then the guests in that repository can only start on those servers. And it doesn't have to be a large repository: just needs to store the vm.cfg files for the guests, not the virtual disk images.
Julian Mccoy-Daly wrote:Correct.
"Hard partitioning is the ONLY case where you are allowed to modify the virtual machine configuration file manually. For all other changes to a virtual machine, use the Oracle VM Manager user interface."
And the implication here is that it is modifying the vm.cfg to add the pin statement, not to add repositories that are manually created with the VirtualMachines/VMUUID/vm.cfg that is then modified to point back to the vm image in a different repository.Why would you need to do this? You can select which repository is used to store the configuration file on the first step of the Create VM wizard. Just select the repository that's only presented to the subset of servers. No manual modifications required at all.
What you say about hard partitioning makes a certain amount of sense to me, but:They're tied to a physical CPU, which implies a physical server. As long as you're only using the CPUs you've paid for, you're OK. The onus is on you to ensure that you only use licensed CPUs, though.
1) None of the Oracle docs I have seen suggest that you need to actually tie a vm to a particular server
2) None of the other hard partitioning technologies would allow you to commit potentially many VMs to the same subset of CPUs - would they?Some of them do, but perhaps none as flexibly as Oracle VM for x86.