4

I have a number of Virtual Machines that were created from physical servers. Some of these have (in my opinion) an inappropriate number of processors - for example, we have a web application, accessed internally only, running on a VM with 4 processors allocated. This is the highest specced of our VMs, but there are others I suspect are overspecced.

As I understand it, this can result in performance degradation, as the hypervisor waits until 4 processors are free on the host machine when allocating processor time to this VM. It also causes problems when trying to migrate the VM between hosts. Are these fair assumptions?

Looking at the server itself, I don't see any reason why it needs 4 processors. It just happens that the physical server it had been installed on had that number of processors.

So the question is - what risks are there in reducing the number of processors on this VM?

Some details:

We are running VMware ESX 3.5 on servers with 8 cores and 20Gb. The VM in the example above has 4 processors allocated and 3Gb RAM. The server OS on the VM is Windows Server 2003 Standard SP2 (not R2).

dunxd
  • 9,482
  • 21
  • 80
  • 117

2 Answers2

5

The only serious complication may come from going from multicore (ie 2 or more) to single core. Windows 2000, XP, and 2003 (im not sure about vista, 2008 or 7) used a different kernel for multicore than they did for single core. That said, its probably just going to be some kind of performance penalty, rather than things blowing all the way up.

I would check to make sure that any critical applications didnt get processor affinity set as well - that could ruin your day. see here: http://forums.whirlpool.net.au/archive/735180 or https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-6168870.html

Edit: the same will be true of linux, however the SMP core issue is simply one of performance rather than full-stop issues. linux, on the other hand, is much easier to set processor affinity permanently. see http://www.cyberciti.biz/tips/setting-processor-affinity-certain-task-or-process.html

Community
  • 1
Devnull
  • 951
  • 1
  • 7
  • 23
  • 1
    +1, I was going to mention the potential single core issues, but then I just thought (same as you) it was not going to be dangerous at all; but it's anyway good to be aware of it. – Massimo Aug 27 '10 at 12:12
  • Thanks for the info on the different kernels. It sounds like there is some risk (but small) attached to reducing the number of processors, but only if going from multi- to single-core. So to minimise risk it may be better to reduce my quad-core VMs to dual core, rather than dropping to 1. Given what Helvick said about the scheduling, this sounds like the most sensible approach. I've given this answer as the solution - unfortunately I can't give to both. Massimo doesn't seem to need the points very much so I am sure will understand. :-) – dunxd Aug 31 '10 at 09:24
3

Yes, your assumptions are correct: the ESX scheduler needs to have 4 available cores in order to schedule execution of a VM with 4 vCPUs, so it will just not run at all if only 2 or 3 of them are available, regardless of how the VM is actually going to use them; the guest O.S. may have only one thread running, but the ESX scheduler will still not be able to make the VM run if there are not enough available free cores.

Reducing the number of vCPUs is generally a safe operation, but this strongly depends of the guest O.S., which will actually need to cope with the (virtual) hardware change. Recent Windows and Linux systems usually don't have any trouble with this.

Massimo
  • 68,714
  • 56
  • 196
  • 319
  • Thanks - I added the server OS in now :-) Windows Server 2003 Standard SP2 (not R2) – dunxd Aug 27 '10 at 10:43
  • 1
    That should be totally safe, then. I've increased and reduced the number of vCPUs for 2003 guest systems lots of times, never having any issue at all. – Massimo Aug 27 '10 at 10:45
  • 5
    This is mostly but not entirely true - fewer cores are much easier for the Hypervisor to schedule but ESX and ESXi have not required totally strict co-scheduling in the way you describe since V3.0 - some amount of skew between vCPU's is allowed. There's a nice summary of how this has changed in this VMWise article http://vmwise.com/2010/07/09/what-is-co-scheduling-anyway/. The general recommendation to limit vCPU's per VM remains good advice though. – Helvick Aug 29 '10 at 11:16
  • @Helvick - thanks for article. From my understanding of it, the problems of inappropriate multi-processor may not be as bad as suspected. My assumptions were not 100% wrong, but the situation is not as simple as I thought. Reduces the urgency of making any change, but I think I'll make it anyway. – dunxd Aug 31 '10 at 09:22