Hyper-V vs. VMware – What is Best for Your MSP?

Save to My DOJO

Hyper-V vs. VMware – What is Best for Your MSP?

Hello everyone! Today we’re talking about a subject that has garnered many an article and many a discussion over the last several years. That is the questions of whether Hyper-V or VMware is better for your MSP toolbox. Many of you may already have a winner in mind, and that’s fine, I only ask that you keep an open mind. Additionally, you should note that I write this article with the assumption that in both cases you would have technicians that are fully trained and understand each product. It wouldn’t be a fair comparison if you compared a veteran Hyper-V engineer’s deployment vs a novice VMware Admin’s deployment. So, as we talk about both technologies below, engineering know-how will enter into the discussion very little.

Without further delay let’s start by looking at features!

Features

Features have become a part of the VMware vs. Hyper-V debate that has become much more difficult to cover in the past couple of years. This isn’t because one is far better than the other in this area. It’s the opposite! Feature parity between the two is basically a wash these days. For example, both have:

Additionally, looking at what both vendors call configuration maximums (the largest amount of resource utilization/assignment the hypervisor/vms can handle) it’s apparent that each vendor’s maximum is so high, only the mega-corporations of the world risk running up to those limits as shown below.

Hyper-V Host Maximums for Example

hyper-v hosts

VMware Host Maximums

vsphere hosts

As you can see, both options scale-out to ridiculous heights, with both having the ability to serve up just about any virtualization need your customers could come across.

If you’re interested in looking further into these config maximums you can find the Hyper-V Maximums discussed here, and the vSphere ones here.

This hasn’t settled our debate, so let’s move onto the next section Manageability

Manageability

The manageability story for this comparison is a bit murkier than the features section above. Each vendor has a different management story and a slightly different way of doing things. If I had to break it down as quickly as possible with a short answer, I would say this:

With a fully trained team, management of either product is effective for MSPs. However, vSphere is more forgiving for junior engineers and those that may not be familiar with virtualization. I say this with Hyper-V being my hypervisor of choice and due to the following:

In vSphere, you have a single pane of glass tool for managing the entire solution; the vSphere Client. You connect to the vSphere client on a stand-alone host or a vCenter instance and the management experience is largely the same. With Hyper-V, you will use one of several possible tools, including:

  • Hyper-V Manager
  • System Center Virtual Machine Manager
  • PowerShell
  • 3rd Party Management Tool
  • Azure Front-End (If using Azure Stack)

While these different tools are highly effective, they are all used in different deployment types, and different scales, and it can lead to confusion and frustration for new IT Pros. That difference aside, both of these products are well suited for MSP management. Both have integrations with MSP RMM and reporting platforms, and both can be used in automation scenarios via PowerShell and PowerCLI.

Likely the determining factor here is going to be what your engineering team is comfortable with. If you’re automating as many functions as you can (and you should be) the numerous management tools for Hyper-V is likely a non-issue. So, from an MSP perspective comparing these two tools, we’re still at an even stretch after this section.

Let’s talk about pricing and cost next.

Pricing and Cost

It’s this stage of the discussion where I start to lean towards Hyper-V. From a pure engineering perspective (no talk of sales or margins involved) Hyper-V wins this section hands-down. And I would argue it’s due to one simple fact. With Windows Server licensing you are given virtualization rights to run 2 VMs with a standard edition and the ability to run unlimited VMs with datacenter edition on a licensed piece of hardware. This is regardless of the hypervisor type. This requirement is the same whether you’re running Hyper-V or vSphere, and this is where the determining factor comes from.

The vast majority of your customers are going be running Windows Server. That’s just a fact. If you want to run Windows Server on top of vSphere you still have to buy those Windows Server licenses, and guess what? That Windows Server license comes with Hyper-V and all you need to run a small to a mid-sized cluster already. So, it comes down to a simple question. Why would you pay for the extra licensing for vSphere when you already get what you need for most use-cases with the purchase of Windows Server licenses that you must buy anyway?

For a standard business (Engineering know-how aside) the answer is simple. For an MSP, a little less so. For the aspiring MSP the decision to choose vSphere over Hyper-V comes down to three extra factors. 1 of which I personally don’t like.

  1. Adding in vSphere to the deal adds extra profit margin for the MSP
  2. vSphere is already the defined virtualization solution in the MSPs toolbox.
  3. Chosen Hybrid Cloud Option.

I will concede that all MSPs have a mandate to make money. That’s how the business continues to grow and function and everyone needs to put food on the table at the end of the day. I do, however, have an issue with selling a product (in this case vSphere) for the sole purpose of adding to my profit margin. If that’s the ONLY reason I’m choosing vSphere as an MSP, my customers should look elsewhere because it increases the cost on them for the sole goal of lining my own pocket. You’d be surprised how many times I’ve seen this.

If this describes you, I would argue that when it comes to cost specifically (all other factors aside) doing a given project with Hyper-V will allow you to come in at a lower price point. Sure not as much margin, but long-term customer trust goes a long way.

As for item 2 on the list above, it’s never too late to change your toolset. If this is the sole resistance to changing your core virtualization choice, then I would suggest putting together a proof of concept and going from there.

Item 3 is fairly simple as well. It’s no secret that Hyper-V has native integrations with Azure, and that VMware is closely aligned with AWS. If you have an affinity for one of those public clouds over the other, that may well influence your decision as well.

NOTE: Looking for info on pricing cloud services?

Is Hyper-V or VMware Better for MSPs?

So, we’ve looked at a few different things as part of this discussion, and I’ve found in my travels that these are the three most important areas for MSPs. Ready for the winner?

My answer to which one is better? Surprise! It comes down to which one fits in your company culture better. Are you a historically Microsoft-centric shop and want to use Azure? Then go with Hyper-V? Are you a fan of AWS? Then you likely want to go with VMware. Are you looking for on-prem only and want the lowest cost for your customers? Choose Hyper-V. But please, for the sake of your customers, don’t be the MSP that chooses VMware just to get a little extra margin.

Whatever choice you make, train up your engineers and integrate it into your MSP stack and your chosen solution will serve you well. Both are fantastic and mature products with large companies behind them ready to help if needed.

What do you think? Agree with my assessment? Don’t agree with it? Let me know in the comments section below!

Looking forward to your discussion!

Get a 30-day trial of Altaro VM Backup for MSPs

Manage all your customer VM backups from a single cloud console, on a monthly subscription. Try Altaro VM Backup for MSPs for 30 days - no strings attached!

Share this post

Not a DOJO Member yet?

Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!

Leave a comment

Your email address will not be published. Required fields are marked *