Earlier in this series on Red Hat Enterprise Virtualization (RHEV), I mentioned the fact that the RHEV Manager (RHEV-M) deploys exclusively on a Windows Server 2003 system and can only be accessed from Internet Explorer. Obviously, this is upsetting to loyal open source enthusiasts, but anecdotal reports indicate Redmond has completely endorsed the strategy.
Red Hat makes some strong claims about RHEV worth scrutinizing:
Compared to the competition feature by feature, Red Hat Enterprise Virtualization offers best-in-class, cutting-edge enterprise virtualization features.
In this article, we’ll take a more detailed look at the RHEV Manager.
It’s The Manager
Make no mistake about it, RHEV-M is not just a manager, it is The Manager for Red Hat Enterprise Virtualization. There are no other interfaces for administrators to create, start, stop, or migrate virtual machines. No command-line utilities and no option for a management client to connect directly to hypervisor hosts.
They could have called it…
Red Hat Enterprise Single-Point-of-Failure
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.
Red Hat is asking their loyal Linux customer base to deploy a physical Windows box — that is a single point of failure — to manage their open source hypervisor. I did not notice that bullet point on their competitive comparison document.
In fact, Red Hat goes so far as to say:
… today, server virtualization is not used pervasively in the production enterprise datacenter. Some of the barriers preventing wide-spread adoption of existing proprietary virtualization solutions are performance, scalability, security, cost, and ecosystem challenges.
It never occurred to me that VMware, the aforementioned proprietary virtualization solution, had so many challenges. How does vSphere management measure up to RHEV Manager…
VMware vSphere: For all Mission Critical Workloads
While VMware vSphere also has a Windows-based manager — vCenter Server — it is not a single point of failure. The vSphere Client performs equally well when connected directly to a VMware ESX system to perform necessary management or configuration and various command-line utilities and scripts can be used without vCenter Server. Also note that VMware is not an operating system vendor and platform support is therefore based on customer demand and subject to the principles of free market economics.
Naturally, vCenter provides important configuration and management capabilities such as DRS and performance monitoring. If an environment cannot tolerate vCenter downtime, there are several methods that can be used to increase availability, from VMware HA, to MSCS clustering, to the high-end vCenter Server Heartbeat. Even if you don’t implement any of those measures and disaster strikes, it is relatively quick and easy to rebuild vCenter and bring live VMware ESX hosts back under management with zero impact on running VMs.
Dare to Compare
If you have not tried VMware vSphere 4, download your free 60-day evaluation with all Enterprise Plus features and capabilities today. I would say put it head-to-head against Red Hat Enteprise Virtualization, but since no evaluation version is available, that may be difficult.
If your datacenter needs the most reliable virtualization platform with the broadest support for guest operating systems — including Red Hat Enterprise Linux — and the best management capabilities in the industry, go with VMware vSphere.
Pingback: Tweets that mention RHEV Manager — It’s not just a clever name: Earlier in this series on Red Hat Enterprise Virtualization (RHEV), I ... -- Topsy.com
Here is my irrelevant $.02….Red Hat is trying to satisfy the masses with RHEV which is why their Manager is Windows based. It worked for VMware…ESX is “linux-y” but the vCenter runs on Windows. Contrary to what delusional thinking VMware has there are A LOT of people that still aren’t virtualizing that are Windows admins that have never SSH’ed into anything in their lives.
Pure feature set does RHEV match against ESX?…Probably not. Taking a page from Microsoft’s playbook, it’s good enough. If you factor ESX and vCenter and SnS, RHEV is still cheaper and cost is and always will be a factor.
Just to be clear, I’m a fan of VMware, always have been always will be, and all my enterprise production workloads run on vShere. However, looking at alternatives in the test/dev area makes sense. Who wants to pay for ESX licenses on dev boxes which you could essentially do for free with Hyper-V/SCVMM with dev if you have MSDN subscriptions. However this nonsense competitor bashing has gotten, well, childish. Did you really think no one would try and challenge VMware eventually?
Use the free ESXi for test/dev scenarios !
ESXi doesn’t support 64bit guests, so that isn’t an option for a test/dev environment in our datacenter. We use KVM, its free and does support 32/64 bit guests.
Of course if does. Where did you get this wrong info ?
ESXi (now called vSphere Hypervisor) supports basically all the guests the full licensed version does.
Right on, Fernando. Good to hear from you.
VMware vSphere has the broadest guest OS support of any hypervisor – hands down.
I know this is an old thread but in order for free ESXi to support 64bit guests, the hardware has to have the virtualization technology in the chip. I have some old HP DL360 G4’s that are 64 bit but do not have the virtualization chipset and will not run 64 bit guests. Obviously KVM also has to have the virtualization technology for their hypervisor to run, so its a wash either way.
Correct. Challengers to VMware are inevitable, and they should prepare to have their claims scrutinized.
There are a few inaccuracies in your statements, though. RHEV is on Windows for now because they acquired the technology via Qumranet. They want to move to an open source/Java platform and are typing as fast as they can. It’s questionable, but this Windows release is a stop-gap measure to buy time. You are right about Windows admins vis-a-vis SSH, but the good news is that ESXi addresses that perfectly.
Lastly, which is really the whole point of me investing time in these blog posts: on the marketing slicks RHEV does look “good enough” but in practice it is not. Like Fernando pointed out, free ESXi is a much better alternative for test/dev, and it uses the identical VM format and user interface.
Thanks for the feedback,
What does Windows and Qumranet have to do with anything? As someone who actually tested and Qumranet before they were acquired by Red Hat, there was no Windows requirement for KVM. Qumranet designed and developed KVM and SPICE. There are also some features beyond your talking points your’re seem to keep ignoring, like SPICE and RHEV integrated connection broker for VDI.
I’m not trying to discredit your findings or your blog posts but it’s the same rhetoric with every VMware competitor. “We can do this, they can’t therefore you suck and we’re better” View didn’t start supporting browsers beyond IE until 3.0 and you just got vCenter HA (linked vcenter) in 4.0 besides paying a ridiculous amount of money for VM-Heartbeat (whatever the vCenter HA solution is called these days)
Not every rev 1 release is going to be a VMware killer….relax, VMware arrogance is safe for now.
What does Qumranet have to do with it? Everything.
The issue here is not that other virtualization platforms are available — it’s a free market. However, a company that makes unsubstantiated claims about being equivalent to VMware at a fraction of the cost should expect to be challenged.
‘RHEV does look “good enough” but in practice it is not’
Really? Not good enough? So why is IBM deploying RHEV for their cloud?
I suppose IBM has some administrators, developers and support engineers. But what if you’re not as big as IBM and you can not allow additional dedicated server plus windows license just to run “free” Linux virtualization system? What if you can allow that, but don’t want just because it’s Linux! You want it to run Linux and you want HA that doesn’t have single point of failure also. Otherwise it’s not HA at all.
The question is whether IBM is using RHEV or RHEL+KVM. Big difference.
If you read the article you would have noticed this :
The public IBM Cloud infrastructure is based on Red Hat Enterprise Virtualization (RHEV) stack based on the Kernel-Based Virtual Machine (KVM). Red Hat acquired the technology from Qumranet in 2008.
vCenter being Windows-only is a pity, both for customers and for VMware. How cool would vCenter in a vApp be !? That’s the way it should have been for a long time.
But RHEV-M being Windows-only is absurd, coming from Red Hat. They of all people should have tried to port this to Linux with all of their might.
RHEV-M being needed for something like VM-failover (HA in VMware terminology), that’s a design failure, IMnsHO. Unless there’s some other mechanism that can failover the function of RHEV-M in case the active instance fails.
Pingback: RHEV HA is not equivalent to VMware HA - do not believe the marketing | VCritical
Qumranet’s manager was based on Windows 2003 as well and this is the main reason for the fact that also RHEV-M is that too.
I had the pleasure to work with Qumranet manager before the company was acquired by Red Hat and I can tell you it had failover solution as the manager was, as Tony already said, an active component of the Soild ICE architecture, functioning as the “connection broker” of the resulting VDI (Qumranet was not virtualizing servers but only desktops), that made the failover mechanism a requirement for customers.
I’m sure Red Hat will introduce such a feature again soon, together with the release of RHEV for desktops or later, with the completion of the porting into cross-platform Java language.
Definitely, I guess for Red Hat it’s better being on the market with a great hypervisor (KVM) and a manager that runs on Windows (even if you notice it only during the manager installation), rather than waiting longer and leaving all the market to VMWare & C.
RHEV was deployed in our environment as a POC.
Compared to VMware’s dominance in virtualization to its strong management infrastructure, RHEV Manager can’t yet match VMware’s management systems feature-for-feature at the top end.
I would say RHEV-M is still a premature product compared to VMware vCenter.
Given below are my observations:
•Initial configuration of RHEV-M solution is bit tricky and time consuming compared to VMware Infrastructure
•RHEV-Manager uses web interface and it is cluttered.
•Red Hat still doesn’t have any client application to connect RHEV-M, this makes RHEV-M as single point of failure
•Multiple VM administrators can be added in RHEV-M however all of the administrators would need to logon to a single Server to manage and administrate VMs, this is not feasible solution.
•RHEV-M uses 2 types of VM consoles i.e. VNC viewer and Spice VM viewer however both of them are not good compared to VMware’s VI Clients built in VM console manager
•VM Snapshot option is not very clear in RHEV-M
•VMware tools can be installed on to any VM through VI client interface however Red Hat VM tools need to be installed manually on to each VMs post VM has been created.
•RHEV doesn’t support connecting local CDROM or shared OS ISO’s for VM deployment. Each and every ISO need to be uploaded on to a central NFS ISO share to accomplish this activity which is quite troublesome feature.
•RHEV Log manager definitely needs improvement.
There are many features which could have been tested however due to time constraints I couldn’t evaluate all the features of RHEV-M.
RHEV-M clearly have a long way to go before they can compete on equal terms with the entire VMware Virtualization Technology system. However Red Hat appears determined to plug away at its virtualization offering, slowly filling in the management features and narrowing the gap until it is ready to go head-head with VMware.
Many thanks for your contribution. It appears that you took a serious look at RHEV and I appreciate the detailed writeup.
Thanks for your comments.
Also, forgot to mention few good things which I have observed w.r.t. RHEV.
Fetures which are pretty impressive in RHEV are:
•VM instances can be created on the fly using a template; I had created 50 VMs (each VM has 40GB HDD and 4GM RAM) within 15 mins using VM template. (We have a RHEV cluster with 2 servers, each server with 6TG HDD and 64 GB RAM)
•Thin provisioning feature is an excellent option included in RHEV.
Interesting points. The reason those VMs deploy so quickly is that they are always linked clones that use a template as the base disk — such an arrangement has use cases but there are many scenarios where this is not desirable. vSphere makes a full copy when deploying a new VM – no longer dependent on the template.
As for thin provisioning in RHEV – according to the docs it is not recommended for server VMs due to performance problems. As I have previously discussed, vSphere thin provisioning is fully supported and performs on par with preallocated disks.
Thanks again for your contribution and for reading VCritical!
Pingback: uberVU - social comments
Thanks Eric for the valauable inputs.
“Failed to connect to the RHEVM service”
What to do ?
just log back in on the RHEV-M website…
Just wanted to provide an update. In July Red Hat had their Red Hat Summit… and there they released a RHEV 2.2 update that includes RHEV for Desktops… which is basically an addon component that you have to purchase licenses for the desktop VMs in chunks of $25. Stock pricing appears to be $15 per desktop VM.
The real news here, with regards to your article though… is that RHEV 2.2 Manager installs on Windows 2008 Server R2 and has the ability to be clustered for failover.
So, as far as I can tell, your main concern about single point of failure is no longer correct.
Red Hat continues to work on the JBoss-based update to RHEV-M that will no longer be Windows-based… but the release date for that has not been given. I also have to wonder what they plan on doing with the current requirement for Active Directory.
Thanks for the update.
While I share some of your critiques of rhev-m it should be noted that you are incorrect about it being a single point of failure. It can be installed in a KVM on red hat cluster suite running on two rhel ap boxes which makes it highly available. This is fully supported. Also while there are many things I like about vsphere, their clunky vcenter ha solution is not one of them.
Using that logic, a person could also deploy RHEV-M on a vSphere cluster to gain HA protection. The point I am trying to make is that availability was not part of the original RHEV design. And it should have been, considering RHEV-M is responsible for restarting failed VMs.
Practically any application can be installed inside a VM on an HA cluster — does that legitimately remove the designation of “single point of failure” across the board?
My 2 cents…
“It can be installed in a KVM on red hat cluster suite running on two rhel ap boxes which makes it highly available. ” this point can be taken; However RHEV-M is still a single point of failure as per my perception.
You cannot have multiple RHEV-M’s controlling your redhat hypervisors. There is no master – slave feature avaialble yet in RHEV-M which makes it difficult to operate. Moreover, RHEV-M would need to be installed on a Windows box wherein at most 3 administrators can simultaneously connect to RHEV-M. If you would need to give access to more than 3 admins then probably you need to buy Windows Terminal Server licenses to suffice this requirement which is again very expensive.
I want to clarify that RHEV does have available CLI to use it without RHV-M. SO is not THE manager…RHEV-M is a MANAGER!
Interesting. After finding nothing in the product documentation about this, I personally asked a Red Hat support engineer for more information and he confirmed there is no CLI to manage VMs directly on a RHEV Hypervisor — at least with version 2.1.
Could you please explain how this is accomplished?
The CLI application is called ‘vdsClient’ and comes in the vdsm-cli package that should be installed on each host machine being managed by RHEV-M.
I am curious… what Red Hat tools would you be installing on the guests? I’m assuming you mean the drivers for Windows, because as long as you are hosting a Linux build, you shouldn’t need any additional tools. This is not really the case with VMware.
Someone also talked about having to have multiple user licenses to allow admins access to administer RHEV-M. Since RHEV-M is a web interface, there is no need to RDP in, thus no need for additional licenses or client installations. Although, sadly it still seems to prefer that you are in an IE browser. Come on java port!
Also IBM’s cloud is on RHEV, for which RHEV-M is the management application. To help clarify, RHEV uses KVM and can use RHEL as a hypervisor if not using RHEV-H (the free hypervisor). Whereas RHEL+KVM by themselves are not RHEV.
Guess what they are adding in RHEV3? client tools… bleh. 🙂
RHEV does have a CLI/API to control your environment. The RHEV-M actually uses it. Documentation can easily be found on the Red Hat website. With the release of 2.3 Python is also available where this is PowerShell only for the moment.
All I can say is wow. Is this some sort of back door marketing ploy from VMware? It must be because VMware itself wouldn’t get away with this type of ‘badmouthing’. Someone should really inform VMware leadership of this website and the bad image this site is creating.
This whole website makes you guys sound like a bunch of douche bags. Why would anyone ever read this crap? This websites slogan shouldn’t be “Informed virtualization criticism”, it should be “VMware is awesome, everyone else sucks”.
I read your bio Eric and all I can say is that I’m deeply embarrassed that a fellow U.S. Army soldier would act in such a way. You obviously never learned professionalism during your time in the military or your life, because this site is far, FAR from professional. I have read reviews from 13 year olds that are articulated in a more professional manner.
P.S. I like how Eric ‘chimes in’ on peoples comments trying to cut them down, but then when proven wrong, there is now response…. Wonder why that is?
We have Installed the RHEV on IBM Storage DS3950 with two IBM system X3850 . Unfortunately the Manager Hardisk has crashed & we don’t have the backup of this. How we should start the VM on IBM storage.
Need your support
That will be fun. You need to get with Red Hat about that because direct access to their storage is possible, just not well documented.
You should install RHEV-M as a “normal” KVM virtual machine using 2 physical machines in a clustered setup. In that cluster you can then also configure your ISO storage domain and even your satellite setup.
As of RHEV 3.0 you might have a look at JBOSS clustering for that