Vmware Vsphere and Microsoft's Hyper-V

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Now THIS is how to 'do' a forum debate

I'm not entrenched and 'anti'-MS over this. I just see them playing catch-up with VMWare for a good few years before they'll have a product that cometes realistically in this space. I know what you're saying about feature-lists - and it's true that MS have got closer with their list of things that are required for virtualisation to be truly enterprise-class. However, the offerings are, at the moment, worthless in comparison with VMWare's.

The one area I will argue that MS is ahead of VMWare is in the area of application performance monitoring, This is only to be expected - since VMWare uses a 'black box' approach to VMs and doesn't care or know about the apps running inside each VM, it only stands to reason that Microsoft (providing the underlying OS on those VMs) is in a better position to be able to balance apps across VMs.

Shin - we could get right into the debate if you'd care to put up MS' offerings over VMWare's in the following categories:

Memory Overcommit - allowing you to overcommit RAM in a production environment to maximise the amount of RAM in your cluster (VMware=TPS)
Live Migration of multiple Virtual Machines at the same time - with zero downtime (VMware=SVMotion)
Ability to move storage whilst machines are live, giving you the ability to move VM storage onto different LUNs without downtime (VMware=Vmotion)
Balancing VMs across hosts in a cluster dependent on resource usage on each host (VMWare=DRS)
The ability to migrate all VMs off a host during periods of low resource usage and shut down to conserve power and cut down on energy costs (VMWare=DPM)
The ability to automatically power VMs back up on a different host in the cluster should the host they're on fail (VMWare=HA)

This will be good (for the uninitiated, MS does have some offerings in the above categories (though only one or two at best) - but every one of them is essential for what I would consider an 'Enterprise-Ready' virtualisation solution.) And bear in mind, 'Enterprise-ready' is what I'm talking about here - not departmental virtualisation.

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

I think everyone here knows that Microsoft is taking Virtualization seroiusly. They will do what it takes to become a respected solutions provider in this field.

It's a similar case to the competition it fought (and still fights) against Citrix. Citrix was a leader in applicaton and desktop virtualization, and Microsoft now has the solutions (Med-V, App-V, etc...) to seriously compete against them in that field.

I've heard people mention Hyper-V and Enteprise Class Solution in the same sentence, but you can all make up your own mind on this based on your wants and needs.

I agree. Microsoft is able to leverage the System Center suite of products to monitor Hyper-V and the VM's to a more thorough degree than VMware. I guess you've seen that particular marketing slide ;)

As I mentioned before, Microsoft chose to not allow this as they believe it is a feature that is "safe" for test/development environments, but not for production.

Now, someone at Microsoft also mentioned that we will offer a similar feature in the future, so I wouldn't discount it entirely. Basically the deal is that many customers want this feature and they've made themselves quite clear about us having to provide it. They value the idea of possibly using twice as much memory as is needed in their Virtual server environment, but at the same time studies have shown that very few use this feature in practice.

Even on VMwares website there are some words of caution about using Memory Overcommit such as:
“Avoid high memory overcomittment. Make sure the host has more memory than the total amount of memory that will be used by ESX plus the sum of the workingset sizes that will be used by all the virtual machines.”

I'm not a developer, but I do know that it would be a nice feature to have for my personal lab. Maybe this will come in release 3 of Hyper-V?

This is now offered in Windows 2008 R2. Works virtually the same as with VMware. I've Witnessed both and there's the same split second time-out in between "migrations". Windows 2008 (non-R2) did not offer this, but did offer what is known as "Quick Migration".

As an alternative to Live Migration, Quick Migration may be preferred in situations where some applications do not play nice when the VM is being transferred between hosts (often due to cache reasons). Quick Migration takes several seconds, even minutes to transfer a VM over (it has to save the contents of the ram similar to a computer being placed in hibernation) but retains a more consistent environment for those picky applications.

I'm not an expert on this, and I believe this is not possible. Even with the release of Cluster Shared Volumes in R2 which allow multiple VM's to run on a single LUN, I believe that moving the actual VHD file around "live" is not something that works out of the box. I honestly think this is a limitation of the OS itself.

What I do know is that R2 offers the possibility to hot-add disks to VM's (select them as SCSI disks in the Hyper-V interface), and if one is running Hyper-V on a DataCenter Edition of windows 2008/R2, they can hot-add more CPU's and memory modules into the physical server as well, thus effectively increasing resources available to the VM's without ever having to move these VM's off the host, or powering down the server.

In addition, with Microsoft licensing model, by installing a DataCenter edition of Windows Server 2008/R2, Microsoft provides you with the possibility to add an indefinite (as many as you want) number of guest VM's to the server without having to purchase additional licenses (with the Standard Edition of 2008/R2, Microsoft lets you install one VM free of charge, and with the Enterprise Edition, up to 4 VM's free of charge). Granted a DataCenter edition of Windows Server is not exactly cheap to purchase, but we have seen customers running as many as 4500 VM's on a single DataCenter Hyper-V server. In terms of licensing costs, that could amount to massive savings.

