There's fud, and then there's FUD

I guess it was inevitable, but it's still depressing.    Traveling around the world means I read a LOT of magazines - there's that 15 minutes of airplane ascent and decent where my usual toys (PSP, iPod, DS) are verboten.   Some stuff (like the Economist) I read to expand my horizons, some stuff (like Maximum PC) I read as the nerd equivalent of Maxim (completely vacuous brain mush).

I couldn't resist the headline of this month's Windows IT Pro: "Virtualization Wars: Hyper-V vs. ESX Server ".   You can read it online here: http://windowsitpro.com/article/articleid/98879/virtualization-shootout-part-1.html

Ok - before I get started - let me make something clear:

While I'm unabashedly pro VMware, that's not EMC's official position (but is my official position as "Mr. VMware" - I admit, I'm a true believer).   VMware operates as an independent company.  EMC must also serve our customers - so we support Microsoft's Hyper-V, Xen, KVM and other Hypervisors.   Chuck covers this well in a recent post here:   Getting Ready For Hyper-V, and Xen, and.   That said, our focus and investment is focused on VMware because of what our customers tell to focus on.     BTW, I don't find anything weird, unclear or conflicted in that - when you get sufficiently big, you need to have a big tent, and it becomes productive to have different people inside EMC driving differnent agendas - and moving the whole forward.    People that think that single world-view approaches are best - well, you probably need to travel more :-)   I personally just happen to think, (and of course I think this on what I think are solid grounds) that VMware has the best story, whether you're talking straight consolidation, or the automated datacenter of the future.   

So - let's get to it....   What's my problem?  It's not that so this is fud, but that it's such BAD FUD.   I mean - this guy is either:

• phoning it in
• colossally out of his depth
• actively malicious
• being paid by Microsoft

Read the article with those four options in mind - and tell me, am I off base?  Read it before reading my opinion - build your own first, then, come back and let's discuss....

.

.

.

.

Are you back?

Ok, the mag is clearly a pro-Microsoft rag, and that's perfectly OK.   The guy has written some decent SQL Server articles (look at his other stories).   But SERIOUSLY, this is utter rubbish - and is the cover article of a magazine with a circulation of more than 100,000 monthly readers.

