VMware Cloud Community
kjetil_t
Contributor
Contributor
Jump to solution

ESX3.5 SAN boot to EMC CX3_20

I have 2 HP C-Class with 3 DL685c in each. They all have a mezzanine card that is interconnected to each Brocade SAN switch inside the C-Class. They have each a ISL port til my two main DS-24 McDATA switches. This gives me two fabric with dom id 1-2-3 on each. One B-switch is subordinated and one is Princepal. The active zone is sendt from the DS-24

I have made 6 different boot lun for all my ESX3.5 installations on the cx3_20, with navisphere agent and QLA BIOS enabled. All ESX hosts is allso registered in Navisphere Mgr and has it`s own NOVI0XBOOT storagegroupe that it is a member off.

All of them are stabile with no ESX3.5 installation errors.

Now I have made a large VMFS3 LUN and want to add all my registered navisphere ESX host to use it, but I get a warrning! It`s about that this host is a member of another storage groupe and if I make it a member of more than one storage groupe, the first storage groupe that it is a member of can fail or get unsable?? ( it`s boot lun ) I know that this is a issue in Windows Host...but this is VMware.

Have I forgotten to set any settings in Navisphere mgr?

Can I just say YES and the linux navisphere agent fixes it any way?

Anyone out there running a ESX3.5 boot LUN storage groupe and a VMFS storage groupe configuration?

BR

KLP

Reply
0 Kudos
1 Solution

Accepted Solutions
DougBaer
Commander
Commander
Jump to solution

I am not currently doing this, but I have read about it on PowerLink...

Boot from SAN information:

• Configure the BIOS settings for the Fibre Channel HBA to select the CLARiiON LUN as the boot device.

• With ESX version 2.5, make sure that the boot LUN is /dev/sda and ID 0—the lowest-numbered LUN visible to the ESX Server. This is not necessary for ESX 3.x, since it uses the device UUID for LUN identification.

• The internal SCSI device (controller) must be disabled for the CLARiiON LUN to map as /dev/sda. Since the CLARiiON storage system consists of active/passive path configuration, the lowest-numbered path to the boot LUN must be the active path.

• For ESX 3.x, when installing the server software select the CLARiiON LUN from which the operating system will boot.

Also,

"For VMFS-3 volumes, they are identified by the Host LUN number. Hence, as a best practice for VMotion with VMFS volumes create a single storage group for all ESX Servers in a farm or cluster since LUNs may be assigned different Host LUN numbers if separate storage groups are created. For additional information, see EMC Knowledgebase cases emc151686 and emc153719."

That said, for boot from SAN, the recommendation I have seen is to create a storage group PER ESX HOST and add the LUNs to each storage group (this is additional management overhead and you need to be careful to add the LUNs in the SAME ORDER to each storage group else your LUN numbers won't match per host (as above).

This is much the same way it is recommended to configure ESX hosts/Clariion storage for a Cluster-across-boxes configuration.

Doug

Doug Baer, Solution Architect, Advanced Services, Broadcom | VCDX #019, vExpert 2012-23

View solution in original post

Reply
0 Kudos
1 Reply
DougBaer
Commander
Commander
Jump to solution

I am not currently doing this, but I have read about it on PowerLink...

Boot from SAN information:

• Configure the BIOS settings for the Fibre Channel HBA to select the CLARiiON LUN as the boot device.

• With ESX version 2.5, make sure that the boot LUN is /dev/sda and ID 0—the lowest-numbered LUN visible to the ESX Server. This is not necessary for ESX 3.x, since it uses the device UUID for LUN identification.

• The internal SCSI device (controller) must be disabled for the CLARiiON LUN to map as /dev/sda. Since the CLARiiON storage system consists of active/passive path configuration, the lowest-numbered path to the boot LUN must be the active path.

• For ESX 3.x, when installing the server software select the CLARiiON LUN from which the operating system will boot.

Also,

"For VMFS-3 volumes, they are identified by the Host LUN number. Hence, as a best practice for VMotion with VMFS volumes create a single storage group for all ESX Servers in a farm or cluster since LUNs may be assigned different Host LUN numbers if separate storage groups are created. For additional information, see EMC Knowledgebase cases emc151686 and emc153719."

That said, for boot from SAN, the recommendation I have seen is to create a storage group PER ESX HOST and add the LUNs to each storage group (this is additional management overhead and you need to be careful to add the LUNs in the SAME ORDER to each storage group else your LUN numbers won't match per host (as above).

This is much the same way it is recommended to configure ESX hosts/Clariion storage for a Cluster-across-boxes configuration.

Doug

Doug Baer, Solution Architect, Advanced Services, Broadcom | VCDX #019, vExpert 2012-23
Reply
0 Kudos