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

Fri Apr 23 13:23:22 CDT 2010

I messed up a bit on the RHEL pricing if you want
the equivalent to SLES the cost for 12x5 is $1499.
The $799 is for the limited RHEL product.

Sorry about that...

On Fri, 2010-04-23 at 13:17 -0500, Chris Cox wrote:
> 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.
> 
> 
> 
> 
> 
> _______________________________________________
> http://www.ntlug.org/mailman/listinfo/discuss