2

In the VMware Infrastructure Client (no vCenter), under the Resources / Advanced CPU section of each VM's Edit Settings dialog, there is an option to alter the Scheduling Affinity of a VM. It sets the sched.cpu.affinity value in the VMX file.

I believe this allows me to force a VM to only be serviced by a specific physical CPU on the host, judicious use of which might in some cases allow me to license a VM for one physical CPU rather than the two that are in the host.

The description of the config field in Edit Settings is as follows:

Hyperthreading Status: Active

Available CPUs: 12 (logical CPUs)

Select logical processor affinity for this virtual machine.

Use '-' for ranges and ',' to separate values. For example, "0,2-4,7" would indicate processors 0, 2, 3, 4 and 7.

Is it fair to assume (in this and similar cases):

  • numbers 0 to 11 represent each of the physical cores (or are the 'hyperthreads' numbered too)?
  • if I wanted to limit the VM to run on one of the physical CPUs, I should enter either 0-5 or 6-11 (or are these numbers in some different pattern)?

Otherwise, is there a reliable source (VIC screen, shell command, etc.) to look up the number-to-CPU mapping on any particular host?

(For reference, the CPUs are Intel Xeon X5675 units, which are each 6-core with hyperthreading.)

jimbobmcgee
  • 2,645
  • 4
  • 24
  • 40
  • Why do you want to do this? For licensing? – ewwhite Dec 24 '14 at 16:01
  • @ewwhite - yes, I'm hoping to avoid an expensive second processor license afer a P2V, but appreciate that it will be subject to the letter of the EULA (which itself might be subject to the phase of the moon) – jimbobmcgee Dec 24 '14 at 16:19
  • Assign the VM *one* CPU socket. That's probably the right way to handle this. What software requires the licensing? – ewwhite Dec 24 '14 at 16:20
  • @ewwhite - appreciated, but that would be P2V from a physical with a single quad-core to a virtual with one single-core. I am actually defining 1 virtual socket with 4 virtual cores but, as I understand it, ESXi is free to distribute those across the host as it sees fit. – jimbobmcgee Dec 24 '14 at 16:26
  • No, I said *single socket*, not single core... – ewwhite Dec 24 '14 at 16:28
  • @ewwhite - "I am actually defining **1 virtual socket** with 4 virtual cores but, as I understand it, ESXi is free to distribute those across the host as it sees fit" – jimbobmcgee Dec 24 '14 at 16:29
  • Why does it matter how the host distributes the vCPU load across the pCPU's? If the software is licensed per socket (and not per core) and you assign it a single virtual socket (single or multi core) then why would it matter how the vCPU load is distributed across the pCPU's in the host? – joeqwerty Dec 24 '14 at 16:31
  • @joeqwerty - Some of the more-egregious EULAs I've read do make a distinction between virtual and physical processors, and require that the software only runs on one physical processor. However, this wasn't *supposed* to be a discussion about licensing -- can I steer it back to the technical aspect?! :-) – jimbobmcgee Dec 24 '14 at 16:52
  • Gotcha. You're interested in whether or not the desired outcome is achieved. Carry on. :) – joeqwerty Dec 24 '14 at 16:53

2 Answers2

1

Is it fair to assume (in this and similar cases):

  • numbers 0 to 11 represent each of the physical cores (or are the 'hyperthreads' numbered too)?

Yes and yes HT are included

  • if I wanted to limit the VM to run on one of the physical CPUs, I should enter either 0-5 or 6-11 (or are these numbers in some different pattern)?

Yes, you got it in one!

Chopper3
  • 100,240
  • 9
  • 106
  • 238
1

Your software is likely licensed per (visible) CPU socket. If you configure your destination virtual machine with the appropriate socket and core count, it doesn't really matter where ESXi decides to schedule threads on the underlying hardware. Your software should only be concerned with what's visible to the virtual machine. In this case, a 1-socket, 4-core VM should satisfy the requirement.

See: vCPU performance between 1 or 2 vCPU's

Just like taskset and CPU scheduling on Linux, you don't want to go down the path of CPU-affinities and pinning unless you have a compelling reason.


Edit:

The numbering is the same as taskset. For a Westmere 6-core CPU, you will see physical and Hyperthreaded cores according to this schedule:

  NUMANode L#0 (P#0 32GB) + Socket L#0 + L3 L#0 (12MB)
    L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0
      PU L#0 (P#0)
      PU L#1 (P#12)
    L2 L#1 (256KB) + L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1
      PU L#2 (P#2)
      PU L#3 (P#14)
    L2 L#2 (256KB) + L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2
      PU L#4 (P#4)
      PU L#5 (P#16)
    L2 L#3 (256KB) + L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3
      PU L#6 (P#6)
      PU L#7 (P#18)
    L2 L#4 (256KB) + L1d L#4 (32KB) + L1i L#4 (32KB) + Core L#4
      PU L#8 (P#8)
      PU L#9 (P#20)
    L2 L#5 (256KB) + L1d L#5 (32KB) + L1i L#5 (32KB) + Core L#5
      PU L#10 (P#10)
      PU L#11 (P#22)
  NUMANode L#1 (P#1 32GB) + Socket L#1 + L3 L#1 (12MB)
    L2 L#6 (256KB) + L1d L#6 (32KB) + L1i L#6 (32KB) + Core L#6
      PU L#12 (P#1)
      PU L#13 (P#13)
    L2 L#7 (256KB) + L1d L#7 (32KB) + L1i L#7 (32KB) + Core L#7
      PU L#14 (P#3)
      PU L#15 (P#15)
    L2 L#8 (256KB) + L1d L#8 (32KB) + L1i L#8 (32KB) + Core L#8
      PU L#16 (P#5)
      PU L#17 (P#17)
    L2 L#9 (256KB) + L1d L#9 (32KB) + L1i L#9 (32KB) + Core L#9
      PU L#18 (P#7)
      PU L#19 (P#19)
    L2 L#10 (256KB) + L1d L#10 (32KB) + L1i L#10 (32KB) + Core L#10
      PU L#20 (P#9)
      PU L#21 (P#21)
    L2 L#11 (256KB) + L1d L#11 (32KB) + L1i L#11 (32KB) + Core L#11
      PU L#22 (P#11)
      PU L#23 (P#23)
ewwhite
  • 194,921
  • 91
  • 434
  • 799
  • Was this generated from a command, or found in a reference article? – jimbobmcgee Dec 24 '14 at 16:47
  • I just pulled the CPU topology map from one of my Westmere-based servers. – ewwhite Dec 24 '14 at 17:02
  • OK. But is the number range I would enter into the field based on the `L#n` numbers in the `L2` lines (so `0-5`); on the `L#n` numbers in the `PU` lines (so `0-11`); or the `P#n` numbers in the `PU` lines (so `0,2,4,6,8,10,12,14,16,18,20,22`? – jimbobmcgee Dec 24 '14 at 17:09
  • I'm not suggesting you do this. Seriously. – ewwhite Dec 24 '14 at 17:18
  • Noted and accepted. That said, which set of numbers is the right one? – jimbobmcgee Dec 24 '14 at 17:40
  • 0-11 are CPU socket #1, 12-23 are CPU socket #2. You can be picky and excluded Hyperthreaded cores. But that's the numbering. – ewwhite Dec 24 '14 at 18:07
  • Thanks. For completeness, running `esxcfg-info -w` from the shell will list each physical CPU as a `CpuPackage`, under which it shows each thread as a `CpuImpl` -- the `ID` property of that appears to marry with `0-11` and `12-23` also, so it stands that one could use this for reference on any arbitrary host. – jimbobmcgee Dec 24 '14 at 18:17