Hyper-V and Mac(HVF) backends have maximum caps on how many vCPUs we can allocate to a VM. Not adhering to them would lead to a failure on VM creation so investigate the caps on each platform to add guardrails.
@tobe2098 This seems like an HVF-specific, macOS-only limitation. We should be checking hv_vm_get_max_vcpu_count() for the QEMU HVF VMs on Mac.
I've also checked Hyper-V. The server SKU caps are well-documented, but for the client SKUs, the documentation is thin. I've found the following code in hcsshim, though, which implies that the client SKUs are bound to the host logical core count:
hostCount := int32(processorTopology.LogicalProcessorCount)
if requested > hostCount {
log.G(ctx).WithFields(logrus.Fields{
logfields.UVMID: uvmID,
"requested": requested,
"assigned": hostCount,
}).Warn("Changing user requested CPUCount to current number of processors")
return hostCount
}
https://github.com/microsoft/hcsshim/blob/8d565b3b866eaeca4906d3c25698ce0fcbc832c7/internal/vm/vmutils/normalize.go#L38-L57
So with that, it's evident that we should have a vCPU count check for Mac and Win. There might be two approaches on how to handle that:
a-) Bail out, show an error that the configuration is not supported
b-) Cap the core count to HVM max cpu/Win logical CPU count, and show a warning.
@tobe2098 What do you think?
Originally posted by @xmkg in #5061
Hyper-V and Mac(HVF) backends have maximum caps on how many vCPUs we can allocate to a VM. Not adhering to them would lead to a failure on VM creation so investigate the caps on each platform to add guardrails.
Originally posted by @xmkg in #5061