TAG | rhel
For anyone else googling trying to find the answer to this, as I was today, I refer you to the following Red Hat article:
To paraphrase, the solution is to take the RAID card out the server and throw it in the bin. The S300 isn’t a real RAID card, it’s a fakeraid. You’re better off just using Linux software RAID.
Unfortunately, the cabling in the server doesn’t allow for connecting to the on-board SATA ports, or rather for powering them. Speaking to Dell support, they initially suggested that just disabling the card in the BIOS would be sufficient; they later admitted it isn’t, and offered to send out suitable cables.
I seem to remember Dell making a big deal of their entire server line offering full Linux support some time ago, so I’m surprised to see them making this retrograde step – particularly as Linux represents a large percentage of the server market. In Dell’s defence they do make it reasonably clear that the S300 card isn’t supported under Linux at the ordering stage.
As I keep getting asked by customers when they can expect Red Hat Enterprise Linux 6, I thought it was worthwhile to make a post on the subject. This is a reasonably long post, but the simple answer to the question is that I don’t know, but my educated guess would be Q4 2010, and that we’ll have a firm(er) date by the end of June. Please note that I’m not a Red Hat employee, although my company is a Red Hat partner, and that nothing in this post is official in any way, shape or form.
Red Hat Enterprise releases have been traditionally 18-24 months apart, and on that basis one might have expected RHEL6 to have been released sometime between October 2008 and March 2009, as RHEL5 was released in March of 2007. So what’s taking Red Hat so long, and when can we expect RHEL6?
There are a number of reasons for the delay, but the biggest is related to the Fedora Project, who create Fedora, on which Red Hat Enterprise is based.
For Fedora releases up to version 6, on which RHEL5 was based, the Fedora Project was run very much as an in-house Red Hat project, with contributions from the wider Open Source community. Post FC6, the Fedora Project was much more run by the Open Source community, with Red Hat contributors. This seems to have led to a shift in focus from fixing bugs to implementing new features. This isn’t necessarily a bad thing – Fedora exists to be the ‘bleeding edge’ of development, pushing at the boundaries in a way Red Hat are obviously unable to do with an enterprise focussed product like RHEL. Unfortunately, Fedora 9, on which RHEL6 was to be based, released with a large number of critical bugs and stability issues. Red Hat made the decision that they therefore couldn’t base RHEL6 on this release, and instead poured man-power into the Fedora Project, fixing bugs and generally improving stability as much as possible.
The evidence is that RHEL6 will now be based on Fedora 12, which was released in November of last year. The was a gap of just under a year between Fedora 6 and RHEL5, so this would point to a release in Autumn of this year.
The other issue that has caused delays to RHEL is that of virtualisation. RHEL4/RHEL5 utilised the Xen hypervisor for their virtualisation. In September 2008 Red Hat purchased Qumranet, whose staff included the leaders of the KVM project, an alternate virtualisation technology. KVM is very much seen as the future for Linux virtualisation, and Red Hat immediately made it clear that this was the direction they would be pursuing. RHEL 5.4 included KVM as a ‘technology preview’, so clearly much progress has been made integrating it into the main Red Hat release. It’s therefore likely that this is no longer holding up RHEL6.
I expect the final release date for RHEL6 to be announced at the Red Hat summit at the end of June. There have been some suggestions that RHEL6 itself will be released at the summit. Unless Red Hat release a beta within the next couple of weeks, I’d say this looks distinctly unlikely.
23
Running an Ubuntu Hardy Xen domU under a CentOS dom0
1 Comment | Posted by admin in Virtualisation
As pretty much always with Linux there’s more than one way to do this, but here’s how I got a nicely working para-virtualized Ubuntu Hardy domU running under a CentOS 5.2 dom0:
- Install hardy under an HVM using the standard ISO
- Boot into your new hardy install and run
sudo apt-get install linux-image-xen(make sure you have universe enabled) - Add appropriate settings to your /boot/grub/menu.lst – here’s what I added:
title Ubuntu 8.04.1, kernel 2.6.24-19-xen
root (hd0,0)
kernel /vmlinuz-2.6.24-19-xen root=/dev/mapper/dsk-root ro
initrd /initrd.img-2.6.24-19-xen
- Add a console on xvc0:
sed -e 's/tty1/xvc0/' /etc/event.d/tty1 | sudo tee /etc/event.d/xvc0 - Power off your Ubuntu VM
- On your CentOS dom0, alter the Xen VM configuration file to boot using pygrub, very basic example below:
bootloader = '/usr/bin/pygrub'
memory = 1024
name = "ubuntu-test"
vif = [ '' ]
disk = [ 'phy:/dev/san1/ubuntu-test,xvda1,w']
- Restart your Hardy VM and enjoy massively improved performance
One thing missing from the para-virtualized VM is VNC support – you have to use the console via the ‘xm console’ command.
The procedure should be similar for Citrix XenServer, although it will involve some messing with the xe vm-param-set command rather than editing the config file. When I have a chance I’ll document this too.
Update, 30/9/08:
To enable a VNC console, do the following as well as the above:
- Add the framebuffer drivers into the initramfs
echo "fbcon" | sudo tee -a /etc/initramfs-tools/modules
echo "vga16fb" | sudo tee -a /etc/initramfs-tools/modules
sudo sed -ie 's/^blacklist vga16fb$/#&/' /etc/modprobe.d/blacklist-framebuffer
- Re-generate the initramfs
sudo update-initramfs -u -k all
- Alter your grub menu.lst to include the boot options console=tty1 vga=normal (best done via the defoptions line, I tend to remove quiet and splash from here too)
Reboot, and you can now use a VNC console as well as the Xen xm console command.