This is already possible with the System Center tools. It can be fully automated.

The System Center tools can be configured to automatically move VM's across hosts based on their use (resource utilization), and R2 is able to shut down entire processors or cores automatically during periods of low CPU activity (called parking) and running VM's group together to a denser set of processors/cores.

I have not heard of capabilities that would turn an entire Hyper-V server off, but I don't see why one couldn't configure rules in System Center to move VM's off low utilization hosts and then turn the host off when unneeded. WOL could be used to bring the server back on, but I'm only speculating here.

I'm all for the green revolution and virtualization is already decreasing power usage in DataCenters around the world by a considerable amount

Hyper-V R2 also offers processor compatibility mode which makes it possible to migrate VM's between hosts with different processor architecture levels, something which was not possible with VMware some years back (the processors had to have a similar stepping level. I'm not surprised if they've fixed this in vSphere 4).

I hear you, and I respect that idea.

All I know is that there are customers using it for production environments, and they're taking it seriously. They're seeing cost savings of 1 to 3 vs VMware with Microsofts Hyper-V solution, and maybe it just works for them.

The beauty of IT is that we have a lot of people out there providing solutions, and we're all intelligent creatures that make a decision based on their wants and needs (and capabilities of their wallets ;) ).

As a final piece of informaiton, I've seen the IDC Virtualization market share numbers, and they state that in Q1 of 2009, Microsoft help 23% of the virtualization market versus VMwares 49%. If Microsoft is able to have half as a big a market share in virtualization as VMware does, then perhaps the customer base of the Microsoft virtualization solutions is not quite as small as some think. Of course as with many statistics, these numbers could be horribly skewed and there's plenty of rumors on the net regarding the validity of these percentages.

Sorry, I don't work in marketing or programming and I really can't vouch for sales or the next set of feature lists in whatever release of Hyper-V comes out nest. I just like to play with my software

 

We have just implemented Hyper V to run along side our VMware environment with a view to learning and selling Hyper V.

It was experience in all honestly I don't want to relive.

The whole consisted of "Error 1", resolve this for an hour and move on, "Error 2" resolve this for two hours and continue. The implementation from start to finish to include SCVMM was over two weeks for just two hosts.

We have since re spec'ed 3 orders to replace Hyper V with Vmware and we do not use the envirionment for production. A few reasons why are below:

1. When using Broadcom drivers and teaming software, Hyper V has major issues. After a VM restart or migration to another host, network traffic will still go to the old host (MAC addresses are not updated, see google). Microsoft clearly state third party software is not their responsibility. However for this sort of solution/product (HA/DR) this should be their responsibility and they should allow teams similiar to how VMware do it at the least.

With have two hosts (16 logical cores, 48GB RAM) capable of hosting a good number of machines all via 1 NIC!!! (Blade with 4 NIC ports, 2 for iSCSI)

2. No easy stats. Via SCVMM, if I want to deploy a new virtual machine to a host and pick the "datastore" (A "pointer" held on the C drive for shared clustering), I have no idea how much space is left or if it is even safe to deploy at that location. I would have to check them manual or I assume install SCOM.

3. Clustering monitors all of the resources to include NICS. When you install and bind a vSwitch to a NIC, it disappears from being a resource/object in the cluster. So if I lose the only NIC when is the vSwitch (No teams remember) how will I know it is down and would the cluster failover?

4. To install and configure this thing, the number of loops to jump though to get the basics working is rediculous, e.g AD Users and Computers to fix permissions just so I can use an ISO.

For single server deployments and using just the Hyper V manager it is great. Anything beyond this is not fit for purpose.

Oh and if anyone knows how to get rid of all the "clusterinvarient:4jiheio3j3ffwefw9e9fweu9u9fw9u99u" messages in the comments of over 200 VMware VM's that SCVMM got sight of, please let me know.

 

Ok then two more points and I'm done:

5. On creating a new fixed sized VHD file, you seem to have no option but let it create normally which actually zeros the area on disk/SAN. This can take 10 Mins plus on a 50GB VHD file in additional causing major a performance drop on the SAN. Create two disks at once and your whole envirionment is on its knees.

6. Deploy from template the "SAN" option is never available and it has to transfer from the network. The template is held on the host in a iSCSI disk held on the SAN. I'm deploying to the same SAN, yet I only get the option for a network transfer. It is far from rapid deployment.

 

Great debate here. I think Shini's definitely in the minority in considering Hyper-V 'enterprise ready', but he makes some interesting and valid points. Rather than turn this into a quote-fest a la BM , I thought I'd just counter his points one-by-one.

First up - no argument from me, As said before, you'd expect MS to have better understanding, visualisation and monitoring of applications running on their OS. I don't ever expect VMWare to compete in this space - so that's a definite point to MS.

