Some vendors license their application per processor, also in a virtualized environment. So if your VM has 4 vCPU’s your vendor will want you to buy a 4 processor license for the application. But you can avoid this by telling the VM that it has cores instead of processors. In others words, instead of having 4 processors you would have 1 processor with 4 cores:
- Power off the VM
- Right click on the VM and select “Edit Settings…”
- Select the “Options” tab
- Click on “General” (in the “Advanced” options section)
- Click “Configuration Parameters…” (in the pane on the right)
- Click “Add Row”
- Enter “cpuid.coresPerSocket” in the “Name” column
- Enter a value (try 2, 4, or
in the “Value” column - Click “OK”
- Power on the VM
The VM will now appear to the OS as having multi-core CPUs with the number of cores per CPU given by the value that you selected. For example, if you create an 8 VCPU VM and set “cpuid.coresPerSocket = 2″ it will be recognized as 4 dual-core CPU’s by the OS while it’s actually utilizing 8 physical cores.
Keep in mind that this feature is currently unsupported!
vSphere 4.0 Quick Start Guide
Duncan,
I had success with this in the beta, but upon attempting it with the GA, I didn’t see any difference between 2 vCPUs or 1 dual core vCPU in Windows 2003.
Also, remember that this may very well put you in illegal waters. Always make sure to check with the vendor if what you intend to do is actually what they licensed you to do.
Hyper-V does this automatically, btw. If you have a 4 CPU VM, and the host is running 4 dualcore CPU, the VM will see two dualcore CPUs. If the host is running 4 quadcore CPUs, the VM will see a single quad core CPU.
Wow, that would be so cool. We run SQL Server in a number of VMs, and SQL is licensed per-socket. So we could save a huge amount of money on SQL licensing alone!
Does this trick only work on vSphere 4, or can we use it with ESX 3.5u4?
I just implemented it in ESX 3.5u2.
@Lukas
I am not certain why you would FUD by saying it could put you in “illegal waters.”
It would certainly seem reasonable that if I have 4x Dualcore processors in the physical system and I have a 2x vCPU VM that I would rather it show as a single socket Dualcore and would certainly be legal. Same as the example you give from Microsoft’s Hyper-V.
I could understand your concern if someone was trying to run a 8x vCPU VM on 4x Dualcore as cpuid.coresPerSocket 4.
However, I would be concerned at that point about performance as I assume you would be limiting Scheduler to run across 2 of your Dualcore processors for each time slice.
Great information Duncan.
Oh Duncan you are so evil, the lawyers are hot on your trail now.
Love this post, it’s one for the 3 ring binder. Thanks!
Little unrelated to the post, but is there an list for available “Configuration Parameters” that can be used?
Lukas, if a vendor doesn’t agree send them to me and I will welcome them into 2009.
If you run SQL Server Enterprise, you only need license it for the underlying CPUs, and you can then run unlimited instances of SQL Server. With a 2-CPU Intel 5500 based server, you should be able to run lots of SQL Server so this can potentialy provide a quick payback.
Surely this could undermine the VMWare limitation of 8vCPU included with Enterprise Plus edition of vSphere?
@roidude, actually you have to license based on vCPUs assigned to each VM.
When you assign 2, 4 or even 8 vCPUs currently they will be presented to the guest as distinct sockets.
With the change Duncan has identified, you can present your underlying hardware of multiple cores per socket to the VM and properly license your SQL instance.
@kiddkoala, how so? This would simply allow you to properly present your underlying hardware up to a new maximum of 8 vCPUs. Sounds perfect to me. This doesn’t change how many vCPUs can be presented to a guest, just HOW they are presented.
indeed, it doesn’t limit scheduling or the amount of vCPU’s just how the GOS sees these.
Duncan,
Have you received any confirmation of support on this? I have submitted it through our Rep as well and have not received any information.
Thank you.
Experimental support only at the moment.
Apologies for my previous comment, I have reread and now fully understand – it will not undermine the licensing at all.
Thank you! I migrated a SQL server to ESXi a while back and had to move from a single-socket, quad-core to a single vCPU because I couldn’t get the OS to detect a second vCPU as a second core and not a separate socket.
Aside from making it easier/cheaper to license per applications per socket, what other uses does this have?
This is fantastic for VDI deployments. Windows XP has a 2 socket limit, so normally that would be 2 virtual cpu’s. But if I buy a high power desktop I can install 2 quad core processors giving me 8 cpu’s. Now I can do this on a VM running XP too! Awesome.
Important note to this.
“The number of VCPUs must be divisible by cpuid.coresPerSocket. So if your VM was created with
8 VCPUs, coresPerSocket can only be 1,2,4, or 8.”
I didn’t quite get the process the first time so maybe this will help the next person to come along.
You first have to determine how many cores you need. If you need 8 cores then assign 8 VCPUs to your machine. Then if you set coresPerSocket to 4, ESX will assume you mean 2 Quad core processors. I first made the assumption that I would assign 1 vCPU and then set coresPerSocket to 2 to get 1 dual core CPU and it just doesn’t work that way.
We have some XP machines we use to build/compile our software for that given platform, and have run into the 2 processor limitation already. Can anyone confirm that they have bumped this up to say 4 cores (2 sockets with 2 cores) or 8 cores (2 sockets with 4 cores) successfully? does this have an adverse affect on co-scheduling that is different from a VM/OS that is allowed to have 4 or 8 sockets?
Andrews says:
-
I just implemented it in ESX 3.5u2.
-
Has anyone else done this on esx 3.5 ?
Regards
Anders
For those of us with Microsoft SQL – They have recently clarified their Processsor based licensing. Licensing for SQL is based on the PHYSICAL processor / per VM. Within a VM, if the host has 4 cores per socket, then a single processor license would allow you to present 4 Virtual Processors to the VM. This was first clarified in answer to a question I posed to a Licensing person at MS – see http://ladylicensing.spaces.live.com/blog/cns!87F95F1B5B21B01E!1558.entry?ccr=136#comment . The official licensing page for SQL 2005 has also been updated to make this a bit more clear.
Hope that helps!
Doesn’t seem to address the problem that it only lets me assign 2 vCPU’s to my XP VM. Not sure if changing the OS type is also required before it will let me do that but am going to give it a shot…
Update to previous – doesn’t seem to work on ESX 4.0
This didn’t seem to work for me in ESXi. I’m running windows 2k8R2 standard. Even after adjusting the “cpuid.coresPerSocket” i’m unable to allocate 8vcpu’s. I had 4 to begin with. I shutdown the vm and tried the “cpuid.coresPerSocket” with 2 and 4. Every time I attempt to increase the vcpu’s it tells me that “Virtual machine has 9 vcpu’s but the host only supports 4. The number of vcpu’s may be limited by the guest OS selected for the virtual machine or by the licensing for the host”. I know for a fact that windows 2k8R2 can take advantace of dual core hyperthreaded procs. Any ideas?
Just tried this again and in ESX 4.0 this works fine as per all the other posts – I just needed to do an update hardware on the VM.