UDA 1.4 and Hiding SAN LUNs

Hiding SAN LUNs

I’ve been experimenting with the “hardware” options enabled in the UDA’s Kickstart Configurator for ESX. Unfortunately,

this part of the UDA doesn’t seem to work. I’ve spent some hours trying to make it work but to no avail. I’m hoping once Carl has access to ESX servers then he will be able to make it work.

In the interim, I have worked out kickstart method which will do the job just as well.

On of the common worries about scripted installations is the concern that our script install might re-partition the wrong LUN. The common recommendation is to disconnect the SAN cables prior to an installation or request the Storage team to mask away the SAN LUNS presented to an ESX host. These options are not especially practical if you are long distance away from your ESX host. Raising a change management request may take sometime, and is fraught with the danger of breaking the existing LUN masking configuration. It is possible from the kickstart file to instruct the Anaconda installer to ignore certain disks.  The only difficulty with this method is listing all the disks the installer shouldn’t see.

For example on a HP server where I would be installing to local LUN, I can add the following line to the kickstart file:

# Ignore these SAN LUNs
ignoredisk –drives=sda,sdb,sdc,sdd,sde,sdf,sdg,sdh,sdi,sdj,sdk

# Bootloader options
bootloader –location=mbr –driveorder=cciss/c0d0

I knew when to stop listing sd devices by using the ESX command esxcfg-vmhbadevs on an existing HP server which has the same LUNs presented to it:

vmhba0:0:0           /dev/cciss/c0d0
vmhba1:0:0           /dev/sda
vmhba1:0:1           /dev/sdb
vmhba1:0:2           /dev/sdc
vmhba1:0:3           /dev/sdd
vmhba1:0:4           /dev/sde
vmhba1:0:5           /dev/sdf
vmhba1:0:6           /dev/sdg
vmhba1:0:7           /dev/sdh
vmhba1:0:8           /dev/sdi
vmhba1:0:9           /dev/sdj
vmhba1:0:10         /dev/sdk

Where an ESX host returns a /dev/sdn name it can be harder to know if /dev/sda is local storage or if /dev/sdj is local storage. It depends on very much how Anaconda interrogates PCI bus enumerates storage devices and then allocates the /dev/sd identity.

On my Dell servers the ignoredisk line is different. This is because /dev/sda is the first local disk, and which makes /dev/sdb the first SAN LUN. So in the kickstart file I use this syntax for the ignoredisks entry:

# Ignore these SAN LUNs
ignoredisk –drives=sdb,sdc,sdd,sde,sdf,sdg,sdh,sdi,sdj,sdk,sdl

# Bootloader options
bootloader –location=mbr –driveorder=sda

I check the device names by listing the existing device names on a similar server with the ESX command:

esxcfg-vmhbadevs

This return the following device names for my Dell ESX host:

vmhba0:0:0           /dev/sda
vmhba1:0:0           /dev/sdb
vmhba1:0:1           /dev/sdc
vmhba1:0:2           /dev/sdd
vmhba1:0:3           /dev/sde
vmhba1:0:4           /dev/sdf
vmhba1:0:5           /dev/sdg
vmhba1:0:6           /dev/sdh
vmhba1:0:7           /dev/sdi
vmhba1:0:8           /dev/sdj
vmhba1:0:9          /dev/sdk
vmhba1:0:10        /dev/sdl

As you can see the Dell Server connected to the same SAN with the same number of LUNs appears to have one extra disk (/dev/sdl). This because its first local LUN is /dev/sda, whereas the first local disk of the HP server is /cciss/c0d0.

Note:
If you want to know more about the ignoredisk option it is documented on Redhat’s website here:

http://kbase.redhat.com/faq/FAQ_79_8927.shtm

Note:
There is one other reliable “soft” approach to stopping SAN LUNs from being visible and that by disabling them in the BIOS of the ESX host. Personally, I don’t like this method so much as it means I have to manually disable and enable the HBA every time I deploy ESX. But you might find it more reliable than the method above. Others on the VMware Forums have experimented with disabling devices using the kickstart options of nostorage and noprobe. I have investigated these methods and found it impossible to make the installer reliably load the right drivers for the kickstart process to work

This was first published in June 2007

Dig deeper on VMware Resources

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchServerVirtualization

SearchVirtualDesktop

SearchDataCenter

SearchCloudComputing

Close