Red Hat RHEV vs Vmware ESX

In 2009, Red Hat launched Red Hat enterprise Virtualization (RHEV)  to compete in commercial virtualization market dominated by VMware. RHEV has two components: Red Hat enterprise Virtualization manager(RHEV-M) and managed hypervisor,which could be RHEV-H(RHEV hypervisor, a trim down version of RHEL) or full-blown RHEL 5.5 (64bit) or newer
Feature wise, in paper,  RHEV looks not too bad, However what will be revealed if dug  further into technical details and compared with VMware?

	RHEV 2.2	ESX 4
Manager
Name	RHEV-M	vCenter
Compatible  OS	Windows 2003 Windows 20008 R2	Windows XP Windows 2003 Windows 2008 Windows 2008 R2
Backend DB	Microsoft SQL Server	Microsoft SQL server Oracle
Application Type	Web application (WPF .xbap application)	Windows native application
User Interface	Web UI	Web UI Windows native application
CLI [1]	Powershell	Powershell(PowerCLI) vCLI
SDK&API	Powershell	Powershell, Perl,C#, Java
Hypervisor
Type	Linux kernel (KVM)	Proprietary
Manager Agent	Python script	Binary daemon
HA/Migration [2]	YES	YES
Manager independent [3]	NO	YES
CLI [4]	NO	esxcfg-*/vimsh  commands
SDK&API	NO	Powershell, Perl,C#, Java
Storage  Type  [5]	NFS/iSCSI/FC	local disk/NFS/iSCSI/FC
Guest OS
supported OS [6]	Red Hat Enterprise Linux Windows	All major Linux distributions Windows Solaris Mac OS/BSD
Clone [7]	Supported	supported
Snapshot [8]	limited support	supported
Supported Hard disk [9]	IDE, VirtIO	IDE,SCSI
Cost	~2/3 of VMware cost	expensive

NOTES:
[1]  Manager CLI:  RHEV-M PowerShell has fewer number of cmdlets compared to PowerCLI

[2] Manager independent: In my opinion, it is RHEV’s  biggest mistake in design. RHEV-M is the central brain, the hypervisor is dummy host, which means you are NOT supposed to login to hypervisor to do configuration or VM operation,  e.g. add virtual network or start/stop vms. All must be done in RHEV-M. On the other hand, each VMware  ESX host is intelligent by design,  you can perform almost anything by esxcfg*/vimsh commands. ESX host just rely manager for HA and Distributed Resource Scheduling.(if RHEV-M fails, VMs in RHEV-H will not be interrupted, but don’t touch them, because you can’t restart them without RHEV-M)

[3] Hypervisor  HA: RHEV requires a form of fencing method for HA, e.g smart power switch or LOM card to shoot hypervisor in the head.

[4] Hypervisor CLI:  libvirt CLI tools are supported in KVM, but RHEV doesn’t use libvirt.

[5] Storage Type: You can’t utilize RHEV-H local storage, it is not visible in manager.RHEV datacenter  has a "storage type" (NFS/iSCSI/FC)  attribute, only single storage domain with the same type can be attached to datacenter.

[6] Supported guest OS: In paper, RHEL and Windows are the only supported OS, but you can  install almost any x86 OS, because RHEV-H is based on KVM not para-virtualization

[7] Clone: RHEV doesn’t call it clone,  You have to choose a template when creating new VM. VMware support clone from template or VM.

[8] Snapshot: You have to  shutdown  RHEV VM to snapshot it.

[9] VirtIO: RHEL 5.x has built-in VirtIO driver, Other Linux should also has VirtIO driver. for windows,  RHEV provide Virtual floppy file, virtio*.vfd,  to be used  during  installation. Any other OS without VirtIO has to use IDE (SCSI is not supported, VirtIO is supposed to deliver better performance than SCSI)

Conclusion:
In my opinion, so far, RHEV Server is not enterprise ready due to limitations of  [3] , [4],  and [8]. RHEV  Server lose to VMware ESX in almost every feature compared, However, RHEV does a better job in desktop virtualization thanks to Qumranet, whose root was desktop virtualization. (In 2008, Red Hat acquired Qumranet, from which the RHEV-M originated).

It is reported that Red Hat is developing RHEV 3, which will be based on Jboss (Java)  in Linux with PostgreSQL DB backend. Hopefully, RHEV 3 can redesign RHEV-H to make it “intelligent” by integrating libvirt for CLI ability in hypervisor.