cancel
Showing results for 
Search instead for 
Did you mean: 

SAN Based boot from Red Hat 4

SOLVED
Go to solution
Robin Geddes
Occasional Visitor

SAN Based boot from Red Hat 4

I looked on the SPOCK site (http://h20272.www2.hp.com/index.aspx) and it says that RH AS4 update 6 is supported for Fabric Based boot.

However, Red Hat say they only support SAN-based boot for Version 5.1 and above. Who is right?

Will HP support my storage/SAN-based boot issues if Red Hat does not? IS there a clear dividing line between what I would call Red Hat for, and what I can call upon HP to support?

R.
1 REPLY
Matti_Kurkela
Honored Contributor
Solution

Re: SAN Based boot from Red Hat 4

For any SAN operations, I would prefer RHEL 5 over RHEL 4, as the newer version seems to better integrate the basic tools and functionality required for SAN use. However, even RHEL 4 is certainly workable in SAN environment, but compared to RHEL 5 is certainly has some rough edges.

To boot an x86 system from SAN, you will need:

- a FibreChannel HBA that has appropriate boot firmware (firmware level must be compatible by both the Fabric and the Server)

- the HBA configured to boot from the fabric: as the BIOS of x86 systems is not SAN-aware, the HBA will emulate a SCSI card until native drivers of the OS can take control. A combination of HBA firmware settings and BIOS settings may be necessary to select the correct LUN to boot from.

- The kernel and initrd configured for SAN support (usually, this means correct boot parameters for the kernel and the FibreChannel driver included into the initrd file)


The basic problem: the BIOS usually chooses the IDE/SCSI/FC controller to boot from, if there are several possible controllers. After that, the default action is to boot from the first disk detected from that controller. Both the BIOS and the controller firmware may make changes to the disk presentation order at that point. If your SAN and/or HBA can guarantee that a certain disk will always be presented to the BIOS as "the first hard disk", the biggest problem is solved.

When configuring the kernel boot options to the bootloader, don't use an explicit disk device name for the root partition, like "root=/dev/sda2". Instead, use LVM (it will auto-detect all disks and find the root disk by VG/LV name) or LABEL= or UUID= identifiers for the root disk. This allows Linux to find the correct root disk even if the fabric configuration changes.

For a dividing line:

If the bootloader cannot load kernel and initrd, the issue is either with bootloader configuration (your responsibility to get it right for your environment) or BIOS or HBA firmware problem (hardware vendor; the SAN vendor might be able to help too).

If the bootloader can load the kernel and initrd, anything past that point is either configuration problems (your responsibility to get it right) or RedHat support issue. If we got that far, we *already know* that hardware works: it did successfully load the kernel and initrd, after all.

MK
MK