ADVERTISERS


« Will virtualization make the server OS redundant? | Main | On the rPath to virtual containerization »
Wednesday
08Aug2007

Flying virtually under the VMware price umbrella

JeffG.jpgEverybody moans about VMware prices. I mean, they charge $6,000 for the software you need to virtualize a $3,000 server box. Talk about monopoly pricing. Microsoft and IBM only dream about it, VMware actually gets to do it. (Well, maybe Oracle kind of does too, if you're using something like RAC.)

But seriously folks, if you were lucky enough to be in VMware's shoes, wouldn't you be doing the exact same thing? Think about it. You start with a bunch of computer science whizzes from Stanford, you get them to build a really ingenious and useful solution to a really hard problem that probably wasn't meant to be solved by ordinary mortal humans (e.g. x86 virtualization). You discover that lots of people are willing to throw money at you for the privilege of using your solution. So you spend the next ten years adding various desirable bells and whistles such as VMotion and VirtualCenter and generally tweaking the whole thing until it's really quite mature. And you bend over backwards to support pretty much every operating system that runs on x86 hardware, plus Solaris and Mac OS X. All the while you are operating in a market where no one else comes anywhere close to doing what you do as well as you do it. So naturally you file for an IPO that will make your employees and your corporate owner (EMC) obscenely rich.

Admit it. If you were the star of this scenario you would be charging sky high prices too. Astronomical prices, even, for as long as you could get away with it. Economists have a term for this. It's called charging what the traffic will bear. Every company does it, because if they didn't they would be punished by their stakeholders, who would soon step in to put an end to such fuzzy-headed charity.

But VMware's outrageous prices have a silver lining. They provide a generous price umbrella that spurs competition and encourages innovation. After my very interesting chat with Simon Crosby of XenSource a few weeks ago, I had a similar opportunity to talk with the other major independent Xen virtualization vendor, Virtual Iron. Founder Alex Vasilevsky and Chief Marketing Officer Mike Grandinetti were more than willing to explain how they are taking advantage of VMware's price umbrella.

Virtual Iron started in early 2003 with an ambitious dream: build virtualization software that would let users lash the disparate servers in their data centers together into a single virtual pool of resources, and let them provision and manage that resource pool in a unified way. The data center manager would throw in a bunch of commodity Intel or AMD servers, stir in some Virtual Iron sauce, and out of the brew would emerge a super machine equivalent in power and ease of management to a (virtual) mainframe.

This vision turned out to be a bridge too far. So late in 2005 Virtual Iron threw in the towel on their own hypervisor layer and decided that their true forte would be building management tools for other people's hypervisors. But which ones? VMware ESX was proprietary and unavailable, Microsoft Viridian was still a distant gleam in Steve Ballmer's eye. But the open source Xen project, while still obviously immature, was getting a lot of attention and was clearly off to a good start.

It took Virtual Iron about a year to retool. They launched a Linux version of their platform in October of last year, followed by the crucial Windows-capable version in December. I say crucial, because Virtual Iron agrees with XenSource that by far the greatest share of the customers they see want to run Windows in their virtual machines, especially the legacy versions. Today Virtual Iron is on version 3.7 and expects to launch a feature-enriched version 4 by the end of the summer. They have several hundred paying customers, and like XenSource they sell their product for approximately $1,000 per pair of sockets, compared to about $6,000 for VMware ($5,750 list price for the enterprise edition of VI3). Note that, like VMware, Virtual Iron is selling an actual license, not a subscription. An annual support contract will set you back another 20%.

Like XenSource, Virtual Iron's product is a hybrid of closed and open source. They periodically snapshot the open source Xen hypervisor, which of course is GPL'd. Then they patch and expand that source code to add needed features. For example, Virtual Iron says it was the first to support 64 bits and High Availability (HA) on Xen. Naturally they turn these features around and offer them back upstream to mainstream Xen, where they are sometimes accepted and sometimes not, as with any open source project.

Here the Virtual Iron team makes an interesting point. Xen, like the Linux kernel itself, is not a product, but rather a collection of technologies – or "engines" as they put it – around which one can build a product, or in fact many different products, by incorporating additional pieces of software functionality and packaging the whole thing up in an integrated bundle. Red Hat Enterprise Linux (RHEL), for example, adds some 4,000 custom patches to the basic Linux kernel, and Suse Linux Enterprise Server (SLES) adds its own set of very similar but not quite identical patches.

The closed source part of Virtual Iron's offering is the management server, which requires a dedicated machine and network card. This is where the automated provisioning functionality resides that Virtual Iron inherited from its original pre-Xen vision and that still sets it apart from its competitors. You install this management server, then you provision copies of Xen out over the network to your target hardware machines (which must allow network boot and use virtualization-aware Intel VT or AMD-V chips), and finally you install your guest operating systems along with the paravirtualized drivers that Virtual Iron provides. (For a detailed description of this process and a comparison with XenSource, see the recent InfoWorld review.)

Virtual Iron execs acknowledge some immaturities in their management code in addition to those in Xen. But now that they are no longer in the hypervisor game themselves, they believe they are closing in on the breadth and depth of functionality in VMware's ESX-based VI3 suite. They can move live virtual machines from server to server with LiveMotion, just like VMware's VMotion. LiveMotion and their HA feature do not require the complicated cluster file system approach adopted by VMware. LiveCapacity offers a form of load balancing across the physical servers assigned to a virtual resource pool and matches VMware's Distributed Resource Scheduler (DRS).

The Virtual Iron execs also boast that their hypervisor instances are easier to provision and patch than VMware, which they claim is a bear to install. Of course there are plenty of third party VMware provisioning tools, but they can be pricey. Virtual Iron also thinks that its automated provisioning gives it a leg up over Red Hat and Suse. Keep in mind that where the big distro implementations of Xen require a full-blown instance of Linux (RHEL or SLES) to function as the host domain on top of the hypervisor – the so-called Dom0 that houses device drivers and management agents – Virtual Iron uses a stripped down and "headless" Linux kernel for this purpose. The Virtual Iron virtualization services stack that resides on this kernel is stateless and entirely memory-resident, it expects to boot remotely over the network and writes nothing to local disk.

Virtual Iron offers a rich set of features that certainly sound as if they could give VMware a run for its money when they are fully baked and mature. Of course, since it doesn't have 2,000 employees and a billion dollar plus revenue run rate, Virtual Iron has had to make some compromises. It supports only a limited range of guest operating systems that at present includes RHEL4 (and CentOS 4), SLES9, Windows XP and Windows Server 2003. No Windows 2000, no Solaris, no Mac OS, no RHEL5, no SLES10 – although some of these are coming with v4 (Windows 2000 in particular). Also, the Microsoft operating systems only run in their 32 bit versions for now.

Furthermore, Virtual Iron requires virtualization hardware assist in the server chips, either Intel VT or AMD-V, not just for private and therefore unparavirtualizable Microsoft code, but also for Linux. That may be bad news for users who want to pack virtual machines onto legacy hardware, but it's also true that the march of progress is unstoppable. Virtual Iron says Intel and AMD have already shipped two million virtualization-aware chips since the middle of last year, and there will no doubt come a time in the next few years when the majority of server hardware in the typical data center has this feature. (On the other hand, Intel and AMD hardware virtualization is itself a moving target, and next year's versions will be different from this year's. For example, Intel's forthcoming VT-d promises to virtualize input/output as well as CPU instructions. But that's a whole other can of worms that I will avoid opening just now.)

Virtual Iron admits that for the present their primary sales argument is price. As with XenSource, most of their initial traction has been with midmarket customers seeking shelter from VMware prices. But not all. They are also winning some Fortune 500 customers who find that they can't justify the investment hurdle required to push VMware out from a few development and test machines to large numbers of production servers.

Since most market watchers estimate current hypervisor attach rates at around 5% of total Intel and AMD server sales, that means more than 9 out of every 10 new servers are running without the benefits of containerization, improved utilization and ease of management that virtualization provides. Software complexity may have something to do with this low penetration rate, but logic says price is the major issue. There has got to be a huge number of customers out there who are not buying now but who would buy if virtualization was cheaper. Maybe penetration wouldn't go to 100%. But suppose it went from 5% of servers sold to just 25%. The extra 20% of units would represent 1.5 million additional hypervisors per year. That's an awful lot of data center pavement being covered by the VMware price umbrella.

To be honest, I just pulled that 25% number out of a hat. I don't think anyone – at Virtual Iron, XenSource, VMware or elsewhere – has any idea what the true impact of aggressive hypervisor pricing from the Xen-based vendors will be. But it's fair to say these vendors will have to close quite a bit more of the functionality and maturity gap with VMware before we see the kind of wide scale adoption needed to hit something like 25% of the server market. To its credit, Virtual Iron is planning ahead by building out an impressively ambitious indirect sales channel. They have signed deals with mega distributors like Tech Data, they are working with Intel's white box system builder channel, and they expect to exit the year with more than 500 certified resellers worldwide (that's actually more than their total paying customer count to date).

