A recent post by Microsoft on the Windows Virtualization Team Blog titled “Hyper-V VM Density, VP:LP Ratio, Cores and Threads” caught my eye this morning as I was scanning my RSS feeds. In this post, the author (the anonymous WSV_GUY) works through the idea of cores vs. logical processors. The distinction here, in case you didn’t already know, is that many modern multi-core CPUs also support symmetric multi-threading (SMT, also referred to as hyperthreading), which means that an eight core CPU can actually process 16 threads simultaneously and would therefore be considered to have 16 logical processors.
<aside>I can see where this might be an area of some confusion; in fact, I was just discussing hyperthreading with a colleague last week. In my opinion, it’s far more accurate to refer to current-generation functionality as SMT than hyperthreading, but that’s another story for another day.</aside>
What really caught my eye was the part of the article where the author compares and contrasts Microsoft’s approach and others’ approaches. I’ve taken a screenshot here in case the original article changes. Keep in mind that the article is based on the discussion of maximum virtual CPUs (or VPs, as WSV_GUY calls them) per logical CPU:
Figure 1. Screenshot of Microsoft blog post
So, two things pop to mind immediately. Let’s take these in order.
First—since it’s fairly obvious that Microsoft is targeting VMware as the primary “other virtualization vendor”—it should be noted that VMware does not consistently use cores as their unit of measure. As a point of proof, I present to you this screenshot taken from VMware’s Configuration Maximums document for vSphere 4.1 (available in PDF here). I’ve taken the liberty of highlighting the two key takeaways:
Figure 2. Screenshot of VMware configuration maximums document
As you can see from the documentation, VMware inconsistently switches back and forth from logical CPUs to cores. From that perspective, VMware has some work to do on presenting consistent messaging and consistent documentation. Point taken. VMware, are you listening?
But that’s not really my major beef with the article.
The second thing I noted was the statement in the Microsoft blog (see Figure 1) about “Vendor A” and statements about ratios. Remember that the entire blog post appears to be about maximum ratios: “Vendor A response 16:1 (with the qualifier that your mileage will vary)”. It seems to me that the author is referring to the statement at the bottom of the VMware configuration maximums document (see Figure 2) that discusses the achievable number of virtual processors per core. However, we’re not talking about achievable ratios, we’re talking about maximum ratios, right? Or are we?
Although the Microsoft author appears to ding VMware for making a statement about achievable ratios in an article discussing maximum supported ratios, later in the same article the author does the same thing (the emphasis is mine):
You can see that even with an 8:1 VP to LP ratio (or 16:1 VP: Core, if you prefer), Hyper-V supports very dense VM configurations. Even on a server with two physical processors, Hyper-V supports a staggering number of virtual machines (up to 256). The limiting factor won’t be Hyper-V. It will be how much memory you’ve populated the server with and how well the storage subsystem performs.
Sounds to me like Microsoft is saying that they have a maximum ratio of virtual CPUs to logical CPUs, but that the actual ratio can you achieve (the achievable ratio?) might be less than that. How is that any different from the statement in VMware’s configuration maximums document? How is Microsoft’s “approach” with regard to ratios any different, better, or clearer for the customer? Yes, VMware’s documentation is inconsistent. But when it comes to maximum ratios vs. achievable ratios, it seems to me that the pot is calling the kettle black.
If I’m off or I’m overlooking something, please let me know by speaking up in the comments. Please use full disclosure of your employer where that employment might affect your viewpoint. Thanks!
Tags: HyperV, Microsoft, Virtualization, VMware, vSphere
-
Is the fun number is the 128 Logical CPUs per host?
Do we assume that’s with SMT/HT – and do we take the 128/2 = and get 64 CPUs per host.
Quad Core CPUs = 16 sockets
Six Core CPUs = 8 sockets (well its 10.66)
Eight Core CPUs = 8 socketsNo one makes a 16 socket server (and I know you can NUMA up a couple 4 sockets, etc) – so what are we looking at.
4 Socket – 8 Cores = 32 Logical CPUs without SMT/HT
4 Socket – 8 Cores = 64 Logical CPUs with SMT/HTor
2 Socket – 8 Cores = 16 Logical CPUs without SMT/HT
2 Socket – 8 Cores = 32 Logical CPUs with SMT/HTAnd then the amount of VMs (with 1 vCPU or 2 vCPU – Desktops) that can be fit on the hosts in order to show a density which in turns shows the # of servers required, which in turn shows the cost of the computer layer which is then added to the 3S (services, storage and services layer) and then divded by the number of desktops to get a ROI of $$$ per desktop!!
Cuz VDI is all about the cost savings – right?
HAHA.
Is anyone running 25 vCPU’s to a 1 CORE (without SMT/HT) or 25 vCPU to a 1/2 a core (with SMT/HT)?
That number seems high – like its theoretical vs. a real number.
-
@Scott – its Jeff Woolsey from MSFT is WSV_GUY (his twitter ID)
-
Not sure what point they are trying to make. Isn’t density always impacted by the type of workload? Regardless of which hypervisor we are talking about, type of workload will influence consolidation ratio.
-
He seems to be unable to argue on the merit of Hyper-V and instead decides to nit-pick wording to make Hyper-V appear to have an edge. I’d say that harping on “mileage may vary” is disingenuous at best.
To me his definition:“Microsoft provides a maximum for virtual processors per logical processor, where a logical equals a core, or thread.”
Seems to imply that an SMT thread is 100% equivalent to a CPU core.
As an independent services consultant I find that WSV_GUY is doing nothing more than discrediting his position. At the end of the day, mileage will vary with any virtualization solution and you can easily back yourself into a corner by using any vendor supplied recommendations.
-
It seems to me that the focus of the Microsoft article was on defining how they calculate their ratios and what the difference is, high or low, when looking at “other vendors”.
I see what you are saying about pointing out the workload caveat and then adding it later in their own statements but I didn’t read that as the main point. If you hadn’t written your blog post I probably wouldn’t have noticed it.
-
I don’t get it either. I wasn’t going to chime in on this one at all, but after reading what Ducan said… yeah I agree completely. The way I read the quoted Microsoft statements, it’s like they’re saying their hypervisor can support so many vCPUs per logical processor regardless. Really? I mean, if you have a bunch of apps that are all demanding really high CPU times that number probably comes down, or at least the amount you can achieve comes down… supported or not. Maximum supported is just a number given everything is perfect world to achieve it. No way the numbers they’re listing are always possible. What I don’t get, is they say the number can drop depending on the storage and memory load… do what? CPU load has nothing to do with it? Yeah. OK. I don’t believe them… the magic hypervisor that creates CPU cycles out of thin air! It doesn’t say that directly, but it really looks implied. It is probably unintentional — in that case then its definitely a case of the pot calling the kettle black as Scott said.
-
All,
I think the purpose of the article was to make Hyper-V’s VP:LP ratios look better than VMware’s. After all, if VMware uses 16:1, and Hyper-V actually gets 24:1 with Windows 7, then Hyper-V must be better, right? In the end, though, he only ended up looking silly. He focused on maximum ratios throughout the article but then pulled a “it depends” at the end, after having criticized VMware for an “it depends”! That’s my biggest complaint with the article.
-
Anyone got a real world number of ratios of vCPU:pCPU?
I heard that the VMware TAMs collect this data and that VMware has access to it but its kept behind a pair of locked golden doors that only Paul Maritz has the keys.
-
@Rob – Real world numbers are going to vary because of workload, but I’d venture to say its in the range of 10-15:1 vs the 25:1 possible ration. Also, you mentioned the lack of 16 socket servers to reach 64 cores, but Ive noticed 6 Core procs are starting to be up and coming, which would allow the 64 cores in 10.66 (8 sockets), but thats just an FYI.
@ Scott/Duncan – Microsoft has a bad habit of resorting to the ‘Sales Pitch.’ A colleague of mine ran into it just yesterday with MS trying to pitch App-V and Hyper-V over ThinApp/View or XenApp/XenDesktop when its common knowledge that MS is playing catchup in the virtualization field. But they will beat the sales pitch dead horse over and over to argue with you. I commend MS for coming up with these die hard guys who defend their product to the end, but at least go about it in a reasonable way. Lets be honest, as a 25 year old, theoretically I should be able to do lots of physical activities and have no issues. But the truth is, Ive eaten enough fast food to kill two people and don’t exercise nearly enough as I should, so it ain’t happening. Maybe I should start pitching myself on a dating site in the ‘theoretical’ description.
-
Doesn’t 4.1 Update 1 support 160 CPU’s in a host now?
-
It seems to me that this is MS simply trying to catch up to VMWare with marketing and not actually with technology. You have to admit that there are some sysadmins and IT managers that would read these articles and simply accept them. I’ve fielded sales calls from MS and other vendor reps that tout what I’d call “false statements”. Like with any vendor you need to think critically about their statements, metrics and applicability to your environment.
-
Disclaimer: I work for Microsoft NZ, but these are my opinions and observations only. I’m not posting on behalf of Microsoft here.
I think the article had two main purposes:
1. Clarify what the VP:LP supported ratios actually mean, and how LP’s translate to processors/cores/threads
2. Allow customers to be clear around what the competition say about Hyper-V (i.e. that the VP:LP ratio isn’t as good as VMware’s), and what is the actual truth.Cheers
Stu
-
Stu,
Thanks for your comment. That’s fair enough, but as I stated earlier the article came across disingenuous—downright deceitful, in fact—because of the “flip flop” between maximum VP:LP ratios (which were the initial focus of the article) and achievable VP:LP ratios (which were the focus of the latter part of the article).
Now, I’ll be completely forthright and say that VMware has had their fair share of similar tactics from time to time (as has every vendor, I think), so I’m not picking solely on Microsoft.
Thanks again for your comment, Stu! One of these days I’m going to get to visit NZ, I hope.
-
Going back to the original comment (Rob Bergin) for a moment…
IBM have an X3850 which can have 4 sockets with 8 core CPU’s – that’s 64 cores with SMT enabled… you can then actually join two of these units together into a single host… reaching that 128 logical CPU maximum…
On top of that, this server is capable of utilising 10-core CPU’s, which will equate to 160 logical CPU’s with SMT enabled…
So it is possible to reach that maximum now and in fact, break it… though I’d hate to see the cost of that host!!!
In case anyone is interested, this is the link to those systems:
http://www-03.ibm.com/systems/x/hardware/enterprise/x3850x5/index.html
Oh, and a 2 node version of the x3850 is supported by ESX(i) 4.1 U1
http://www.vmware.com/resources/compatibility/detail.php?device_cat=server&device_id=14912
-
Disclaimer: I work for VCE – these are my own personal opinions.
I’ve read that article a couple of times and I have only one main take away: Microsoft is attempting to deliver a consistent message about what their ***supported maximum*** ratios are for Win7 VDI instances and also for server virtualization.
In the FAQ section, there was a question that read “Is the 12:1 VP:LP ratio a hard block? What happens if I attempt to start a 13th virtual machine? Will it be blocked?” The answer, to summarize, is no it won’t get blocked – these are just support metrics.
To me that says that, depending upon your hardware configuration, you can achieve a maximum of 12:1 for VDI instances running Windows 7.
I understand Scott’s point about the “Your mileage may vary” because oversubscription policies and consolidation ratios always vary depending upon the workloads but I don’t believe that was the intended message.
I saw that post as MS drawing a line in the sand and saying this is the maximum of what we’ll support – you may or may not achieve that but if you do…you’re covered. I’ve never seen that specific of a claim from any other virtualization vendor.
Site Sponsors
15 comments
Comments feed for this article
Trackback link: http://blog.scottlowe.org/2011/04/26/is-the-pot-calling-the-kettle-black/trackback/