ESX Boot from SAN and Storage Groups

Way we go about it is on UCS creating a profile for each ESXi host and on each profile i point the particular esxi host assign to the profile to boot from an specific LUN ID.

on the VNX is simple.

1 storage group

all boot LUNS and datastore LUNS assign to that storage group

all esxi host are member of that storage group.

all hosts that way see all datastores and vmotion is a cake and the boot is being handle at the UCS level pointing the profile to boot from an specific lun id for each host.

caviat1 : when adding the LUNS to the storage group do it 1 by 1 and put the HLU above 16. I have all my host above 16 and control the boot at the UCS as previously explained.

caviat2: if on vnx you are also doing file: you need to add a 1gb temp LUN and give HLU = 0.

i hope i am being suficiently clear... sorry if it sounds confusing

. Unfortunately you can only have a host in a single Storage Group at any one time,

isn't this other way around! u can have mutliple hosts in one storage group; But a given host can only be part of a single storage group. That is what "Renaton" said too

renaton4175, when you do boot from SAN, you can't let the boot LUN be accessed by multiple hosts. (That is what happens when you add multiple hosts into a single storage group).

The config suggested by Craig, is the recommended one. Manage LUN in multiple hosts on multiple storage Groups is not as hard as it sounds. You can control that on a per LUN basis. (right click the LUN).

But you can still use VSI to help delivery new LUNs to the VMware. This is the easiest way to do that! With a single storage groups or multiple storage groups

RRR thanks for that,  I can see how that would work as well,  suppose it's just a case of working out whether the cost of an HBA x the number of hosts is greater or less than the cost of the management effort in managing seperate storage groups for that number of hosts.  I can imagine in an environment with a lot of hosts the HBA option would be a non-starter due to the CAPEX costs,  but it is indeed another workaround to the problem.  Thanks

I think I see what Renaton is saying here and this might be UCS specific but I think it would probably work in all configurations where you can boot a blade or server from a specific LUN ID.

Assign LUN ID's 0 - 31 to be boot LUNs and on each ESXi host configure the boot LUN accordingly,  e.g server ESX01 boots from LUN 0 where as server ESX06 boots from LUN 5 and so on all the way up until server ESX32 boots from LUN 31.

LUNS 32 - 255 could be used for datastore LUNs and all could co-exist in the same storage group quite happily.  Your only real management task would be to manage the boot LUN configuration on the host so it matches the right boot LUN in the Storage Group, which in truth is a lot easier than managing separate storage groups per host.

Doe that sound sensible? have I picked that up right?

Craig Stewart

vSpecialist Technical UK/I

www.virtualpro.co.uk

Quite a while ago I encoutered an IBM xseries 346 or something with an onboard RAID controller and I added 2 Emulex HBAs. The server was supposed to boot from internal disks, but I couldn't get the HBAs to work and the only option was to disable the onboard RAID controller. And now both HBAs worked fine! The error I got was about not having enough resources to enable both the onboard controller and the 2 HBAs. So I added a third HBA and I got that to work!

So to boot from I used the 3rd HBA, which wwpn was in a separate storage group with only the boot LUN and the other storage group was for all datastores and was shared by all ESX hosts in that cluster.

It works like a charm, but you'd have to buy an extra HBA for each server.

The other option is maintain storage groups for each server. Make sure you keep all HLUs identical, so datastore x is on LUN y for all servers.

Since nobody mentioned it I thought it was worth sharing my experience

FYI...You can have Hosts in multiple Storage Groups.  The limitation is with the Host's (v)HBAs.  The (v)HBAs can only belong to 1 Storage Group.  Our config has 4 vHBAs & 8 logical paths for each ESXi server.

We setup a Boot LUN Storage Group for each ESXi server.  That helps with scripting out the OS installs specially when we initially zone only a single path to the Boot LUN.  After the OS is installed, we finish the zoning for all paths.  We then setup a 2nd Storage Group adding all the ESXi cluster nodes and all the shared Datastore LUNs.

To achieve Hosts in multiple SGs, we click on the 'Advanced' button under the 'Hosts' tab in the Storage Group and select only the vHBAs needed for the Boot & vHBAs needed for the Cluster Datastores.

I guess I’m confused on what your definition of a Unisphere registered Host.  A registered Host can have different HBAs in different Storage Groups.

I have 4 vHBAs zoned to 8 logical paths and 8 registered initiators.  If all 8 initiators are registered to the same host and you add a Host to Storage Group in Unisphere, all 8 initiators are automatically selected because they belong to the same Host.

You can verify this by clicking on the ‘Advance’ button under the ‘Hosts’ tab within the Storage Group.  It will show that all 8 registered initiators are selected.

Unselect the HBAs you want to assign to a different Storage Group.  Create a 2^nd Storage Group and assign the same host to the new Storage Group.  Click on the ‘Advanced’ and it will show which of the Host’s HBAs belong to this new Storage Group as seen in the screen print below:

It is the same Host that has its HBAs divided between 2 different Storage Groups.  Again, a Host’s HBA/Initiator cannot belong to 2 different Storage Groups but the Host itself can.

it's still not one host in multiple storage groups as far as Unisphere registration is concerned.

are you saying that you have vh-clpoc-c1-04 connected to two different storage groups ? I can see the 4 bottom WWNs assigned to that host name. What about the top 4 WWNs ..what host name are they assigned to ?

You have to de-register all 8 initiators since all 8 of them were registered under one hostname. Then, manually register 4 of the initiators but give it a different host name (i.e. vh-clpoc-c1-04-boot). Put that host in the BFS storage group. Now register the remaining 4 initiators and give it a different name from above (i.e. vh-clpoc-c1-04 or vh-clpoc-c1-04-data). You are all set.

yup Works like a charm! Did it in 2005 for the first time. 1 HBA to boot from (SAN) and 2 others for shared storage

The good old days when you had to submit an rpq to get that done

hahaha, it worked without an rpq