Boot disk created on SAN disk instead of local disk

[cwilliams_2]

When we load the OS using RDP on BL25p servers with a fiber card the server boot partition is created to the SAN storage instead of the local disk. This has destroyed data that is on the SAN storage. The only way around it so far is to remove the fiber card before attempting to reload the OS. Any tips on why is this happening?

[Jimmy Vance]

What OS?

I don't do much with RDP, but if the OS is Red Hat, you can specify what disk to use in your kickstart file. SuSE can be done the same way in the autoyast file.
Most Linux installers will use /dev/sda before using /dev/cciss/c0d0

I'll have to look in some of my old files to give you some examples

[cwilliams_2]

It's the Windows OS. We've had several builds overwrite the SAN connected data with a boot disk. The boot order has the array controller listed first.

[James ~ Happy Dude · Accepted solution]

Hello William,

If you are deploying Windows operating system, and two paths are set up to the
LUN (through both HBAs on a blade, for example), there could be issues.

Windows must be installed in a single path configuration.
To resolve the issue, either remove one of the HBA cables, or set up the SAN switch
zoning to allow access to the LUN from only the first HBA and one array controller
port. After Windows is installed, install the multipathing software, and enable the
second HBA to access the LUN.

Regards,
James.

[cwilliams_2]

Thank you. That sounds like what's happening. We are rebuilding an existing server and the two paths are already zoned to the data.

[Jimmy Vance]

I mainly do Linux installs but I'll check with the guys that do Windows and RDP and let you know thier response

[cwilliams_2]

Thinking about this more. It's a manual process to go tell our storage guy to rezone the LUNs. Is there a command line that would allow us to disable the HBA at the beginning of the load process. We are using blades (p-class and c-class).

[Jimmy Vance]

I don't think it's a mulitpath issue. What you normally see there is multiple drives pointing to the same LUN.

[cwilliams_2]

That's true, you would see the same drive twice without MPIO. Wonder why it would load the OS on it if it see's the same drive twice? It's like it's seeing the SAN disk as the first disk, so that's what it sets as the boot disk and then loads the OS. I appreciate all of your help.

[James ~ Happy Dude]

Hello William,

From the Deployment Server, run a Windows scripted install job on the target
system. Optionally, configure the HBA, and install and configure StorageWorks Secure
Path on the target system. On the target system, use the SAN management software for your specific RAID array to create LUNs and present them to the target system according to the recommended instructions. Use the Disk Administrator utility to rescan for the new disks, and then partition, assign drive letters to, and format the disks.

Regards,
James.

[cwilliams_2]

Wouldn't these things be done after the OS is loaded? Any way to disable the HBA through RDP before the OS loads so it doesn't create a boot partition on the LUN?

[James ~ Happy Dude]

Those configuration steps are required to deploy an operating system to a server with
a QLogic or Emulex FC HBA attached to an HP StorageWorks SAN.(its before loading OS- Pre-requisites & not after)

Disabling the HBA BIOS before deployment can tried.

However, I am not aware of a Script / Command to do this.

Regards,
James.

[aboerup]

I have run into this problem myself, luckily it was during prep & deploy stage so nothing was lost.

The main problem is RapiDeploy used in the HP RDP kit does not do a very good detection of HBAs (both FC and SAS/SCSI) and will just blindly write to whatever one has a drive that it picks first.

Perhaps the easiest thing to do in this situation is to disconnect your fiber-channel cables to the back of your blade chassis, which will force the server to only see the internally connected drives as an available disk. RDP should then write your OS deployment job strictly to that disk. Once you are done you can reconnect the cables and then everything will be happy.

When I do this I just use the C-Class Onboard Administrator to power off the fiber-channel switches, I don't believe you have an easy remote option to do this on the P-Class, its been a few months since I checked for one.

Best of luck!

[Jimmy Vance]

It's not really an RDP issue, it's the way the host OS sees the devices and decides on which ones it wants to use first.

As I said before, I'm not sure how Windows handles it as I mainly work with Linux. Under Linux the installer tries to use /dev/sda (the fibre stuff) before it will use /dev/cciss/c0d0 (the Smart Array controller)