This post is more than 5 years old
46 Posts
0
6019
Booting from SAN via Qlogic Cards and C200 Servers on VMAX
I am trying to get a c200 Cisco UCS blade server to boot from SAN via a Qlogic HBA
The zoning and masking shows as connected and a single path is all that has been configured, we have done all the steps in the configuration guide and it see the disk but when we try to load any type of operating system it fails to find a disk
We have even removed the mezzanie card from the C200 to try and get this to work, has anybody seen a similiar issue whereby the server sees the disk in the hba settings and setup but will not let them load a operating system and does not see the disk when we try to load an operating system to the configured disk
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1448
http://networkadminkb.com/KB/a26/how-to-boot-from-san.aspx
http://www.manualslib.com/manual/403437/Hewlett-Packard-Integrity-Bl890c-I2-Server.html?page=22
michael_churchi
46 Posts
0
November 27th, 2013 02:00
We have managed to get a bootable version of Red hat Linux working on this server now
We had to update form the supported level Qlogic drivers to the latest versions and then get updated ISO images from Plate spin to fix the ongoing issue. The firmware even though in the supported matrix just did not work
We have been left with a bootable image which now however suffers from kernal panic on boot which we are looking at Plate spin to fix etc
Normal case when in doubt update the drivers
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
0
November 19th, 2013 12:00
what does your cisco ucs boot policy look like, did you configure your FAs as your primary, secondary. What did you set your LUN Id to (0 or 1) ?
michael_churchi
46 Posts
0
November 20th, 2013 04:00
This is a standalone C200 Cisco Server so does not effectively have a UCS boot policy as it is not being managed through the Interconnects or UCS manager
This is in effect the same as any other physical server so boot from SAN should not be the issue
We have tried updating our firmware on the Qlogic cards and this has geiven us some progress I have also manually altered the LUn ID to LUN ID 0 although this is not something that can be done via the Unisphere for VMAX GUI
You have to manually add the device through the command line to set a LUN 0 ID and this has been done
We have got it to the stage whereby the qlogic bios sees a single disk on LUN 0 and it can if we give it a boot image from another machine will boot from SAN
It is during the windows install process whereby it looks for a place to put the OS that it reports no devices
We are trying to load Linux from an ISO image onmto a single disk seen through one path with a LUN ID of zero
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
0
November 21st, 2013 05:00
i am curious about one thing, do you have ACLX devices mapped to the same FAs where your host is connected to ? The reason i ask is because when i use UCS boot profile, i have to specify my boot LUN as address 1, not 0 ...because 0 is my ACLX device. Is there a place in the Qlogic Bios where you can experiment with that ?
michael_churchi
46 Posts
0
November 21st, 2013 07:00
Yes we had the ACLX available via the FAs we were using so could not orginally mask out as LUN 0 as the ACLX takes this as the first device to be discovered
We got round this by effectively adding two devices to the OS boot storage group and then removing the boot device and manually re-adding it back into the storage group via the command line which lets you then select LUN 0 and apply this
It really makes no difference as all our UCS B Series servers are set to have a boot policy to use LUN 1 as the boot device and all these work with the same type of cards
We added a bootable image to the host via LUN ID 2 and after making the normal boot selection in the Qlogic FAST Util to piont to this the server actually booted, it eventually blue screened due to driver incompatibility betwen the server we took the boot image from and the hardware we are using but proved boot from SAN
The issue seem to be when the actual OS install program get to the stage of discovering the devices we know are available in terms of the FAST util setting and the view connections on the Unisphere for VMAX
It just does not seem to find any and returns no device found so has nowhere to load the OS
We are presently looking to get a new ISO image cut and use platespin to load this image onto the server boot device and see if after we have the image on the disk it will boot
The plan all along is to migrate existing reg hat linux host OS via plate spin onto the disk to create the boot image etc. Buit we had to prove boot from SAN would work with this combination
The Drivers for the model of card we were using QLE2462 Driver level was a couple down from the latest and in the support matrix but we only got anywhere with it actually seeing the Qlogic card properly when we updated to the very latest firmaware driver
michael_churchi
46 Posts
0
November 21st, 2013 08:00
We could always get to an ISO image we tried several different sorts of OS from Red hat to Windowsacroos various versions to just get any OS to reconise the device, we have got past the problem with the Qlogic card not being picked up as a boot path and now it is just that any of the OS we try to load do not get past the piont whereby they should give you the option to partition the disks and load the OS
We see the disk on LUN 0 and can setup the boot bios on a single primary card to see this and it see the disk on boot and reconises that it is there it just doesn not find it whe nwe load the OS, the OS loads into RAM then during device discovery just does not pick up any devices
Yet we can adda bootable image from another server and it will boot
Everything look good from the SAN end and from the piont of view now of the Qlogic setup and bios just does not load any of the ISO images we have
We have tried bot hTHin and thick devices etc but will not get past a certain piont on loading the OS
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
0
November 21st, 2013 08:00
can you use UCS console/virtual device and point to a regular redhat ISO install media ? QLE drives should be built-in so they should be loaded at boot time and see your boot LUN. Or did you get past issue already ?
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
0
November 27th, 2013 06:00
thank you for the update
michael_churchi
46 Posts
0
December 2nd, 2013 05:00
We have gone back and set the required d setting on Initiator port groups to over ride the global setting and reset the LUN to LUN 0 manually but it still did not work or get us past the kernal panic
We may have made progress by simply setting the boot switches to boot from an older kernal with just the linux rescue setting as it seem to have booted twice now we are loking at 2.6.9-99 instead off 2.6.9-100 anything earlier than 100 failed to boot with the LUN ID is higher than supported by HBA error
So this could be a combination between resetting the LUN 0 and port setting or running the linux rescue without changing anything in between boot attempts
We will now need to systematically check the kernal versions to see which boot and which do not
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
0
December 2nd, 2013 09:00
what flavor of Linux is it ? I am booting a bunch of RHEL 6.x and have not had to worry about kernel version.
michael_churchi
46 Posts
0
December 3rd, 2013 07:00
We are trying to boot redhat linux version 2.6.9-100
We can boot version 2.6.9-55 and we can get past the kernal panic for redhat version 2.6.9-89 but it seems to hang loading modules not much of a linux guy so this is what I am getting told
But if we go to 2.6.9-100 we cannot get past the kernal panic
We are using qlogic cards with the latest driver as of september 2013
It will boot but not the version we want to have
Suspect it is a linux/platespin issue with drivers as the drivers are built into the OS as far as I know but cannot get a working version of 2.6.9-100
michael_churchi
46 Posts
0
December 11th, 2013 07:00
Ok we have finally got this working or rather the Server team have
The key piont of the fix to get a booting version were
- - Updates to /etc/modprobe.conf - Modprobe.conf was changed to add " alias scsi_hostadapter1 qla2xxx"
-
- qla2xxx.ko was missing from /lib/modules/2.6.9-100.ELsmp/kernel/drivers/scsi/qla2xxx/ - we copied across from another host with same kernel version
- - depmod command on kernel directory to update all the symbols and map files - depmod 2.6.9-100.ELsmp
- - mkinitrd command to update the boot image file - mkinitrd -v -f /boot/initrd-2.6.9-100.ELsmp.img 2.6.9-100.ELsmp
It is possible that just the mkinitrd fixed it, but these are the steps as taken by us. All above steps were completed within a historic kernel available through GRUB boot options.
This has left us with a booting server, but only reaches the correct runlevel if the powerpath modprobe.pp.conf is not included in modprobe.conf (commented out)