Microsoft Hyper-V Server CPU Scheduling and NUMA Memory Architectures

Both of the other answers are correct. Calling Microsoft for support with Hyper-V and Windows 2000 will result in being told that the only supported configuration involves one virtual CPU.

With that said, I suspect that you got exactly the same performance each time because Windows 2000 didn't automatically reconfigure itself as a multi-processor installation when you added virtual CPUs. Win2K was only using one CPU, even when you assigned it four.

You need to go to device manager and change the HAL from the single processor HAL to the multi-processor HAL. (Update driver on computer type.) That will trigger the installation of the multi-processor kernel, ntdll, HAL, etc. My memory says that there were about six binaries that changed.

Note that this is a one-way trip. Your Win2K VHD will be running multi-processor code indefinitely after that, even if you go back to a single virtual CPU. You might want to back up your VHD first, as these multi-processor binaries are less efficient than the single-processor ones when running single vCPU.

Lastly, please understand that the reason that Microsoft isn't supporting more CPUs for Win2K has partly to do with the fact that the Win2K kernel has no idea isn't being virtualized and it has some hard assumptions that all CPUs run all the time. Breaking this assumption by virtualizing more processors will result in less than linear performance gains (cough, cough.) You might get reasonable performance with two processors. More will probably not help.

It is a trade-off. Say you have four physical cores and two VMs.

If you map two virtual cores in each VM, then pretty much each guest will see what it expects. It will see two cores that it expects to have full control over and more or less get that. (Assuming host load isn't high.) You won't often confuse the guest's scheduler with a case where it assigns a task to a core expecting the task to be done immediately and instead the task does not get done because no physical core is available. However, if one guest is CPU-starved and the other is idle, two cores will be twiddling their thumbs.

On the other hand, if you give each guest four virtual cores, each guest will be able to use all the available CPU power when the other guest and the host don't need it. However, when there is load from another source, the guest's scheduler will not get the behavior it expects and some tasks will get started immediately and some won't in a way that the guest's scheduler can't easily expect and deal with.

My recommendation is generally to put as many physical cores as you have in each VM that might ever be expected to need a lot of CPU. The exception would be if you have VM's that are critically dependent on latency. I would also reduce the core count on any "smaller" or "less important" VMs that share a physical box with more critical VMs.

The hypervisor assigns logical cores to physical cores as part of its scheduling policy. There is no fixed mapping unless you specifically make one. (Which I don't recommend except in the one specific case where you want to reserve a core for a latency-critical VM.)