[NTLUG:Discuss] RHEV-H (the standalone hypervisor of RHEV)

[Chris Cox]

On Fri, 2010-04-23 at 04:16 -0500, Ralph Green wrote:
> Howdy,
>   I do most of my virtualization with VirtualBox.  I am still just
> playing with KVM.  KVM needs hardware virtualization support and none of
> my virtualization machines have that.  So, I know this question may
> sound kind of uninformed.  Is RedHat forced to do some of this?  KVM is

Red Hat's RHEV depends on hardware(cpu) virtualization instruction
support.  RHEV is an OLDER revision of contemporary KVM which uses
a proprietary mgmt protocol.

> one of the newest virtualization platforms and I don't know if it is
> mature enough to use in production.  I am not saying it isn't, but just
> that I don't ever see anyone use it except for people working on some
> neat new programs in the virtualization area.  VMWare, XEN, and
> VirtualBox are used quite a bit in production.  Does any distro package

My vote is that RHEV is undeployable right now.  But... if you don't
mind the whole hypervisor tanking whenever you sneeze... I guess it's
interesting. :-)

IMHO, at LEAST two iterations from being usable (at least).  And I'm
not including the minor steps taken later this year.

It's simply NOT a Red Hat product.  I'll explain in a bit what I
"think" happened.

> KVM in a way that it is more open and useful that RedHat is doing?  Suse
> seems to push XEN, so I'd give RedHat some credit for trying to work

Novell has the Alacrity-VM work which is designed to replace the
virtio with a better vbus based system inside of KVM.  So no.... Novell
isn't banking on XEN forever and since GKH is still there, he knows
about the evils of Xen inside of the kernel.  (not saying GKH is
involved KVM/Alactrity-VM work... but certainly there is a Novell
association).  To make this a bit more confusing, the Novell engineer
and kernel dev behind this project is Greg Haskins (another Greg).

http://developer.novell.com/wiki/index.php/AlacrityVM

With that said, something that works is better than something
that doesn't work.  Thus it's still a Xen world (enterprise Linux
wise).

> with the more open technology.  I thought RedHat was the one doing more
> work on libvirt, so it seems they should get credit there, too.

While true, that is NOT RHEV, at least not today.  And Red Hat may
be using their KVM work (KVM was created by Qumranet) to confuse
the current state of affairs with the existing RHEV product.


>   Please educate me, since I am looking for good information in this
> area.  And, in a related note, I'll add that the thing I am looking for
> the most is a good physical to virtual tool.  I have been experimenting
> with writing part of this myself, since I have not found anything
> useful.  But, I still think someone out there must have already
> addressed this problem.

RHEV == old KVM

Best way to look at that.  So if you believe somebody is working on
this or that KVM wise... I know for sure it is NOT to be found in RHEV.

Qumranet's design was to HIDE the kernel.  Qumranet was likely using a
home grown kernel. Then Red Hat simply
replaced it with theirs to put their fingerprints on the
product line.  But since it was simply jammed in, there is no
normal Red Hat support/subscription/yum/etc mechanism for RHEV.
The update mechanism is by iso's released periodically (so NO
immediate update/patch solutions for any serious/critical problems).

And Red Hat charges you a SUBSCRIPTION fee ($499) per seat for RHEV.
(interesting since Red Hat can't really provide a typical online
update mechanism for the product... but people will pay them anyway).
Even if you choose to use RHEL, you still have to pay an extra
$499 and then RHEV's install iso will back rev level your good
KVM stuff to the crummy version that Qumranet developed on.  Personally,
the install is cloudy on doing this... Red Hat really wants you to
install the non-Red Hatish RHEV-H iso on raw hardware.

>>begin aside<<
Just for completeness, whether you use Xen or KVM using Novell's
SLES, you do NOT have to pay a separate subscription fee.. 
virtualization is just another part of the SLES functionality...

With that said, RHEV is just $499 for a 12x5 support option
and a full SLES is $799 for 12x5.... but of course that's also
a full SLES, virtualized or not... so YMMV on which is a better
value.

A 12x5 RHEL costs $799 now.  AND... in all fairness that comes
with Xen and KVM (just not the RHEV KVM).... :-)  However, Red
Hat does limit their Xen (and possible KVM) as well to a limited
number of VM's etc.  Not sure if Red Hat will maintain the
stupid limits in RHEL 6, hopefully not.
>><<

I know this is VERY critical.  RHEV stinks.  I don't think anyone
could say differently.

What's really bad is how Red Hat used their current work on KVM
to confuse matters to get the industry to hedge a bit and
essentially spread misinformation about RHEV based on the
marketing message that Red Hat created.  Of course, it's pretty
typical of many companies out there... just don't think of
Red Hat as some kind of knight in shining armor here...

Next version in beta is more of the same... nothing improved.
Again, I think AT LEAST two more iterations... and even then,
while the Qumranet team is still in charge, it's just moving
a simple/primitive mgmt interface away from .Net and embedding
it into Java + JBOSS... which is still a pain IMHO.

You could sort of tell that the Red Hat (Qumranet) team wanted
to take the Mono route... but since Red Hat has a unmovable opinion
on that (ultimately NOT because of M$ but more because of NiH, and not
acquirable), that
solution was dropped.... which means a lot of work for the Qumranet
folks in porting their code base from an easy to use framework to
the mess that is J2EE.

I suppose it's possible that Red Hat will wake up and NOT continue
the route of growth through acquisition and learn how to properly
assimilate technology into their culture rather than having a
bunch of cancer cells here and there.

It's possible that Red Hat was scared since the only enterprise
virtualization product line was coming out of Novell... and so they
did a quick tech purchase and pushed things out to confuse
the marketplace a bit while they play catch up.  If you're using
a non-VMware, non-Citrix, non-Microsoft enterprise level hypervisor
today, chances are you are using Novell's SLES Xen.

Red Hat is a confusing company.... pretty much like any big
company out there.  They have THREE virtualization lines with one
being phased out.  Red Hat adopted Xen (which they said SUCKED
even though they did a large amount of the work) when Novell
included it and built a platform for virtualization on top of
their SLES enterprise product... Red Hat had nothing and their
attempts at bad mouthing the Novell decision failed... so Red Hat
went Xen.  Red Hat likes KVM and aquires Qumarnet and decides
that KVM will be the focus of the NEXT version of RHEL, thus
dropping Xen.  Red Hat also pushes out a standalone product
line called RHEV which is NOT like the KVM included in RHEL.

So... RHEL 6 will include KVM and even SPICE components (though
SPICE is ONLY supported via RHEV and NOT in RHEL).  So you can
virtualize using libvirt and friends using RHEL, or you can use
the vdmsp proprietary mgmt tool of RHEV-M + RHEV-H.

Clear??

Let's just say Red Hat is not being very clear at all right now. The
confusion is creating internal competition... two product lines
potentially competing against each other virtualization wise.