Hyper-V vs VMware

Another difference in SR-IOV it seems is that Hyper-V supports a whole lot more VF's than VMware. The VMware article you linked states up to 41 VFs on supported Intel NICs, and up to 64 VFs on supported Emulex NICs, where the X540 intel cards support 63 VF's per port, so on Hyper-V you could use the full 126 VFs for VMs on a X540-T2 while you'd be stuck at 41, or less than one port can provide, on VMware (pretty sure it's 63 for each port, can't check right now, can't access device manager)
 
Can you elaborate on your point about Azure site recovery? The MS documentation makes it seem like it is fairly simple to fail both to and back from the Azure cloud, so I am not sure what you mean about your VM being there to stay. I've never used it myself so I don't know if there is some hidden gotcha.
 
Can you elaborate on your point about Azure site recovery? The MS documentation makes it seem like it is fairly simple to fail both to and back from the Azure cloud, so I am not sure what you mean about your VM being there to stay. I've never used it myself so I don't know if there is some hidden gotcha.

You know, I got it from what I thought was good authority that failback wasn't possible. Now that I'm looking at documentation I'm seeing also that failback is supported.

I think I got mixed up with InMage which is Azure's product that allows VMs running VMware or physical machines to be replicated to Azure for disaster recovery. In that scenario, failback is not possible.

I also need to point out that only Generation 1 Hyper-V VMs can be replicated to Azure.

Thanks!
 
Trying like hell to get the administration section done this weekend. Got some good weird ones in there like that you can't use VMM to rename a running VM, you have to use Hyper-V or Failover Manager or how no VMware to Hyper-V VM conversion software exists that lets you convert a VM straight to a SMB3 share.
 
Wow, this is a good read. I've been dealing with virtualization, mostly VMware for the past 5-6 years now. Still manning up for the VCP 5, since I bombed on the VCP4 exam.

Can't wait for this to be finished.
 
Based what I learned at my new job over the past months here is how the two hypervisors are different in real world terms; some of our application vendors have certified their apps to run in VMware, but have not done so with HyperV.

Unless those vendors of business critical apps take the step of supporting their app in a HyperV environment it's completely irrelevant what the technical differences/merits of one hypervisor over another are.

It may be easy to say "well, fine, we will just use an app where the vendor doesn't care which virtualization stack its running on" but that's all it is, it's easy to say, operationally it's not that easy because all of a sudden you are talking about user re-education, integration with other software, integration with hardware (instruments, non-compute devices), etc. etc. etc.

I am a VMware fanboi, but from a cost perspective we would benefit from HyperV. The current HyperV feature set is sufficient for us. If our app vendors would support it I would turn the org on a dime and deploy HyperV for an annual savings of at least 120k, not counting the savings realized during future expansion.
 
Based what I learned at my new job over the past months here is how the two hypervisors are different in real world terms; some of our application vendors have certified their apps to run in VMware, but have not done so with HyperV.

Unless those vendors of business critical apps take the step of supporting their app in a HyperV environment it's completely irrelevant what the technical differences/merits of one hypervisor over another are.

It may be easy to say "well, fine, we will just use an app where the vendor doesn't care which virtualization stack its running on" but that's all it is, it's easy to say, operationally it's not that easy because all of a sudden you are talking about user re-education, integration with other software, integration with hardware (instruments, non-compute devices), etc. etc. etc.

I am a VMware fanboi, but from a cost perspective we would benefit from HyperV. The current HyperV feature set is sufficient for us. If our app vendors would support it I would turn the org on a dime and deploy HyperV for an annual savings of at least 120k, not counting the savings realized during future expansion.

Excellent point. When I get to the cost section one of the things I plan on mentioning is that even if an organization decides they want to run Hyper-V in production, it often makes sense to run BOTH VMware and Hyper-V with application supportability being one of the reasons.
 
I plan on mentioning is that even if an organization decides they want to run Hyper-V in production, it often makes sense to run BOTH VMware and Hyper-V with application supportability being one of the reasons.

It's probably very situational whether it makes sense to run both environments. We would save on VMware maintenance fees if we were to go partial Hyper-V but we don't have any people who can operate Hyper-V.

Sure, training can be done, but it goes back to having a unified environment both on the hardware and the software side. Despite the maintenance savings, diversifying the hypervisor environment spreads human resources too thin.
 
It's probably very situational whether it makes sense to run both environments. We would save on VMware maintenance fees if we were to go partial Hyper-V but we don't have any people who can operate Hyper-V.

Sure, training can be done, but it goes back to having a unified environment both on the hardware and the software side. Despite the maintenance savings, diversifying the hypervisor environment spreads human resources too thin.

The biggest reason I see for running a heterogeneous environment is to ease the transition from one hypervisor to the other. If a VMware client wanted me to guide them to an all Hyper-V infrastructure I'd tell them it will be a 1-2 year process that would look like the following:

Stage 1 - setup Hyper-V on test servers, train staff, use Hyper-V test servers to learn
Stage 2 - once comfortable with Hyper-V make plans to build a new test/dev Hyper-V cluster or replace existing test/dev VMware cluster with Hyper-V
Stage 3 - create new Hyper-V production cluster(s) and begin provisioning all new VMs there
Stage 4 - begin migration of VMware workloads to Hyper-V

Stages 3 and 4 could take a very long time to complete which means you're running both hypervisors for an extended period of time. I would never suggest a rip and replace approach.

Another plus for running heterogeneous is that both products are known to release patches and upgrades that break things. Wouldn't it be nice to have the other product alive and well if needed?
 
The biggest reason I see for running a heterogeneous environment is to ease the transition from one hypervisor to the other. If a VMware client wanted me to guide them to an all Hyper-V infrastructure I'd tell them it will be a 1-2 year process that would look like the following:

Stage 1 - setup Hyper-V on test servers, train staff, use Hyper-V test servers to learn
Stage 2 - once comfortable with Hyper-V make plans to build a new test/dev Hyper-V cluster or replace existing test/dev VMware cluster with Hyper-V
Stage 3 - create new Hyper-V production cluster(s) and begin provisioning all new VMs there
Stage 4 - begin migration of VMware workloads to Hyper-V

Stages 3 and 4 could take a very long time to complete which means you're running both hypervisors for an extended period of time. I would never suggest a rip and replace approach.

Another plus for running heterogeneous is that both products are known to release patches and upgrades that break things. Wouldn't it be nice to have the other product alive and well if needed?

We are in the middle of this but will most likely running both in parallel. The Linux team for some reason doesn't want to give up VMware :p/
 
I've used both products extensively over the years. I like Hyper-V at home because I run mostly Windows guests, and the elastic (dynamic) memory is cool because I'm able to run more simultaneous guests than the same piece of bare metal running ESXi 5.5.

There's a pretty drastic difference in the two products when job hunting, however. VMware is the gold standard, every company seems to be looking for VMware certs, and VCP5 or better seems to be the pinnacle of IT job security, even more so than the way MCSE was often considered the cert-to-have in the early and mid-2000's. You rarely see a company calling for Hyper-V proficiency or cert.

Still I think the competition is good, and I'm curious to see if the next iteration of Hyper-V makes another leap forward in their catch-up race with VMware. I'd like to see MS continuing to leverage the ability to create efficiencies between the hypervisor and windows guests because they have that access to the windows kernel team.
 
Last edited:
Back
Top