While this is happening, it's a pretty safe bet that VMware will not stand idly by. Judging from the white papers they've published comparing their architecture with Xen's, it's obvious they are watching the subject closely. I'll come back to the issues of binary translation vs. paravirtualization and fat vs. thin hypervisors in a subsequent post (the Virtual Iron execs had a lot to say about that). But it already seems likely that the ESX product line – the company's crown jewel – is going to have more differentiated price points in the future and will address a broader swathe of market demand than just the price-insensitive customers they serve today. The price umbrella is probably going to spring a few holes. And of course we're still waiting to see what Microsoft will do. Although they probably won't be giving fully functional versions of Viridian away for free – at least not with the less expensive Windows Server 2008 SKUs – their pricing is bound to be aggressive.

Be that as it may, Viridian is still a year or more away and VMware is not going to be slashing prices on full-featured ESX in the immediate aftermath of its IPO. That gives the Xen players a little bit of runway. Let's hope they use it wisely!

Reader Comments (3)

"Economists have a term for this. It's called charging what the traffic will bear."

I've always called it the 'threshold of pain'.

Cool article, but such Blogger posts never let me know of a response, and I'll not book mark your article.

Cool, get what I mean?

August 12, 2007 | Unregistered CommenterJJMacey

"Talk about monopoly pricing."

