vsphere: Multiple cores per vcpu about terraform-provider-vsphere HOT 2 CLOSED

I would like to give a hearty second to this enhancement request, and I can cite a strong technical motivation.

If I use TF to provision a Windows 7 machine with, let's say, 16 vCPUs -- I'll end up with 16 sockets with 1 core each. The problem is, the Windows 7 OS can only see 2 sockets and therefore only 2 of those cores. (I just discovered this the hard way when a Windows compile project took 14 hours to complete instead of 2).

It looks like the default in resource_vsphere_virtual_machine.go is 1. It would be wonderful to expose NumCoresPerSocket as a configurable parameter.

  // make config spec
  configSpec := types.VirtualMachineConfigSpec{
    Name:              vm.name,
    NumCPUs:           vm.vcpu,
    NumCoresPerSocket: 1,
    MemoryMB:          vm.memoryMb,
    MemoryAllocation: &types.ResourceAllocationInfo{
      Reservation: &vm.memoryAllocation.reservation,
    },
    Flags: &types.VirtualMachineFlagInfo{
      DiskUuidEnabled: &vm.enableDiskUUID,
    },
    Annotation: vm.annotation,
  }

I just took a peek at the branch for the big refactor release (circa November 2017), and it looks like 1 is still hard-coded.

In addition to the socket count limitations in Windows desktop OSes, the number of cores per socket is also used in the calculation ESXi does when it decides what sort of virtual NUMA architecture to present to the guest OS. Though we may be few, some TF users care about matching the virtual NUMA arch to that of the hosts running the hypervisor. :-)

In addition to possible NUMA misalignment between guest and host, using NUMA at all in the guest OS will be impacted.

Here we have a TF-provisioned VM with 20 cores and 1 core per socket.

[root@cent69-build10 ~]# numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9
node 0 size: 8191 MB
node 0 free: 3497 MB
node 1 cpus: 10 11 12 13 14 15 16 17 18 19
node 1 size: 8192 MB
node 1 free: 1198 MB
node distances:
node   0   1 
  0:  10  20 
  1:  20  10 

And here we have a "manually" provisioned VM with 20 cores and 4 cores per socket.

[root@cent66-pa18 ~]# numactl --hardware
available: 5 nodes (0-4)
node 0 cpus: 0 1 2 3
node 0 size: 1663 MB
node 0 free: 1482 MB
node 1 cpus: 4 5 6 7
node 1 size: 1631 MB
node 1 free: 1562 MB
node 2 cpus: 8 9 10 11
node 2 size: 1632 MB
node 2 free: 1499 MB
node 3 cpus: 12 13 14 15
node 3 size: 1632 MB
node 3 free: 1532 MB
node 4 cpus: 16 17 18 19
node 4 size: 1632 MB
node 4 free: 1538 MB
node distances:
node   0   1   2   3   4 
  0:  10  20  20  20  20 
  1:  20  10  20  20  20 
  2:  20  20  10  20  20 
  3:  20  20  20  10  20 
  4:  20  20  20  20  10 

This is just a long-winded way of saying that sockets matter.

I need to learn golang so I can start helping more directly.

Edited to add some additional NUMA-related motivation.

from terraform-provider-vsphere.

This was added in 1.0.0 and can be controlled by the num_cores_per_socket option.

from terraform-provider-vsphere.