As readers of this blog will be well aware, one of the key additions to Hyper-V R2, was Live Migration. Prior to R2, Hyper-V had a capability known as Quick Migration, which enabled a virtual machine (VM) to be migrated from one physical host to another, but included a pausing of the VM as it was moved. VMware, who’d had Live Migration, known as VMotion, for some time before this, inevitably picked up on this, and thus branded Hyper-V insufficient for an Enterprise’s needs. Still, 100+ case studies later, Hyper-V R1 has established a solid foundation, with a low TCO, ready for R2 to take over the baton.
Now R2 is here, and features like Live Migration, Hot-Add of storage, Cluster Shared Volumes, Redirected I/O, and more, are all baked into the product for free, the direction of the argument has changed. No longer is it about ‘We have Live Migration and you don’t’ – it’s all changed to a ‘We have a lower cost-per-application than you’. An application being a VM in this case. There’s a prime example of this argument being presented by VMware, in this video, aptly titled, “VMware slams Microsoft”. I’ll let you make your mind up on that one.
What’s interesting is, that neither VMware’s, nor Microsoft’s pricing models really reflect a cost-per-app comparison, yet the cost-per-app calculator is being used to prove that VMware vSphere does in fact have a lower cost-per-app than a Hyper-V & System Center combination.
In this post, we’re going to investigate how much of this is actually true…I work for Microsoft, but that doesn’t mean that I don’t appreciate VMware technologies. My role is to ensure Microsoft Partners can build successful virtualisation practices around Microsoft virtualisation, and articulate the key values of our virtualisation technologies, so they, the Partner, can provide the right solution for their customers. This isn’t about slating any of their technologies, as they are the market leader, and in many ways, have defined where virtualisation has got to today. I am a VCP (not vSphere :-( ). This post is purely concerned with addressing the cost-per-application calculations.
So, here we go…
Firstly, where can you find the cost-per-app calculator? Here: http://www.vmware.com/technology/whyvmware/calculator/
Let’s plug in some values:
# of Applications to Virtualiise – 100
Virtualisation Host Type – Server B
Networked Storage Type – iSCSI SAN
Compare to Vendor – Microsoft
VMware vSphere Edition – Enterprise Plus
Physical/Virtual Management – Virtual
Electricity Costs – Average
Datacenter Space Costs – Average
OK, so that’s the values plugged in, what pops out the other side?
“The unique features and architectural design of VMware vSphere 4 allow you to run many more applications per server (higher VM density) at an acceptable level of performance than other virtualization solutions. In our own testing and from reviews of our customers, we have seen VMware vSphere 4 users commonly achieve 50-70% higher VM density per host than with Microsoft Hyper-V, resulting in a 20-30% lower cost per-application.
Based on your inputs, the cost-per-application to virtualize 100 applications using VMware vSphere 4 Enterprise Plus Edition is $2,299 -- 3% lower* than with Microsoft Hyper-V R2 and System Center.”
Let’s just dissect what that is saying for a moment there. So, vSphere can provide higher levels of density, through the use, predominantly, of Memory Oversubscription/Overcommit (a feature Hyper-V, even in R2, doesn’t have). Based on this, you’d run more VMs per host, thus you’d need less hosts. We’ll investigate this more later. However, look at the last line of the first paragraph. “…resulting in a 20-30% lower cost-per-application. This is actually in line with what was said in the video I mentioned, and linked to, earlier. Also, what’s an acceptable level of performance? Hmmm!
However, the very next line, based on my inputs, suggests that the saving is actually 3% lower, (as opposed to 20-30%), and notice the little * after “3% lower”? This is to indicate, and I quote, “Assumes that a VMware ESX server can run 50% more applications than a Microsoft Windows Server 2008 (Hyper-V) host”. Firstly, where’s R2 gone from the comparison, and secondly, its an assumption that everyone uses Memory Oversubscription, to that level, and thus makes those gains.
What is Memory Oversubscription?
I’m not going to take anything away from VMware here. What ESX can do with memory management is very impressive indeed. There’s a great whitepaper that’s just been made available to download discussing the main techniques ESX uses to manage memory, with little impact to performance in most cases. In a nutshell, Memory Oversubscription is made up of three key mechanisms, Transparent Page Sharing, Ballooning, and Hypervisor Swapping, with the latter being the least desirable, as it can have a considerable performance impact. For the purpose of this discussion, Memory Oversubscription is a mechanism where, if a VM isn’t using all of it’s allocated RAM, say, it’s using 800MB of it’s 2GB allocation, that remaining 1GB ish, can be returned to, almost like a pool of spare RAM, which can then be used by other VMs. This can, as the information above states, allow more VMs to run on a host, providing they don’t all need their full allocation of RAM at once. To simplify, if you had 16GB RAM, you could, potentially, get 16 x 2GB RAM VMs running on that host, with little performance impact, providing that the total working set of memory in the VMs is less than the 16GB RAM. TPS would obviously help here. However, if all of those 16 VMs starting to go mad with a craving for RAM, and they all needed their 2GB, you could find yourself in a situation where you are hypervisor swapping, which isn’t, and VMware would accept this, the best place to be. For more info on Memory Oversubscription, there is a great explanation here.
Do I wish Hyper-V had some of these memory management techniques? Sure! If only to give people the opportunity to evaluate, and test it, and see if it is the right fit to use in their environment. Plus, I could get more VMs on my Shuttle PC :-)
To contrast this, Hyper-V’s approach to memory, at a high level, is more simple and straightforward, in the sense that if you create a VM with 2GB RAM, it consumes 2GB RAM from the physical host, and this doesn’t change, whether the guest OS is using 10% or 90% of it’s 2GB allocation. In some ways, this is preferable, as you always know what your VMs have got in terms of RAM, and even if they use their full 100%, you know you’re not going to get into a position of hypervisor swapping, so it won’t impact performance of other VMs, however, on the flip side of that, your limits are a lot more hardcoded. You won’t be able to start that 16th VM, should you already be at capacity with 15 of your 1GB VMs on a 16GB host, even though each of those 15 VMs aren’t using their full 1GB allocation. So, in summary, it’s swings and roundabouts when it comes to memory management. There was a post a while back on one of the VMware blogs, which, I accept, was based on VI3, not vSphere, but still highlighted that only 57% of 110 customers surveyed, used memory oversubscription techniques, and 87% of that 57% used it in production, so not everyone is using it, but still, I’d rather have it in my kitbag, than not, but that’s just me.
For the purpose of this cost-per-app discussion however, we’re not going to talk about how many people do, or don’t use it – we’re going to focus on what the cost-per-app calculator states, and that is that you will ‘always’ achieve a 1.5:1 higher ratio (50%) of VMs to host on ESX4, than you will on Hyper-V R2.
Back to the Report…
The very next item in the report, is a graph, which you can view for yourself when you enter your figures, however what I find funny is the heading for the graph: “VMware vSphere 4 can deliver a much lower cost per application than Microsoft's virtualization offerings” I’ve bolded out much lower there, but reality is, in the very next table:
Let’s take a look at this for a second. I’ve highlighted that versus Enterprise Plus, the actual savings in terms of cost-per-app is only 3%. Bit different than 20-30%, but hey, it’s still a saving, right? Let’s look at the numbers a bit deeper though. Why do we need 105 VMs, and they need 102? Well, we said we’d be virtualising 100 VMs, plus the Management technologies and associated database server. So, with that in mind, we’d need a SQL Box, (as would they), and VMs for System Center Virtual Machine Manager 2008 R2, Operations Manager 2007 R2, Configuration Manager 2007 R2, and Data Protection Manager R2. Fair enough, I'll give them that. 105 to 102 isn’t the end of the world anyway. However, where it starts to get interesting is the fact that due, predominantly, to the fact that memory oversubscription is being used, we can only get 12 VMs on a 32GB host, as oppose to 18 (50% higher) on the vSphere side. This means that we would in fact need 9 hosts, instead of 6, and thus every cost that’s associated with a host, which we’ll discuss in a minute, get’s added on 3 times too. We now have 3 more hosts’ worth of infrastructure costs, 3 more hosts’ worth of software costs (Windows licenses, Management licenses etc), thus our total costs are higher, thus our cost-per-app is higher, by 3%. Its important to note that no further information about the ‘VM’ is provided, in terms of CPU, I/O, RAM and so on, so, we’ll just have to work with what we’ve got, apples for apples.
Let’s just take a step back for a minute. If you had done an accurate capacity plan, and decided to buy some new servers to host these VMs, how many Partners are realistically going to think ‘right, on VMware we’ll need 6 x 32GB RAM Servers, and on MS we’ll need 9 x 32GB Servers, so I’ll go and buy 9 x 32GB RAM Servers’. Why would you not just double the RAM, and potentially, half the number of servers you’d need on the Hyper-V side? Simplistically, if 32GB hosts 12 VMs, would 64GB not host 24? 105 / 24 = 4.375 hosts, which, at a push could be 4 hosts, but, we’ll say 5 for headroom. 4 less hosts than before reduces our figures around infrastructure costs quite considerably, along with reduced software costs, and thus, a lower cost-per-app.
The (very) simplistic way to look at this is, whilst vSphere Cost > RAM Cost (and you’ve got room in the server to increase the RAM), cost-per-app will be less on a Hyper-V platform.
You could say, well, what if they are older machines, that don’t have so many RAM slots – if we max out the box in terms of RAM, vSphere is going to have a higher density than Hyper-V. There is only one answer to that, and it is yes, that’s true. However, a large proportion of customers, when they embrace virtualisation, are pretty much coming from a very physical environment, and want to invest in newer, more powerful and scalable hardware to run these virtual infrastructures. Working with a Partner, to accurately capacity plan their estate, and thus translating this into the levels of kit they need can be a straightforward exercise, yet choosing the kit to map to this will need to factor in budget, but also things like slots for RAM. a 32 RAM-Slot server is cheaper to upgrade to 128GB RAM than a 16 RAM-slot server, based on the fact you can buy 32 x 4GB DIMMs cheaper than 16 x 8GB DIMMs, but the 8GB DIMMs will decrease in cost as we move forward. These are just a few of the important considerations to make, but still, if you had an older server, with 16 slots for RAM (fairly common) which were all filled with 1GB DIMMs – you could take those out, and replace them with 4GB DIMMs, to get to 64GB RAM, for a few thousand dollars, giving that server a new lease of life, and at the same time, maximising your investment in kit. This obviously assumes that the piece of kit is supported, but also has enough I/O capacity, and CPU grunt, to handle VMs!
As always, I digress! Point is, if memory oversubscription is a blocker to Hyper-V, for a much lower cost than vSphere, you could increase the RAM significantly, as we’ll explore in more detail now.
Breaking down the Infrastructure Costs.
Firstly, what makes up the infrastructure costs? Well, if you scroll to the bottom of your results page, and expand Appendix A and B, you’ll find all the info there, but let’s take a deeper look. Infrastructure costs are made up of Servers/Hardware, but also Power/Cooling etc. I’m going to put a bit more of a real-life spin on this, but at the same time, I’m going to use a number of VMware’s Calculator Information for Power/Cooling and Datacenter Costs etc. Bear with me on this one, it will make sense!
Hardware
For this discussion, I’m going to head on over to http://www.Dell.com. The reason I chose Dell.com, is, because, like the VMware cost-per-app calculator, you can head on over there, for yourself, and try it out. The use of Dell hardware has nothing to do with it’s performance, scalability, or cost. It’s purely down to being able to quickly customise a server, and get a price for doing so!
Based on VMware’s Server Profile Assumptions, our chosen server will be:
Dell PowerEdge R805
2x Six Core AMD Opteron 2427,2.2GHz, 6x512K Cache, HT3
32GB (16x2GB), 800MHz, Dual Ranked
No Operating System
4x Broadcom® NetXtreme II 5708 1GbE Onboard NICs with TOE
LOM NICs are TOE, iSCSI Ready (R905/805)
4x Intel PRO 1000PT 1GbE Dual Port NIC, PCIe-4
Total NICs = 12
3Yr Basic Hardware Warranty Repair: 5x10 HW-Only, 5x10 NBD Onsite
FYI – based on the rule of thumb for Hyper-V R2, of 1 physical core to 8 vCPUs, we would support 96 VMs with 1 vCPU on a Dual Six-Core Server, or 48 2-vCPU VMs.
Total Server Cost: $3,664
What about Storage? Well, this is the same for both parties, so we’re not going to go into the nitty-gritty about this. If you look at Appendix A on the cost-per-app calculator, on both sides of the fence, the total comes in at $30,000, and takes into account the number of GB we’d need, and an assumed cost of $3 per GB.
Total Storage Cost: $30,000
What about Networking? Well, we’ll stick with the VMware pricing of $4,000 per network switch, and a network switch has 24 ports.
Total Networking Cost: $4,000 per switch
What about Power & Cooling costs? Well, actual operating power is 424 Watts Per Server, according to the calculator, and 530 Watts per Server for cooling, but to keep things simple, I’m going to use the figure of $833 per server in terms of power/cooling costs per year. This is based on the power/cooling costs of VMware’s 6 hosts, coming in at $5000. $5000 / 6 = $833 per host.
Total Power/Cooling Cost: $833 per Host
What about Datacenter space? Well, these are identical for both parties, as they assume that all servers (2U)[...]
