Like pretty much every other big vendor in the IT space, VMware has many ways to hit competition. A very efficient one is to criticize other vendors though non-corporate blogs. This allows the company to be way less polite than what customers expect, while not keeping full responsibility for the critics if something wrong is said.
This approach has additional benefits: it allows customers to read a brutal (brutal, not necessarily brutally honest) review of products that may be hard to evaluate, it obliges competitors to defend their approach clarifying technical details that wouldn’t be revealed otherwise, and eventually it leads to counter-attacks, which expose additional weaknesses on both sides.
Over the long term this turns into a futile marketing skirmish (see the multi-year VMware-Citrix one), but at the beginning the information exposed could be really valuable.
This is what is going to (hopefully) happen between VMware and Red Hat now that the former completely smashed the new Red Hat Enterprise Virtualization (RHEV) platform, launched in November 2009.
A VMware Senior Engineer, Eric Gray, in fact recently published on his popular, personal blog, a series of articles analyzing multiple aspects of the new RHEV offering.
RHEV-M is one seriously mission critical component of the RHEV infrastructure, so it is surprising to see that there are no high-availability options for RHEV-M — no clustering or other redundancy support.
Even the approach of protecting RHEV-M by deploying it in an HA VM is also impossible — something that works just fine for vCenter Server and even System Center VMM. That’s because RHEV-M is the sole management tool for RHEV, creating a chicken-and-egg situation that essentially mandates the use of a physical system.
HA must be manually enabled for each virtual machine — no cluster-wide settings
No cluster admission control — administrators must manually ensure sufficient capacity would be available in a cluster to accommodate a host failure
No VM restart priority to ensure the most critical workloads and dependencies are brought online first
Primitive split-brain protection requires IPMI or other out-of-band management interface to force a host shutdown
Cannot protect the RHEV Manager itself — chicken-and-egg situation
So how did the architects behind Red Hat Enterprise Virtualization (RHEV) deal with CPU compatibility across KVM hosts?
They decided not to expose the true underlying CPU details and advanced instruction sets. Instead, they take a more conservative approach and masquerade as an old Pentium II Celeron CPU — no pesky SSE4 instructions to deal with here.
…
That’s the virtual CPU [an Intel Pentium II] presented to guests even in a cluster of identical Nehalem hosts! This is as “good as it gets” for RHEV.
Now, to be fair to KVM — the open source project on which RHEV is based — the capability to expose all physical CPU features is present, it’s just that Red Hat has not designed a suitable management feature such as VMware EVC to take advantage of it.
On RHEV Power Saver capability:
Red Hat Enterprise Virtualization has a seemingly-similar feature called Power Saver that also consolidates virtual machines onto fewer hosts. However, the RHEV solution stops there — hypervisor hosts simply sit idle with no running VMs; they are not powered off.
…
Red Hat claims that an idle host requires just 10-15% of the power required for a host with running VMs. That sounds very generous if you ask me. Frankly, from the looks of my HP C7000 BladeSystem Onboard Administrator power summaries, it seems quite false.
If customers were actually asking for this, then you’d expect some of those alleged customers to be readily available as references. So far there appears to be just one, a Swedish Internet video company named Voddler. I’ve never heard of them either — but a reference customer is a reference customer, and name recognition isn’t everything! I tried to find another reference, but after almost half a year since the RHEV 2.1 GA release there aren’t any.