Without wanting to bag a particular vendor...(!)
Let's say that you have a dual quad-core hyperthread enabled server (two physical CPUs, eight cores, 16 threads or logical CPUs). On this server runs an application that is CPU hungry. The application is limited to four CPUs and to use more you need to pay a significant dollar increase into the next version. This isn't a problem on the physical server since there are only two CPUs and you get to use all the cores and all the threads you need.
Enter virtualisation for whatever reason. Let's say, workload mobility, DR capability. Whatever. You decide to virtualise.
Now; heres the things. Under virtualisation you can only present (due to CPU limits) four vCPUs. Each CPU is considered, and presented as, a single-socket, single-core, single-thread processor. Essentially, you can now only use one quarter of the available CPU resource. In fact, if you choose to spend the dollars (and a lot of them!) you could go to eight vCPUs but even this is only half the available CPU resource. What is ironic, in this scenario, is that the application license actually would allow for eight vCPUs in the normal version even though it has a four CPU limit!
Ok, so with the CPU intensive application this now a bottleneck at 'more than average' times, such as when performing queries and reports.
Here's the question / discussion:
...has anyone been in this situation, and if so, how was it resolved? Did you a) not virtualise, b) find a workaround (what?) or c) pay the extra for the higher version?
Second opinion point; its time for application vendors to move away from processor limits and licensing. In the modern world, it simply isn't going to fly. Telling a customer they need to spend NZ $30k - NZ $40k so they can use only half of their available CPU resource on a dedicated server just because they want to slide a hypervisor in there is just BS.
What would you do / have you done?
Thank you for that. It *almost* resolves my problem, the exception now being the licensed version of vSphere.
Unfortunately, the way the tweak works is to present each allocated vCPU as a core, rather than as a socket, rather than 'split' a vCPU into cores.
This means that I can still only allocate 4 vCPUs to the VM since vSphere4 Advanced has a 4-vCPU limitation. Nuts.
However, if I run sysinternals "coreinfo" I can at least see that the VM now sees a single socket and four logical CPUs.
My next step will be to see if we can uplift to Enterprise under vSphere4 given that we have maintenance and get an automatic uplift to vSphere5 Enterprise. I guess that will depend on how friendly and accomodating the VMware licensing team are willing to be. Unfortunately, for a number fo reasons, we cannot upgrade the platform to v5 any time soon.
Even if we *can* uplift to Enterprise, we will still be limited to 8 vCPUs since to go higher requires E+. Ah well, maybe that will be enough. At least we can work around the 4-CPU limit of said application and OS (for now). Cheers.