Ok Chad, breathe, deep breathing....    I try really, really hard not to come across (both here and in person) in the militant ways some of my EMC blog peers do (sorry guys, but that's part of your charm) - but this has me positively steamed.

What do I mean?   Well, let's deconstruct:

"In both cases, the hypervisor runs directly on the system hardware. However, with ESX Server the hardware drivers are all part of the hypervisor, which significantly increases the size of the hypervisor. In addition, the device drivers are created by the hardware vendors, which introduces third-party code into the hypervisor and limits the hardware that ESX Server supports. " 

My comment: So, out of curiosity, who writes the device drivers for Windows?   Does anyone out there actually use the drivers that Microsoft ships with the OS (if so, please please stop)?  Of course not.  "Third party drivers" isn't something to be afraid of, it's par for the course.  Thank goodness the hardware vendors write their own drivers.   In fact, that's why Microsoft instituted their WHQL and "signed driver" programs - because kernel-mode drivers are dangerous if not high-quality.   Now, what "third party" drivers does an ESX have running at the VMkernel layer?   Network, core logic and chipset drivers, storage adapters.   These are very robust, and in fact this simple, lean model is one of the reasons ESX is so reliable (great link on that here: http://redmondmag.com/features/article.asp?editorialsid=2400 - look at that source too....) .   

Ok, what about the "limits the hardware that ESX server supports"?   Well, I guess there's kind of a point there - except that there isn't (which is the essence of FUD - if you don't know better, it kinda makes sense).   Every customer I know runs production hardware that's on Microsoft's logo program (and on the WHQL if they are clustered - unless it's iSCSI of course).   Those are the same servers from Dell, IBM, HP, FSC and others that are on the VMware HCL.   The VMware HCL is like Logo certification.   If you want to run "non-official" hardware for doinking around purposes - go to town.  I have yet to build a home-grown system that didn't just work - and you can see that I have some experience (Building a Home VMware Infrastructure Lab).   Later in the article, the author even goes on to point out the "home-grown" Hyper-V issue - Intel VT or AMD x64 are required - which isn't true of ESX - which can run on old CPUs with 32-bit VM support only (but of course, to the author in that case "limiting hardware support" isn't a big deal when it's Hyper-V).

"In contrast, Hyper-V uses a microkernel hypervisor in which the hypervisor contains the minimal amount of code required to schedule and share hardware resources between the active VMs. The Hyper-V hypervisor has no device drivers and no third-party code, which ensures the best possible performance and reduces security exposure."

My comment: minimal amount of code?!?!  The ESX pure hypervisor is under 32MB (and shipping).  Hyper-V's minimal install using Windows Server 2008 Core and RC1 bits is just under 4GB!    That's 2 orders of magnitude "more code"!.   This guy does a really good job (and frankly a good job of summarizing a lot of Hyper-V details here: http://blogs.msdn.com/virtual_pc_guy/archive/2008/02/25/hyper-v-terminology.aspx) OK - so, of course - Microsoft has stated that they will ship a version without Windows Server Core.   Question - can someone... ANYONE... explain to me how that will work?   Consider the dependencies - for Quick Migration - there is a complete dependency on Microsoft Cluster services (which of course runs in the parent partition - totally borking the hypervisor model).  What about the dependency on the parent partition for a lot of core management functions?   How exactly would an install work?   Oh, and then of course - there's the small issue with... Microsoft comparing NOT AVAILABLE features/functions against a shipping product.   Are we comparing Hyper-V to ESX, or V-Next (or whatever) to ESX?

"Both products are managed from the first VM partition. In ESX Server this VM partition, typically called the service console, is based on the Linux shell and is managed via the command line. However, you can download an easier-to-use Windows-based management client, called the Virtual Infrastructure Client, from ESX Server’s Web console."

My comment: most customer will either use Remote CLI (they should), or the full VI client.   What's interesting is that he mentions the VI client, but then goes on later to describe it as if it doesn't exist....

"Hyper-V is also managed using the VM running in the first partition. In Hyper-V this partition is called the parent partition. In addition to VM management, the parent partition is also used to run VMs with legacy OSs such as Windows NT and Windows 2000 that can’t utilize Hyper-V’s new VMBus architecture and must use the older emulated hardware model."

My comment: Wrong on VMware (i.e. incorrect use of the word "also" - should have been "can be managed from the service console"), RIGHT on Hyper-V.   Customers manage ESX without the Service Console and instead with the Remote CLI and with the VI client (and I'm finding more and more using the installable version of ESXi for security reasons - even with hardware platforms that don't have ESXi on the hardware itself).   In the authors own words (and he's correct here) the parent partition is mandatory for everything with Hyper-V.  The same is NOT true of ESX - there is no dependency on the service console.   Let's all look each other in the proverbial eyes here and be intellectually honest.   Microsoft has chosen to bundle Hyper-V with Windows for a couple reasons.   Some are technical - for example the MSCS dependency I pointed out earlier.  The other reasons aren't technical, and I don't even think they are conspiratorial (I know many good friends at Microsoft - and they are smart, smart cookies).   It comes down to the fact that they fundamentally think that the idea of a "parent partition" (which actually is intrinsically linked with a lot of key architectural decisions) is a GOOD idea.  That's an OS centric model, as you would expect from a company built on Windows and Office.    Most customers I talk to don't agree (even those who buy the "Hyper-V is cheaper" argument) - and they want a hypervisor to have nothing to do with a traditional OS, simply to be a platform.   I guess the market will decide here - but here's a litmus test.   If V-Next is bundled with Windows 7 - then Microsoft still doesn't get it.   Wait - I'm going to stop myself - it's not that "Microsoft" doesn't get it.   When you get that big - same holds true of EMC - you aren't monolithic (there are clearly parts of Microsoft that recognize that not everything is OS-centric - i.e. the Live team), but so long as the hypervisor crew at Microsoft are a small part of the HUGE Windows Core team (which they are now), it's inevitable.   Hmm - perhaps something to watch for from Microsoft - do they have the cajones to make the team seperate.....

"Unlike the earlier version of Virtual Server 2005 R2, Hyper-V’s new architecture and 64-bit foundation bring its feature set into parity with the features that are present in VMware’s ESX Server. Table 1 shows a feature-by-feature comparison of VMware’s ESX Server 3.5 and Microsoft’s Server 2008 Hyper-V."

My comment: You've got to love tables.   They give you a chance to pick your list of desired comparison points :-)   Our competitive teams produce them all the time and they make me laugh.    It's just bonus when many lines in the table are wrong :-)   What about 32-bit hypervisor - that doesn't sound cool, right?   Until you understand that ESX has had a 64-bit machine monitor (the part that handles CPU/memory emulation) for a while (3 years now last time I looked) - which is why ESX has supported 64-bit VMs for a long, long time.   Ok - picking "Maximum Number of Host Sockets" - alrighty - anyone have any 64-socket servers planned for hypervisor use?  You in the corner, all alone with your hand up?  Go home, seriously.   Ok - maximum host RAM, wrong - it's 256GB for ESX.   Live Migration - first of all, if this is a straight comparison of hypervisors, this shouldn't show in the table, since this is a dependency on Virtual Center, but if you're going there, you might as well add DRS, and many other features.   If you don't put it in the table, first of all, let's be honest - the feature isn't "Live Migration" - it's "Non-disruptive Migration".   VMware does it.  Xen does it.   Hyper-V doesn't.   The Hyper-V fan boys instantly jump and say "but they'll add it - SOMEDAY!".  Sure, but we're not comparing some mythical future product, we're comparing the RC Hyper-V (feature complete) to the shipping and deployed at hundreds of thousands of customers ESX.    What about something like Storage Vmotion then... Anything like that?  That's a very, very useful feature, and free and included in the ESX license.   I need to check on the max number of VMs - I think ESX's is higher, but I challenge someone (and seriously - someone please take me up on it), build a Hyper-V system with 64 sockets running unlimited (well, OK, Iets not be ridiculous - let's call it 200) VMs.   Let me know how it goes.   How's that hyper-consolidation going to work for you when you can't "Non-Disruptively Migrate" them?

 

"The primary differences begin with the hypervisor itself. As I explained previously, the ESX Server hypervisor is a heavyweight hypervisor that contains device drivers. In contrast, the Hyper-V hypervisor is a thin hypervisor that contains no drivers and no thirdparty code. Hyper-V’s device drivers are in the guest OSs, which makes the Hyper-V hypervisor smaller and more secure."

My comment - say it as much as you want, it doesn't make it true.   Furthermore, I think it's a misuse of the word "explain"  :-)   Now, Server Core as a kernel is actually very solid - and it's been that way for a while.   You will still need device drivers to plug in your SAN, your iSCSI HBA, your NIC, pretty well anything - and this come from those scary "third parties" mentioned earlier.   Now, the question of stability and security of kernel-mode drivers - either in the vmkernel with ESX or in Windows is debatable.   Personally, I'm in the ESX camp, and can defend the position, but in the end, this all comes down to the people writing and maintaining the drivers.   The "smaller" thing - well, I talked about that earlier.   The "more secure" thing - hmm.   A well implemented Windows system can actually be very secure.   My experience is that Windows server stability is often a PBKAC problem - but that's what you're bound to end up if your source of info is Windows IT Pro judging by this article.   Can anyone point to any published ESX exploits?   And no - shared folders doesn't count, you ninnies - that's VMware Workstation/Fusion - not a hypervisor.   And no - "BluePill" doesn't count either - that's a theoretical attack leveraging hardware VMMs - that's ONLY accessible on physical OSes or OS-centric Hypervisors!   Hmm.   Do I claim that ESX is impregnable?   of course not - it's still software (and BTW people who say that are silly too - firmware is software, heck even hardware is software - the point is that it's created by humans, and humans are fallible).   I do however claim that hypervisors - particularly those that aren't OS centric (think ESX and KVM) and don't have excessive dependencies on "parent partitions"/"dom0" are more secure and have a smaller attack footprint than those that do.

"Both platforms provide support for 32-bit x86 and 64-bit x64 guest OSs and large VMs with up to 64GB of RAM per VM. For more efficient memory usage, ESX Server provides a shared memory feature that lets VMs share common memory blocks. Although this feature can enable more simultaneously active VMs, it generates additional performance overhead."

My comment - ah... the old "minimize the value, then throw in some fud" trick.   The "shared memory" feature (I like to call it "memory dedupe" :-) ) is huge.   If you can demonstrate that you can run 1.5x or 2x more VMs on a given host, isn't that the core economic metric?   $/VM?    You can prove in a heartbeat that ESX can run more VMs than Hyper-V on the same hardware due to this little feature.   Don't believe me?  GREAT - I love skeptics!   Try it for yourself.   Xen is dead last here, BTW - throw it in for fun and give it a shot.   What that translates into in basic terms is this: even if you ascribe ZERO value to all the advanced non-disruptive fluidity, the automation of things in Virtual Center and the other elements of VMware's management suite - even if it's just a straight hypervisor to hypervisor battle - ESX is the cheapest by the all important $$/VM metric.   Oh, and BTW - 2x more VMs is conservative - for some use cases, like VDI use case it can be much much higher - just depends on memory commonality.

"Both platforms support booting VMs from either an iSCSI or Fibre Channel SAN."

My comment - Right, but ESX also supports NFS which is not to be minimized - some excellent use cases there.

"One area where VMware excels is in support for live migration (i.e., moving running VMs from one host to another). However, this feature requires the VMware Virtual- Center Server product. Hyper-V doesn’t support live migration, but when coupled with Windows Server 2008 Enterprise Edition and Microsoft System Center Virtual Machine Manager, it does provide support for what Microsoft calls quick migration— quickly saving the state of a running VM and then moving that VM and saved state to another host. Quick migration requires the use of failover clustering."

My comment - I guess he must be limited by word count in the article, that or he has no idea what he's talking about.   Everyone here likely knows the story on non-disruptive VM migration with Hyper-V.  It was promised, and promised, then dropped.  Then they started to compare it with VM HA (http://blogs.technet.com/virtualization/archive/2008/04/09/hyper-v-quick-migration-vmware-live-migration-part-1.aspx).  Then, Microsoft started to FUD it as equivalent (http://blogs.technet.com/virtualization/archive/2008/04/24/hyper-v-quick-migration-vmware-live-migration-part-3.aspx).   Of course, it's none of those.  Again, please, intellectual honesty please.   They needed to cut it to hit a date.   Then they worked on something they could get done, but "live" it ain't ().   The bigger thing to me is the dependency on failover clustering.   MSCS has gotten a lot, lot better over the years, but it's still incredibly complicated compared with VM HA.   The bigger issue is that do "quick migrate" a VM, the storage resource dependency moves - which means you need to have a LUN for every VM.  YIKES!   Again gang - don't listen to me.   TRY IT FOR YOURSELF.

"ESX Server is limited to 128 active VMs (probably enough for anyone), whereas Hyper-V is limited only by the available system resources. Unlike the desktop virtualization products, neither product provides support for guest audio or USB. ESX Server supports guest VM backup using the integrated Consolidated Backup feature, which takes a snapshot image of the VM and writes it to a backup server. Hyper-V supports live backup of VMs using Volume Shadow Copy Service (VSS).

My comment -  VSS backup again depends on the parent partition (oh, there's another "OS-Centric" giveaway).

"Setting up both systems was relatively easy. The basic setup for ESX Server was actually easier than the Hyper-V installation. Although the ESX Server installation was character based, the screens were easy to follow and I had a completely functional server in about 20 minutes....   For Hyper-V the actual installation process was easy but the subsequent system setup on Windows Server Core was a manual piecemeal process that required a good deal of Windows command-line knowledge to complete. The Hyper-V virtualization role can be installed on either a full Server 2008 installation or on a minimal Server Core installation. Server Core is the better choice for a virtualization server host because it has all the extraneous Windows components stripped out (e.g., the graphical shell, Internet Explorer—IE, Outlook). This bare-metal approach gives Server Core less overhead and makes it more efficient."

My comment - I don't know whether to laugh or cry.   Anyone who has done both - want to chime in?   ESX is essentially "next, next, next, name, IP address, finish".  It's 20 minutes if you're really slow at finding the "next" button.   Oh, and it's only character based if you don't go with the default graphical install.   Then, the fact that there's no GUI, no browser, no OUTLOOK (I mean - removing an email client as an example of "slimmed down" !!!!!) but otherwise a FULL OS (again, that 4GB thing) is considered "bare metal"?  Then the unsubstantiated "less overhead" and "more efficient".  Crickey.   What sort of logic skills are they teaching these days?   Is this guy so on the kool-aid that he believes what he's saying?

"Installing the Server Core OS took about 15 minutes; running the subsequent system configuration commands took about 20 more minutes and a couple of reboots. For more information about the commands to configure a Server Core system and add the Hyper-V virtualization role, see Top 10, “Essential Server Core Setup Commands.”

My comment - Yup, that sounds like a Windows install :-)

"To manage the system, I needed to attach to it remotely using the Hyper-V management console, which Figure 2 shows. .... Any Windows administrator will feel right at home with this Microsoft Management Console (MMC) 3.0–based interface."

My comment - I do agree, the Hyper-V management console is a nice, simple MMC 3.0 interface.

"Managing ESX Server is another story. ESX Server uses a Linux-based command shell—this command line might be comfortable to a Linux administrator, but I’m not one. (In fact, I rarely need to deal with Linux.) Fortunately, the VMware Virtual Infrastructure Client is a graphical tool that you can download by pointing your browser to the server’s URL. Figure 3 shows the VMware Virtual Infrastructure Client.  The VMware Virtual Infrastructure Client lets you create and manage VMs. However, it doesn’t let you perform server management functions such as adding and removing network cards. You need to use the command line to perform those types of functions."

My comment - WHOA!   Ok, first thing first - early in the article you could install the "heavyweight" VI client, right (I double check... right, he does).   You can use Powershell with Hyper-V also (being able to script operations as Microsoft has recently embraced, is very powerful when you get serious which they have) - that's the analogy (BTW - you can use Powershell with VMware as well - using the VI toolkit).  But likewise, the analogy to Hyper-V's MMC console is the VI client (which everyone uses - heck you use it with Virtual Center).   The browser-based VI management is truly pretty weak.   No one in their right mind would do it.    The VI client let's you do everything under the sun, is fast and responsive, and is as easy to use as any MMC.   As a 3rd party vendor, one thing that it's nice that VMware has realized is that it's important to be extensible (as we work to integrated more and more EMC functions where we can).   While the VI client isn't as extensible as MMC, it's not far off - but that's a developer thing, not a end-user thing.

"A big difference between VMware’s ESX Server and Microsoft’s Hyper-V is the price. Despite the trend toward free virtualization products, ESX Server has always been a chargeable product and is the staple of VMware’s product line.....In contrast, Hyper-V is part of the Server 2008 OS, making it essentially free to organizations running Server 2008."    

My comment - You need to license the Hypervisor, right?   So it's not free - it's the cost of Windows Server 2008 for that host, just like the license for ESX or ESXi.  In some cases ESXi is cheaper outright, and in all cases ESX is cheaper using the $/VM metric.

"Windows Server 2003 R2 and Server 2008 Enterprise Edition allow as many as four active virtual Windows instances at no additional cost. This licensing is the same whether you use Microsoft or VMware virtualization products. Running eight active VMs requires two Server 2008 Enterprise Edition licenses. Although not used in this comparison, Windows Server 2003 R2 Datacenter Edition and Server 2008 Datacenter Edition allow an unlimited number of virtual Windows instances no matter which virtualization platform you choose.

My comment - very few customers go Datacenter, almost everyone is Enterprise Ed. so this is a wash (but ABSOLUTELY something to leverage - whether it's Hyper-V or VMware)

"The basic virtualization and feature sets provided by Microsoft’s Hyper-V and VMware’s ESX Server are quite comparable and so far it’s a dead heat. ESX Server offers broader support for more Linux distributions and has a couple of more advanced features, such as support for live migration and shared memory between VMs. However, its command-line management is unfamiliar to most Windows administrators, its limited device support requires a more restrictive hardware platform, and it comes at a higher price than Hyper-V—which is essentially incorporated into Server 2008."

My comment - I just don't see how someone (and I've seen customers do this too - so it's not just the author) ascribe no value to:

• better $/VM - the ultimate metric for consolidation (due to memory dedupe)
• a simpler, more secure - and heck, AVAILABLE - hypervisor-only model
• advanced features like storage vmotion (even forgetting about Virtual Center - which no one in their right mind would forget)
• avoiding things like MSCS and 1:1 VM to LUN dependency if you want per-VM quick migration as you scale beyond a SINGLE hypervisor
• And that's all forgetting about what this guy will (hopefully) discover in his followup ("beyond the hypervisor") - and I'm going to limit myself to things that Hyper-V doesn't have any analogue for: VMotion, DRS (intelligent placement DOES NOT COUNT - it does it at create time only silly!), DPM, Site Recovery Manager, Lab Manager, Stage Manager, Life Cycle Manager

So here's the question.   Is the author willfully ignorant, and the editor so uninterested that they didn't get anyone to fact-check this?   Or, is this really a Microsoft-supported FUD job par excellence?    I hate conspiracy theories (because the truth is generally simple, basic and right in front of you - so I have to assume the former, not the latter.

What I hate is the effect these sort of things have.   They DO propagate misinformation.   Pointy-haired bosses everywhere will read it because they think they'll figure it all out from a few hundred words, and they assume this guy knows what he's talking about - because heck, they wouldn't print it if it wasn't true.   It's the essence of FUD - pure, distilled, FUD.

Come on, Microsoft - you're better than this - and all you MS haters out there, I actually really, really mean this.   Microsoft has made mistakes - EMC has also - every company makes mistakes when you're around long enough and get big enough.   BUT - Microsoft, you don't need to play this way.   You have resources to invest if you're serious (and boy, I'll tell you - VMware doesn't underestimate you - they are girding for a fight - are you?).   

Likewise, if you're serious - acknowledge what Hyper-V is (a very good 1st generation OS-centric hypervisor), and what it's not (a virtualization technology to build your business on, or an enabler of the"flexible, dynamic datacenter of the future).    Don't try to hold back customers through licensing, support FUD, and marketing FUD like this.   Compete on a level playing field.   Until you're ready to commit to a "V-Next" feature list and target release date (even with me conceding that those are always subject to change), don't combat "we don't have that" with "we're working on that".

You are a great company - albeit in need of some solid re-invention.   Look, I LOVE my Xbox360, and I'm typing this on Live Writer.   You can do it.   I'm throwing down a gauntlet in front of you - gather the true courage of your convictions and FIGHT.   It will make you better, it will make VMware better, and will move the whole industry forward.   I practice what I preach (EMC’s Celerra Simulator (I Eat My Words))

FUD is for losers.

Comments

[Chuck Hollis]

No doubt, the Microsoft marketing machine is gearing up for Hyper-V. And, no doubt, many of the Microsoft Minions will see the world a certain way. And, yes, many of us were dismayed by the casual disregard of facts in this piece.

My hope? That Microsoft decides to market the product based on its strengths and weaknesses, and doesn't try to paint an overly rosy picture, or misrepresent VMware's products.

Too many people are too familiar with what VMware products actually do to try any other approach.

Great post!

[Scott Waterhouse]

I think I probably resemble the militant comment... Anyway I try not to. Most of the time. Unless there is a specific campaign of misinformation and FUD. Then I might slip. (I will blame it on the banana peels.)

More to the point, if you are traveling that much, you should really get your hands on a Sony eReader or a Kindle. I have the former, and it is almost as valuable as an iPod for travel (second only because it can't block out the sound of screaming babies on a plane). The Kindle looks nice from an availability of titles stance, but it looks dorky in an 80s sort of way to my eye, and doesn't work from Canada.

Scott

[Steve Chambers]

If you are a windows techie who wraps a "Somebody Else's Problem Field" around the rest of the world, then who cares?

But if you are an Exec, Architect, IT Service Delivery Bod or any other subject matter expert like VCP, CCNA or Storage - than listen to this article.

Free is not cheap, and distributed IT has been getting away with waste for a long time, and VMware is not just helping fix a part of that but driving organizational change for business benefit - completely opposite from Microsoft's investment in the status quo (we can do EVERYTHING! - impossible!)

[Dan Baskette]

He also fails to mention any of the process of setting up Clusters. ESX has clustering embedded into the design of the product while Hyper-V is layered on top of MS Cluster Server. No where is this more evident than in the setup of new Virtaul machines. With ESX, you just use VMFS and Cluster VMs, or you can use VDMs and cluster machines. But with Hyper-V, to get cluster-enabled VMs you must first allocate disks to the Cluster Server so that when you go into the new VM wizard the Cluster Enabled disks will show up. It looks a lot like the install of Exchange, etc on a cluster where the Shared disks pop up as potential iptions.

[Duncan]

Great article! MS definitely knows marketing that's for sure.

[Z]

You think that is bad? Check out this fair-and-balanced look at how Hyper-V is putting Vmware and Linux on notice!

Review: Microsoft’s Hyper-V puts VMWare and Linux on notice
http://blogs.zdnet.com/microsoft/?p=1182

Your incisive and much-appreciated article on this mountain of FUD has probably single-handedly reduced it by half or more. Would you mind commenting on the article above? This one is far more misguided.

[Glenn]

When there's a choice between a conspiracy and a cock-up always suspect the cock-up. :-)

Great read - I'll pass the url around to my colleagues!

[Chris]

Great article review. I read the review before finding your blog and I had to laugh for quite a while about this guy. Virtualization is definitely not his core strength. I mostly enjoyed the part because he complains about Linux and Command line and then in the second part of the review he writes that he had to switch from 2008 to 2008 Enterprise for the install because certain things did not work right with Hyper-V ....

[Keith]

Great Read.. Although I wish you'd show more passion :-)

Reviewing the comments on the original article, looks like many readers share your review. 1's and 2's (mostly ones) across the board. I can almost see the red hand print...

Keep it up.

[dcs]

Just came across this post in my rss reader and I've got to go with CAS (confused author syndrome) on this one. Lots of really smart Windows power users just don't *get* the power of a bare-metal hypervisor. It's a really different way of thinking about operating systems and hardware. For some people, it just clicks - ESX + Virtual Center pay for themselves in hardware/power/space savings in no time. For others, they have to get their hands on it and run real servers on ESX for a while before they realize how revolutionary this software is.

The crazy thing, from the Microsoft perspective, is that ESX is responsible for a ton of Windows OS license sales. When you're bound by space and hardware costs, you can only have so many servers. When you're getting 15:1 or 20:1 server consolidation, the same space generates 10 to 20x the OS license revenue per host computer for Redmond.