There is a difference between "market price" and "monopoly price" do you seriously not know what that difference is?

Actually, I know that you do, so why put something like that into an otherwise interesting article?

The difference is important because you are minimizing what is "actually" criminal by comparing it to what "feels criminal"

August 13, 2007 | Unregistered CommenterFilterIN

I don't understand economics well enough to comment about it, but I do understand virtualization.

I found your post interesting (and bookmarked it), but somewhat incomplete. First, I was curious why you mentioned nothing about VMs like Virtual PC, qemu, or bochs. Qemu supports a greater number of host and guest processors and OSes than any of the VMs you presented in your posting. From a functionality standpoint, it's been the most flexible VM I've ever worked with (including VMWare, VirtualPC, Mac-on-Linux, bochs, and several others). Many of the things that you could do with with ESX (like checkpointing, building virtual clusters, and automation), you can also do with qemu--for free. Qemu also has a smaller footprint than VMWare. It's small enough for me to be able to run a qemu session, running Knoppix 5.1 as a guest, hosted on top of a Knoppix 4.0 (from a bootable CD).

Second, although you listed a few of the VMWare components, you didn't state how one might use them. Building a virtual cluster, composed of 100 virtual nodes, to support 5 users who basically only need to use MS Word is overkill. It would have been even more interesting had you presented 2 or 3 case studies that showed VMWare, Xen, and Virtual Iron's product in use. For example, qemu is great for building virtual clusters. There are several documented examples of qemu clusters in use. Yet, I find qemu to be unbeatable as a virtual, development machine, because it enables me to work in the host environment I want, targeting for the guest environment that I'm developing/testing products. Even if you wanted to, you couldn't use VMWare on a machine with a MIPS processor while targeting for SPARC 64, but I can do that right now with qemu.

Third, your argument about the penetration rate of virtualization is partially correct. You correctly identified two key factors (price and software complexity), but your analysis is incorrect. There are several virtualization solutions out there that are available for free, like qemu, Sun Solaris Containers, KVM, jails, z/VM, etc. So, the cost of the virtualization product is nil or negligible. Software complexity is the key contributor for the weak penetration rate. Software complexity issues include partitioning various enterprise solutions into their base component systems (which is often difficult to do), application/data migration, application stacks (LAMP/WAMP, OSCAR, etc), licensing terms (whether an arbitrary piece of software is licensed to run per machine/CPU/core/thread/socket), and a lot of other--including human capital--issues. That's only scratching the surface. Most data center managers I know, wouldn't think twice about dropping $9K for that machine with ESX--that's a bargain. The real issue is, and has always been (as soon as virtualization entered the picture), what the ROI is on the amount of effort expended to convert to a solution that uses virtualization strategically.

August 27, 2007 | Unregistered Commenterdp2

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>