Regarding memory overcommit, the MS line is that it isn't a production feature, and isn't used seriously in the enterprise viurtualisation marketplace. I have 10-15 friends who are at my level (senior sys admin/technical architect type roles) in organisations ranging from 150-10000 seats. Every one of them uses memory overcommit to show a decent ROI on their vmware environment. Nobody reading this or any other MS blurb on memory overcommit should believe anything they say on this. Memory overcommit is used in production environments everywhere. I'm sure Ryan will tell you the same for the customers he supports - not sure what level Sparky is involved in VMware in the SME marketplace but I'd imagine the penetration down there is just as great as it is in higher-seat organisations. Besides, it's wholly ridiculous for MS to say on one hand that (paraphrasing) 'nobody uses memory overcommit in production, studies show that it isn't safe b lah blah blah...' - but invest huge resources into developing it anyway for their virtualisation suite. Lulz at that.

Hyper-V's migration still doesn't compare with VMWare's. I know people who have put Hyper-V in alongside VMWare for testing purposes - all of them (without exception) found the migration process slower, and had random problems like being unable to RDP into VMs after migrating them to another host, pings dropping out for 30 seconds at a time for no reason, some migrations taking place with only 2-3 pings dropped, whilst others dropped off for over 30 seconds. That AIN'T live migration Sally! Quick Migration is a fine idea - but the amount of time it takes, you may as well power off the frickin VM and power it back up again! Also, I run over 100 different apps in my environment - including crapware developed in-house ten years ago. None of them have ever exhibited any problems during or after being vmotioned ('application sensitivity to virtualised environments is another MS myth)

Real Storage Vmotion (SVMotion) isn't possible in Hyper-V. 'Quick Storage Migration' is a sick joke when compared with the benefit of being able to move all your VMs off one LUN and onto another with ZERO downtime. Storage re-architecting used to be an absolute pain in the ass before SVMotion. It would STILL be a pain in the ass if you had to do it in Hyper-V. Way to go answering this one by chucking in a completely unrelated, random feature to do with storage (hot-adding storage - which ESX can also do anyway) though. You've only been at MS a few months and they've already indoctrinated ya!

DRS in Hyper-V is also a poor relation to VMWare's offering. SCOM is ridiculously complex compared to VMWare's implementation. DRS is configured with one click - ONE click - in the VI Client. You also need extra servers (and extra licenses) for the app and DB servers to support SCOM and (unless MS have changed this) there is no centralised method of managing resources across a custom-defined bunch of servers (Resource Pools do this in ESX and are absolutely frickin awesome at it)

For DPM you can pretty much say the same thing as DRS above. It's complex to implement in Hyper-V - and I'll wager isn't actually used anywhere - whereas more than half my buddies already use it. Our environment is slightly different to theirs (24/7 operation, most of our servers work just as hard through the night as they do during the day) but if that ever changes, or if I move on to somewhere with a more 'traditional' resource usage pattern, it's going to be wicked-cool for me to do five minutes' worth of work and save my new company £xxx in datacentre power costs

Regarding HA - you missed a trick there. You answered the post with a sly dig at VMWare without having possession of the facts - and without answering the real question. I can do that for you now. MS' offering to combat HA is 'Quick Migration' - which, as anybody who has used it will know, is anything but quick. You can configure specific isolation responses based on the failure scenarios your cluster can tolerate, which is awesome for people who like to run close to the bone (not a problem for me as I run nice and fat resource-wise). Anybody wanting to do a like-for-like comparison of VMWare HA and MS Quick Migration should check out the net. There are loads of resources (pretty much all of them coming to the same conclusions as me). As for the poke at VMWare - ESX has had the ability to create an EVC (Enhanced Vmotion Cluster) cluster for aeons. In fact, longer than MS has been 'doing' virtualisation at all. The ability to migrate VMs seamlessly between different processor architectures (which is a limitation for ALL virtualisation platforms btw, due to different instruction sets on different CPU families) was mitigated against even before it was possible to create an EVC cluster through CPU masking.

I've also seen the IDC numbers. They are deeply, deeply flawed. They don't take into account the number of customers who are using Hyper-V in direct competition with VMWare in the enterprise marketplace. Any mom and pop operation running a single Hyper-V server is counted as an "MS Hyper-V FTW!" fanboi who is grabbing the bull by the horns and spearheading the MS annihilation of VMWare in the enterprise virtualisation marketplace - when, in reality, they're doing no such thing. You may as well count all the installations of VMWare server running in data centres and server rooms across the world as 'enterprise-level'.

You've actually done an admirable job here of defending MS' offerings. Better than most of the marketing plebs I encounter at trade fairs, conventions & roadshows. Kudos for that - but, as I think I've outlined above, the numbers/arguments just don't stack up.

Best debate on here in a coon's age though - keep it going!