“Red Hat today released Red Hat Enterprise Linux 4.5, featuring a 2.6.9-55.EL kernel paravirtualized for i686 and x86_64 machines. RHEL 4.5 also provides NFS performance metrics and updated kernel support for Infiniband connectivity, according to the release announcement.”
Redhat couldn’t have made a much smarter move than updating RHEL4 with a paravirtualized kernel. This will allow businesses using RHEL4 to seamlessly upgrade to RHEL5 by hosting RHEL4 virtual machines under RHEL5.
Now Redhat needs to make enterprise virtualization management tools. There isn’t anything opensource (yet) that comes even close to VMWare’s Vmotion technology for policy based live-migration of vms. virt-manager is all cute if you are playing with a virtualized desktop, but doesn’t do much for servers that don’t have x.
virsh is getting there, but not yet.
Indeed, this is a very smart move!
I have always been a huge RedHat fan and I am looking forward to there more “serious” desktop distribution that was spoken about a little while ago. I understand that Fedora is the community version, but I’m wondering if they plan on closing Fedora or just picking up and putting more resources into it. They’ve already missed the boat with Dell, but there’s honestly no reason not to go forward with this idea.
Anyway, I went WAY off topic here. Ah well…
Erm, no. You could always run RHEL 4.4 as a virtual machine under RHEL5, the virtualised kernel means you could run RHEL5 as a virtual machine under RHEL4.5
4.5 is really so people who have a real need to stick to RHEL4 can gain some features of RHEL5.
Redhat couldn’t have made a much smarter move than updating RHEL4 with a paravirtualized kernel. This will allow businesses using RHEL4 to seamlessly upgrade to RHEL5 by hosting RHEL4 virtual machines under RHEL5.
Erm, no. You could always run RHEL 4.4 as a virtual machine under RHEL5, the virtualised kernel means you could run RHEL5 as a virtual machine under RHEL4.5
4.5 is really so people who have a real need to stick to RHEL4 can gain some features of RHEL5.
My understanding is that, although you could run RHEL 4.x within a fully virtualized environment, it was not possible to run it within a paravertualized environment.
Paravirtualization comes with numerous advantages, including but not limited to.
1) Significant speed boost (at least that’s my understanding).
2) Support for giving dedicated access to specific hardware (e.g. network cards)
With RHEL 4.5, it is now possible to run it within a paravirtualized environment, as such taking advantage of the above to features and what ever else comes with para-virtualization.
So now admins can look to set up RHEL 5 virtualization infrastructure and migrate RHEL 4.x servers across by upgrading to 4.5 and installing the required xen modules.
re-write to try and make more sense
Edited 2007-05-04 10:55
Wrong… this is PARAVIRTUALIZATION.
If you don’t understand paravirtualization, wikipedia it. With older versions of redhat, you could run them fully virtualized, but that never runs as fast or well as when paravirtualized.
By that note, you can run RHEL3 “virtualized”, but not paravirtualized. Please read my post and teach yourself about the benefits of paravirtualization. Then you might understand why this is exciting news.
I know what para vs. full virtualisation is, but you seem to be hinting that these guest OSes have been modified to enable that…..?
As far as I know, only non-VT/Pacifica hosts would need a guest to run a modified kernel (the old Windows on Xen problem).
So has 4.5 been modified such that your could paravirtualise them on old processors, is that your point or am I missing something?
Yes, RHEL4.5 sports a paravirtualized kernel so that it can run paravirtualized on non VT hardware aka to support things like it running as a RHEL5 domU (guest in Xen terms). Paravirtualization does not need VT hardware (by design).
Xen has ran on non-vt hardware (using paravirtualization) until fairly recently where they support hardware virtualization using some hacks and code ripped out of qemu. Here is a decent page on Xen:
http://www.linuxjournal.com/article/8909
Also note that Redhat calls their Xen integration genericly as “Virtualization” because XenSource started getting really strict on trademarks of the Xen name.
Sorry for flaming you earlier, I woke up in a not so nice manner.
Edit:
Here is a link where a Redhat rep says pretty much what I just did about RHEL4.5 running paravirtualized (without VT hardware) under RHEL5.
http://www.internetnews.com/ent-news/article.php/3663126
Edited 2007-05-04 17:53
2.6.9 in RHEL4.5 while 2.6.21 just got released.
Sorry, but I don’t get it, why would anyone use something like RHEL for anything at all.
2.6.9 in RHEL4.5 while 2.6.21 just got released.
Sorry, but I don’t get it, why would anyone use something like RHEL for anything at all.
Stability and consistency.
It may also be worth while taking in to account, that Redhat also backport a significant amount of code to their older kernels.
Edited 2007-05-04 10:57
no point redhat putting a 2.6.21 kernel in a older Enterprise Linux when they could bring out RHEL6 with that kernel an have all the awesome features enabled , where as if they did that with RHEL4.5 they’d have that many callers ringing up sayting, ‘ why isnt this working etc etc, an that would be a bad move if they were to do that
So, if you’re running an Oracle RAC cluster or a PeopleSoft installation on RHEL4.4/4.5, what specific feature of the 2.6.21 kernel are you missing?
Don’t get too hung up on kernel version numbers. If there’s nothing there forcing you to upgrade to that version, who cares? As long as you’re in the ballpark (2.6.x) and it works for you, that’s good enough.