Information and announcements from Program Managers, Product Managers, Developers and Testers in the Microsoft Virtualization team.
Hi, my name is Chris Steffen, architect with Kroll Factual Data. You may have read one of my prior guest posts.
Recently, I came across an InformationWeek Analytics Weblog that asserted a bunch of half truths and misinformation about Microsoft’s Hyper-V virtualization solution. Usually, I can just let it go (everyone’s entitled to their own opinion, right?), but in this case, the article was so skewed and so misleading that I felt that I needed to respond.Full disclosure – I am a Microsoft MVP for virtualization and a very happy Microsoft Hyper-V customer. Over the years, I have written about and presented many times on the topic of virtualization in general (including Hyper-V, ESX and Xen), and the benefits my company has experienced implementing the of the Microsoft virtualization solution. I certainly recognize my particular biases, but my biases originate from the ability of Microsoft’s virtualization solutions working in my enterprise environment. In my position as a technology architect, I try to stay on top of all of the latest advances in technologies that could benefit our business. As my company is heavily invested in virtualization, I am keenly aware of the constantly changing virtualization platforms and their continued claims of superiority over each other. But some of these arguments from VMWare are just getting old. I will try to separate some of the “myths” from the reality of the debate.1. Breadth of OS supportMyth: Hyper-V has no support / limited support for Linux.Reality: Microsoft supports more than just the Windows server platforms, including versions of Linux from Red Hat and Novell. VMWare claims to support 4x more OSes that Hyper-V, but what does that really mean? When Microsoft lists an OS as supported, they COMPLETELY support the actual OS installation in the VM and you can call Microsoft support on that OS. Microsoft has support agreements with Red Hat and Novell specifically for this purpose. VMware provides no support for the actual OS, telling customer to refer to the vendor. Also, many of the OSes that VMWare claims to support are only supported by the Linux community - not taking a shot at the Linux community here, but most do not have a formal support organization. This leads me to question why they would be used in an enterprise environment. Also, those Linux distributions can be run under Hyper-V, using the Linux Integration Components Microsoft has available for download and the drivers which are in the 2.6.32 Linux kernel release. In this case, customers wouldn’t be able to call Microsoft for support for the OS, but would work with the Linux community, just as they would with VMware.2. Memory managementMyth: VMWare allows for memory over subscription and this is a good thing.Reality: The Microsoft solution does not allow for over subscription of critical resources, but you shouldn’t do it anyway.First, there is nothing poor about the way that Hyper-V manages memory – it works exactly as designed. It was designed with system performance and stability as the paramount priorities, whereas the VMWare solution appears to have been designed to allow a customer to cram as many instances on to the VM host as possible, regardless of the consequences.The core of the VMWare argument is that you can somehow get “something for nothing” – that there is some kind of magic that comes with the over subscription of RAM using VMWare that is the silver bullet regarding memory management. To leverage memory management in ESX to the fullest, one would have to fully burden the host beyond the physical memory. If you don’t, you really aren’t using memory overcommit. If you do, one of the most risky uses is the disaster recovery scenario. Relying on a host to overcommit memory to support failover hosts is potentially dangerous and incorrect oversubscription leads to all VMs suffering from performance. I would also contend that there are some instances where a company might choose to use over subscription for noncritical environments, such as a test or a dev lab. But I would not classify disaster recovery as one of those environments, and I would never over commit my VM hosts in production.3. SecurityMyth: The design of Hyper-V makes it somehow unsecure.Reality: Hyper-V is more stable than and at least as secure as VMWare.One of the oldest arguments in the book – one that VMWare evangelists continually bring up – is the scare tactic that there are millions of hackers trying to hack the latest version of any Windows operating systems, therefore, VMWare (or any other operating system or application) is more secure than any offering by Microsoft. While it may be true that there are versions of Windows everywhere, it is also true that no other commercially available operating systems or applications are more forthcoming about their flaws and their efforts to fix them. As far as install footprint is concerned, the total size for ESX systems after all the patches have been downloaded and applied was 45 times greater (4.0GB compared to 73 MB) than the size of the patches for a Windows Server Core system during an 18 month period. Further, if the actual number of patches is more relevant to you (as it is to me), ESX 3.5 had 168 total patches, compared to 19 for Windows Server Core (34 if you are using the complete install of Windows Server). Either way – which is more stable?4. Live MigrationMyth: Hyper-V does not have a live migration feature.Reality: Live migration of virtual machines was released with Hyper-V R2One of the largest pieces of misinformation that continues to pass around the virtualization circles is that Microsoft does not have a live migration feature. Literally, at a recent VMWorld event, I stopped counting at 200 different folks who believed (or were told by someone) that this was the case. To be absolutely clear:Microsoft Hyper-V R2 has a live migration feature!Most of the folks from VMWare have come to accept this, so now they are touting that their LM solution is better because you can migrate multiple VMs simultaneously. While it is true that the VMWare solution can migrate multiple VMs at the same time, is this actually better?Let’s go back to Basic Computer Architecture 101, and the example of the water pipe. There are limits to how much water you can push through a pipe at any given time, and the more taps that you add to the pipe, the longer it will take to fill up a bucket at each of the pipes. Hyper-V uses the best practice of moving a single VM as quickly as possible, using the entire bandwidth available to complete the transfer. Also, it is important to point out that without a modification of the host setting, VMWare would limit the migration to 4 VMs at a time (presumably for the same bandwidth considerations). The idea of moving 40 VMs all at the same time (as mentioned in the article) is not something that would be recommended, ever, regardless of platform.5. VM Priority RestartsMyth: Hyper-V does not start VMs and VM Hosts in specific order.Reality: Hyper-V can be configured to restart with specific delay and specific order.Some analysts are quick to point out the major differences between the virtualization solutions. This is hardly on that I would call a major difference, but this is something that Hyper-V does not have an automatic, automated solution for. That said, in practical use, Hyper-V VMs can be configured to restart on specific hosts, with specific delays allowing for prioritization (and even non-automatic restarts, for less important VMs). Also keep in mind that using the System Center suite, the Microsoft solution can Live Migrate VMs to other hosts due to situations that VMware servers cannot even monitor, such as CPU Power, Power Supply Failures, and Fibre Channel congestion.6. Fault Tolerance.Myth: vSphere is THE solution for high availability systems. Reality: Read the label…
Again, this sounded a little too good to be true. First, vSphere is limited to a very small subset of the CPUs available, therefore limiting the different kind of hosts that are able to use this technology. Then, there are limits to the kind of virtual machines that can be created in vSphere to use this technology (uniprocessor VMs, limited thin disks). Then, you would need to create a second complete infrastructure for the fault tolerant environment.There are certainly applications that you might consider putting into this kind of fault tolerant environment (Exchange and SQL Server come to mind). But you would never want these as network limited, processor starved virtual machines.7. Hot-AddsMyth: VMWare has Hot Add capabilities.Reality: Hyper-V does have some hot-add support, and the VMWare solution has some limits as well.While VMware vSphere has hot-add, it is not that ANY VM can perform Hot-Add. While you can perform a Hot Add to the VM, it is only actually useful if the Guest OS supports Hot Add to recognize the new hardware. If not, you would need to reboot the VM see the Hot Add devices, which is almost the same as simply shutting down the VM and adding it cold. Many do not, especially with Hot Add CPU and Hot Add Memory. Also, Hyper-V does support Hot-Add disk in supported VMs.8. Third Party Vendor SupportMyth: Hyper-V lags behind VMWare for third party tools support.Reality: Hyper-V gains third party support every day.Which solution offers the greater support? Obviously, this is a very subjective matter. In this particular instance, there are many third party tools out there that support the VMWare solution. But those same third party companies are jumping onto the Hyper-V bandwagon every day. While VMWare may lead in quantity, it has been my personal experience that the support for the Hyper-V solution is world class, and one of the top priorities for Microsoft.9. Maturity.Myth: VMWare is more "mature" than Hyper-V.Reality: vSphere is just as new as Hyper-V, and Hyper-V is very much ready for prime time.There is really no evidence that Hyper-V is any less mature than vSphere. Regardless of the virtualization solution, an enterprise IT department will need to properly evaluate both solutions. When they do, they will find that this "maturity" issue is really a bunch of bunk, and that the solutions should be judged on their merits. Literally hundreds of companies (including mine) have embraced the Microsoft virtualization solution for our enterprise environments. No amount of disinformation from will change the fact that Hyper-V works, works well, and is a top tier (if not the top tier) virtualization solution for enterprise class environments.10. CostsMyth: Hyper-V is cheaper, but a lesser product.Reality: Hyper-V IS cheaper, and is a stable, cost effective, robust and competitive virtualization solution.Sometimes, it does come down to cost. The folks at VMWare would like you to think that you get additional bang for your buck by selecting the VMWare virtualization solution. But that is just not the case. As we have discussed with the previous 9 points, the Microsoft solution matches up with VMWare point for point. And the differences that exist between the two solutions are often a matter of interpretation of subjective analysis, not concrete facts. But despite any facts or points that you may or may not believe, even the folks at VMWare will admit (grudgingly) that the Microsoft virtualization solution and management systems cost less than the comparable VMWare solution.
Overall, it has always been one of my goals for companies to look at the benefits that a virtualization solution would bring to their enterprise environments, and there are many good solutions to choose from. I have no particular animus towards VMWare or any of the other virtualization vendors out there – quite the opposite, in fact. I believe that the competition between Microsoft, VMWare and the others makes a better end product for everyone. But I also do not believe that it makes sense to discount the abilities of any one of these vendors over the other.As I have stated in numerous blogs previously, the best way to evaluate a virtualization solution is to get it into your environment and take it for a spin. Give Hyper-V a chance, and I think you will find that it can be a great choice for your enterprise virtualization needs.
I'm totally agree with you in all items. As Windows system engineer, now, Microsoft makes one product rely too much another product. On new production, it is very hard to find the knowledge. For example, add new host to SCVMM, we have to know WinRM, Windows Firewall and etc. But, on other production, they do only one product at a time and it is simple. For instance, if we install VMWare ESXi and use IE browser to host. We can download client and use the client to manage host. I'm afraid to say I' bored when reading say there beloved production is better than another but to me, I'm tired with this behavior of Microsoft.
You are making some assumptions that should be better investigated first. For example memory over commit on VMware. Have a look here:
More on good and bad memory overcomit: http://www.gabesvirtualworld.com/?p=930
Chris, on this CIO magazine article you said Live Migration is a very bad idea. Not that MS has it, you changed your mind. Can you explain us why ? Let's remember what you said about Live Migration:
"...I can't imagine why I'd want to do that in a production environment.."
"Hot-provisioning is a cool gimmick..."
"... it's not going to be in any production environment I'm responsible for"
Looks that you were very, very resistant to the VMotion idea. Now you suddenly changed your mind.
Maybe next year you will be telling why Hyper-V memory overcommitment is so good ???
Sorry dude, your credibility is in the ground by now.
Chris, how can you comment these plans to migrate Kroll's 500 file servers to VMware ESXi?
Chris, I disagree strongly with your views on Hyper-V Memory Management and fault tolerance.
You say that the memory management is designed for maximum performance - However in a 2-server fail-over environment, you will have to keep half the memory of each host free, in case the other one fails over. How is this maximum performance? Imagine I have one 32GB box and the most I can load it up is around 12GB, because in the rare case that the other box needs to be taken offline, I'll need that memory free.
I don't mind that performance is degraded because ram is oversubscribed in the rare case that one box goes down.. It's going to be back up again in less than a day because of my servicing contracts anyway. Our staff are not going to walk off the job because the servers run slow for 6hrs.
For the record, we are a Hyper-V shop.
Noah, your post lacks logic. You say you don't get how not overmotting memory is better for performance but then go on to say that you don't mind performance being degraded because memory is overcommitted. Obviously, you must understand that overcommitting the memory is a performance problem if you are willing to accept the degradadtion? Furthermore in your example you are assuming that you can just overload one box's memory (sounds like you are looking for doubling up even) in afailure situation and have everything just work. If your VMs aren't really using the memory alloted to them that might work, but if they have loads that are actually using their memory then you may not just have degradation, you may not work period. Memory overcommit is really only good for collections of VMs that have sporadic memory use. If you have a bunch of one tasker systems that each only need memory at short intervals, then fine, but real application workloads rarely fit this model.
I personally disagree with your failover design from the get go. Froma resource perspective it is much smarter to design your failover as an N+ model. If you have enough workload to need two hosts, buy three and have the third available as the failover for either of the two primaries.
Setting the record straight is only fair, but adding fuel to the fire is not helping anyone. Neither Microsoft or VMware are trustworthy critics of their own product compare with competing products, they are incapable of such.
Both products are great, depending entirely on the specific problem we customers are trying to solve. All hypervisors have the basic features and differentiate on features that we say we love to have, but seldom use.
There is no doubt that the only truly right product only can be determined by having a business case and see what product fits best (and remember to reevaluate).
In the end a product is either chosen based on a set of business needs or a "religious" belief.
Thanks for the setting the records straight, adding some fuzziness to the answers and keeping the same level as InformationWeeks article.
Strongly recommend to read David Davis' White Paper published at http://www.5nine.com/p2v-migration.aspx (Hyper-V or VMware?).
Hyper-V is getting mature, and we will see major ENT and SMB deployments this year and thereafter.
It is a complex subject - as many factors are involved: Capacity and Migration Planning, Consolidation ratios, licensing costs, performance of V-Environment after P2V, Management Tools and supported Guest OSs.
There are emerging tools that help you to make a right decision for your Data Center ( take a look at www.5nine.com ). Secondly - main thing is that most of the common Guest OSs are indeed supported by Microsoft ( and more to come ); and - using objective analysis shows that for SMB - ROI ratios are always better for Microsoft solution. For Enterprise - with various licensing aspects - MS solution should prevail, especially if you use 'Avarege memory utilization' method for your Migration planning.
VMware technology is great, while I believe many SysAdmins will use mainly Hyper-V for SMB, and also for Enterprise once various easy-to-use Virtualization Management solutions for Hyper-V become available.
You are a MVP. It is one of the condition to become a MVP is to represent Microsoft @all time. Lets someone do it and I will copy the idea. Bing and Hyper-V are just two of them. vSphere will leave Hyper-v far far behind when Microsoft Hyper-v catch up to current ESX4.0 and VC4.0 level. Microsoft is just trying to get a Market share of virtualization. That’s all about it. By the way, I am a MCSE, MCSA and CCNA but not biased.
I guess this one is true
We have to make this possible
I've built VMWARE environments and Hyper-V invironments and I can say three things that should be mentioned here.
1. VMWare and Hyper-V both have Live migration, but the way they do it is very different. When running side by side tests I lost connectivity for 10 seconds in VMWARE when migrating VM's from Host to Host and 90 seconds in Hyper-V (this was actually better than expected.
2. Setting up HA in Hyper-V was considerably more complicated than in VMWare.
3. The management console for VMware seemed much more user friendly to me and had various additional features that I found useful. Even SCVMM falls far short of Vsphere.
You would expect to hear these things from an UNIX guy, but I'm a Microsoft Baby. Hyper-V should have been easier for me than VMWare, but unfortunately it wasn't.
I guess you're not suppose to mention these types of comparisons, but I would think you would have more credibility if you did. It's OK to say we are not as good in these ares's today, but we are aware of that and working on it.
I read this with interest because we are always looking to improve our IT offering and Hyper-V is certainly worth keeping a watch on.
However I was doubly dissapointed as not only is much of what this piece claims flat out incorrect but it also does not address the original article so much as what the writer wished the artciel HAD said.
For example when addressing point 4 the writer has a big to do about how the original piece claims that Hyper-V can't do live migration. Whereas, in reality, the original piece acknowledges the addition of live migration and actually focuses on the limitations of the MS version.
So the writer here is deliberately misrepresenting the artivcle he is responding to - which by my standards is dirty pool and reveals a lot about the nature of the writer.
I agree with Suraklin. So many of these points failed to address the actual issue raised by the original article, instead focusing on why the missing feature wasnt really that useful anyways (2, 4, 7-- especially conflating OS limitations and hypervisor limitations in 7), or why its acceptable to install an unsupported OS (Debian? RedHat? Solaris?) on a hypervisor and then rely on community support, without the ability to install the integration patches.
It seems like several times Chris came close to actually acknowledging weaknesses honestly, but never really got there, instead insisting that less is more, and that anyone who wants some of these more advanced features doesnt know what theyre doing anyways.
I was most disturbed by the attempt to assert that Hyper-V has been out as long as VmWare, when the first version of HyperV came out in 2008, and ESX has been out for more than a decade. What gives? Are you going to seriously claim that vSphere is a different system than ESX, and somehow is brand new?