If you have been following along on my Red Hat Enterprise Virtualization series, you may have noticed that the RHEV marketing hasn’t matched reality. Red Hat’s claims about being best in class and equivalent to VMware vSphere are dishonest. As much as I’d enjoy writing about something more interesting, I do have a few more important realities to share with the virtualization community about this latecomer.
RHEV Comparison Whitepaper
Red Hat published a PDF comparing RHEV to VMware vSphere and Hyper-V. Here is one of the entries on virtual storage:
Okay, so far so good. Apparently, as with vSphere, virtual disks are simply files and can be stored on any of the various storage domains. If you missed the last post on how RHEV Data Centers are limited to a single storage technology, please be sure to check it out — it’s not like vSphere.
As it turns out, the fact checkers were off the day Red Hat released that handy comparison whitepaper. Because if you actually went through the effort to set up RHEV and create virtual machines, you would never find anything resembling a virtual disk file on the host.
Logical Volume Manager
RHEV virtual disks are actually stored in cryptically named logical volumes – no encapsulation or portability here.
Did you spot the file? While it is common to say that “everything in UNIX is a file” this is taking that old adage to an extreme, wouldn’t you say? Storing virtual disks in this fashion makes it nearly impossible to move VMs between hosts – even if they are powered off. And you can forget about easily storing archive or DR copies of important VMs in an alternate location.
Even if you are running Red Hat Enteprise Linux virtual machines, the best and easiest virtualization platform to deploy, configure, and manage is VMware vSphere. Try for yourself and see.
Eric, XenServer use the same way to register/run VM and migration between nodes is fine : http://hypervisor.free.fr/xen_vg.jpg
Yes, they both use the same architecture for VMs on shared storage.
I don’t think Citrix calls LVM volumes “files” though. 🙂
Indeed they don’t but why did you say that “Storing virtual disks in this fashion makes it nearly impossible to move VMs between hosts” ?
I should have been more clear, since “move” has more than one context.
I’m not talking about live migration, but just manually copying with cp or scp. From there it is trivial to register and run a VM in seconds on another vSphere host.
I was thinking the exact same thing when i first look deeply in xenserver. Even more : “OMG, what the hell if you need to troubleshoot things like snapshots ?!”
Eric,
While the ease of access is indeed cleaner in vmfs, it is similar in RHEV. Look under /rhev for details. Note that intentionally, all nodes expect of the storage manager node maintain a file view only for the VMs that they own. This is done to improve security and performance.
There are also a set of commands to the local storage manager to expose/hide such disks, locate a certain disk, fetch and image from the internet, etc.
As much as I know, Redhat do not publish this interface and do not support it, how ever it is an open source api…
Eric,
It is clear that Redhat has probably overstepped on the “best-in-class” statement and probably overstepped on the marketing, but it seems like you are getting to the point where you are just nitpicking…
I was hoping that you could write a blog post about the cost differences between RHEV and VMware.
Thanks,
Mike
Cost comparison works best when two products provide equivalent features and benefits.
Question: What is the cost difference between a Big Mac and a set of snow tires?
Answer: Who cares?
If you need to drive in the snow a Big Mac is not going to help you, just like RHEV does not provide a production-class virtual infrastructure for enterprise datacenters. Even if RHEV were free, it is unusable.
If you think that RHEV doesn’t provide a reasonable alternative to VMWare for quite a large number of the VMWare customers, then you are quite jaded.
I realize that you believe that your product is superior, but you come across as some type of crazy fanatic. Your analogy of RHEV as a hamburger when you need snow tires is completely ridiculous. The fact of the matter is that another company provides a product that provides 90% of the functionality of yours and has the money and resources to match the other 10%. If you must, compare the most basic VMWare package in cost against RHEV and see where you end up in price. Let me guess, comparing these is like comparing a pencil to a 747? People might take you more seriously if you wrote reasonable comments/blog posts.
Cost is what drives the bottom line and if you can’t compete in cost, you will lose customers.
Robert,
Consider the possibility that I am not concerned whether or not people take me more seriously.
But seriously — have you actually used RHEV? It simply does not provide 90% of the functionality.
As far as cost is concerned, VMware participates in the free market economy and vSphere is currently priced according to fundamental capitalistic principles.
Thanks for your comment.
Eric
RHEV might be ready when they’ve had the following features stable for at least 6 months:
* hot add CPU, mem. NIC would be nice.
* importing and exporting OVF or other open/documented format VMs
* Migrating underlying storage without downtime (or, actually, AT ALL without resorting to CLI on the SPM host)
* Clustering of the management server
* Better logging and statistics (SNMP, integration into existing systems management infrastructure)
* Actual powering off/on of underutilized hypervisors, rather than some broken junk that just passes VMs from one hyp to another, endlessly, based on some inscrutable algorithm
* Redhat guest additions support, to make templating easier (a Redhat product with Windows templating, but not Redhat templating? DOPEY!)
* Multiple shared storage architectures per datacenter
* Ability to use local disk for VMs (particularly for non-critical non-prod instances or things behind a loadbalancer)
* Attach local ISOs to a
For my enterprise, these are non-negotiable requirements, and RHEV simply cannot do it, regardless of how vigorously their sales and marketing folks wave their hands. And I promise you, I’m no employee of VMWare or EMC, but rather a sysadmin who wants a solution he can trust over a weekend without being hassled.
The only features I’d want that RHEV has are:
* mass migration of hosts via multiple-select/right-click/migrate
* Redhat system disks using pvscsi/paravirtualization instead of LSI SAS
* GUI sugar to make booting from ISOs easier (instead of having to drill into the boot options/go to BIOS)
At least with RHEV 2.2 they stopped using shitty puttySSH libraries for their ISO uploader, that thing in 2.1 would push like 300-500KB/s MAX to the ISO partition..
Hypothetical:
I have an environment that runs 80 servers (mixed Windows and Red Hat).
I want to virtualize this environment, allow for live migration, snapshots and possibly even templates to easily roll out more servers as demand requires.
I have shared storage, lets say a SAN, plus a couple of beastly servers linked to the SAN which will host the virtualised environment.
Given my list of requirements from the virtualization point of view, can VMware fulfill 100% of the stated requirements? Can RHEV fulfill 100% of the stated requirements?
Your stance is that RHEV does not (yet) implement 100% of vSphere’s capabilities, which nobody is disputing. BUT it does not mean RHEV can not meet 100% of the bulk of consumer’s requirements.
That said, your fierce evangelical rants fall right in line with one of the Red Hat mottos: “First they ignore you, then they laugh at you, then they fight you, then you win.” – Ghandi
Slanted as your criticism is, the great thing about it is also that Red Hat takes note, even of your rants, and they’re changing their product to improve.
I’m glad I don’t rely on this blog for anything resembling substance. Reading this reminds me of watching a sporting event with a homer commentator.
Your priority seems is to be able to “do things the way I’m used to doing things” (“Oh my god – I can’t find the vmdk file and move it around – whatever will I do?”). Wouldn’t it be better to take some time to understand and adapt to an alternative way of accomplishing the goal? Better performance, more secure, more affordable – can’t imagine why any of that would be worth some time and growing pains.
I’m glad I’ve chosen RHEV. Just wait until the other pieces fall into place (remember RH has only been working on this for a couple years at most).
The most respected technical content authors tend to be the ones with a broad view on the technology and don’t choose sides… there really isn’t a point in doing that. This is not Coke vs Pepsi. Show us that you have some talent and skill, learn the product, then hilite the pros and cons in an advisory capacity and you’ll be far more respected outside of your circle of friends and the vmware community. You just come off as threatened, and quite frankly, ignorant.
Good luck to you and enjoy wallowing in your vmware bubble.
VCritical is not Consumer Reports. Maybe someday there will be an independent third party that can effectively evaluate virtualization platforms and make an unbiased recommendation alongside the latest in televisions and refrigerators. But don’t bet on it. Everyone has an agenda — especially in technology. I am a long-time VMware enthusiast, and that is why I work for the company.
As for Red Hat — I have rooted for them from nearly the beginning. But times are changing — Red Hat rushed an inferior product to market, after failing miserably with their previous hypervisor. To make up for lost opportunity, their CEO bashes VMware and the RHEV marketing has been flat-out misleading. A response was warranted.
Once you start using RHEV, you find out things like: snapshots are for powered-off VMs only, there is no P2V that will enable converting of the existing workloads to VMs, templates in RHEV are always linked clones based on a single common master — unusable for servers.
So to answer your hypothetical question: no, RHEV does not implement 100% of the bulk requirements.
Oh, and last I heard, Ghandi was more of a Xen user. If you don’t like what I found with RHEV/KVM, you wouldn’t believe what the XenServer gang is saying.
Open Source infighting at its finest. 🙂
“…there is no P2V that will enable converting of the existing workloads to VMs”
virt-p2v, you need to do your homework Eric. Sure, you need to boot the VM from a live CD in order to use the tool, but the tool exists.
“…Ghandi was more of a Xen user.”
Ha ha, I see what you tried to do there, however Zen is a Buddhist philosophy and Ghandi was a Hindu.
“So to answer your hypothetical question: no, RHEV does not implement 100% of the bulk requirements.”
By your definition, that should read “…RHEV does not implement 100% of the bulk requirements the way VMWare does.”
Still, as I said before, your criticisms are somewhat valid and are heard. Let us see what Red Hat does in the next year.
Rudi,
I like to think that I have “done my homework” — but I do welcome corrections when appropriate.
However, to suggest that virt-p2v is equivalent to something like VMware Converter (integrated with vSphere) is puzzling for two reasons:
1. RHEV does not include virt-p2v — it is not an integrated feature of RHEV, it is a separate, experimental project
2. According to the virt-p2v homepage, the project has had no activity in over 1.5 years and is being “rewritten” — recommending alternatives such as dd
Regardless, the discussion is welcome. Thank you for reading — and for not crossing over the line of personal attacks as so often happens in a venue like this.
Eric
While I have your ‘ear’ might I inquire whether any of the VMware Converter tools are able to convert a physical host which uses software raided (md0,md1,mdX) to a VMWare VM? I tried the Standalone Converter V4.0.1 last week, and encountered this barrier, whereby the Standalone Converter is not able to read from software raided devices. Sadly I had to resort to dd and nc in the end.
I also found that the VMWare Converter fails to migrate off of a RHEV VM, which was setup as LVM on top of a virtual LUN (/dev/vda1). I ended up migrating by doing a full restore from backups.
To clarify, I am referring to converting a Linux physical, which uses software raided devices.
Not possible, but you should be able to break the mirror and then perform the conversion.
Might be a nice feature on a Linux P2V to have VMWare provide access to its target data store as an iSCSI target, attach it to the Linux LVM, do a pvmove onto the iSCSI, then copy over the boot partition etc.. pvmove is nice in that it won’t delete the original PV blocks until after it’s completed and verified, if you quit the pvmove 99% of the way it all has to start over, time consuming but it maintains data integrity..
(I’m not aware of a comparable RHEV P2V tool, at least for Redhat. RHEV seems much more geared towards competing with Citrix, what with its desktop stuff and SPICE..)
Hi there team,
As Eric pointed out, RHVE does not have a P2V tool as of today. We are one of the few Red Hat Partners in Spain – please do not get me wrong here as I love Red Hat technology, after all I am a Linux guy – and two weeks ago Red Hat confirmed to us that its P2V tool is still beta.
Beside, we feel we have not been welcomed to Red Hat partner network, at least, not as much as with VMware partner program. We have reported to them a few problems during customers engagement and we did not get any support 🙁 That looked bad on us but on Red Hat too as the customer noted that we were on our own.
I am not saying that Red Hat socks, all the opposite, we need companies like Red Hat to create an even bigger and better competition so that VMware and others wont sleep on their laurels
My two cents.
Jose Maria Gonzalez from El blog de Virtualizacion en Español
OK, what happens in a year when you decide to get off of your current SAN LUNs and want to migrate either to new LUNs or to iSCSI?
In RHEV 2.2 (this was not possible in 2.1), if you change your underlying disk arch (from, say, FCP to ISCSI), you have to:
* export all of your datacenter’s VMs to the export storage domain, which has enough space to handle all of your VMs (you did build them all thin-provision, right?)
* destroy your datacenter
* rebuild a new datacenter with the new disk architecture
* import all of your exported VMs
You ask “how often will I do that”? I reply “as soon as you get a product that can’t do it, you’ll need to do it 3-6 months later after you’ve poured in a ton of work doing the virtualization”. Also, keep in mind that if you don’t destroy a datacenter _just right_, your export storage domain will be corrupted, requiring editing its metadata manually. Guess how I know.
Staying within the same architecture, RHEV offers no LUN management within the management tool, you have to go to the SPM host via CLI and do reorgs using LVM. If I wanted to deal with CLI, I’d go with a fully opensource equivalent and save even more, and probably get better support.
Why oh why have the Borg not included us in their collective? How I would love to have access to your experience.
LOL, no you really don’t, I wouldn’t wish it on a Windows admin..
Right now, I see RHEV as being an option for sites that have a single storage arch that will never change, underlying LUNs that will never be removed or resized, and have VMs important enough to only run on shared storage (as opposed to internal disk). The way I figure, if you’re going to go cheap, go free and hack together your own mgmt tools. If you’re not going to go cheap, why bother with the hassle?
Perhaps running RHEV with an NFS datastore is how they really expect it to be done, but I just don’t trust NFS that much, even on a Netapp. They claim they can support Oracle data stores over NFS. I just can’t buy it.
ps: Fault-tolerance (running VMs on multiple hypervisors in lockstep, possibly 3+ with constant ‘elections’ for data integrity) would be an exceptionally nice feature.
Aguante RHEV !!!
Interesting find, but I don’t really see the provenance of the info you are providing. What kind of storage is this?
The use of LVM acutally makes a lot of sense as mv / cp is not the most efficient way to move large files around on shared storage. A simple import / export of a logical volume between hosts on shared storage is much more efficient for moving things around.
And as stated before, if you look in the ‘appropriate’ locations (the /rhev dynamic mount point) you will see a ‘cleaner’ representation. Just like your BK / snow tires analogy, you are complaining that jet engines are wrong b/c they are different looking than auto engines.
Where do you get that Ghandi is more a Xen guy ? Let’s say that Ghandi is more Linus side, and so KVM side since Xen as been kicked because they didn’t wanted to bend to be kernel norm compliant.
Concerning what you said I guess dabble and rudy allready summed up what I’m thinking. But honestly since you admit you are not neutral on this, why writing in a blog just to say “VMware are fantastic whatever they do” ?
This is the problem with internet and blogs, people keep thinking they have interesting things to say ….
Pingback: Wrapping up the VCritical RHEV series | VCritical
Pingback: PowerCLI can easy register all VMs on a vSphere datastore | VCritical
Eric,
I am also a vSphere enthusiast and work with it most of my worktime. I beleive that’s the superior product in the market far ahead of any other for many reasons.
However I do beleive RHEV is something quiet intresting for the time it has been developed. It based on Linux and that fact it uses its already rock-solid drivers gives a good assurance of stability along with the flexibiity of easily implementing new features (NFSv4, Gluster, etc and be in line with any new feature the kernel support (remember it’s just Linux underneath). I do also beleive after ESXi, KVM is the best Hypervisor that although don’t have all features of ESXi, will catch up at some point and will be the big competitor do VMware either people like or not. Xen and Hyper-V I won’t mention as serious comparisons.
I see on your posts that you are very passionate about VMware, so do I, but in your case this makes you look like you are being forced or paid to specificlly attack RHEV and the way you write takes out any credibility you suppose to have when having a blog about a certain subject and writing public.
It’s not inteligent at all you say thar you are no concerned if people take you seriously or not. Why do you have a blog then if you don’t mind to be taken seriously ? Seems to me a very vain answer to a criticism. Or just to try earn a “vExpert” stamp ?
It’s great you take the same tim compare the features between vSphere and RHEV and write about it, but be more reasonable on your comments, see the good things on competitors, they are out there, and don’t try to hide from a reality which is that Redhat or simply KVM is cooming to face VMware and that’s something that can’t be avoided. You have only two choices: Adapt yourself for the changes or Lose.