ESX boot from SAN – design limitations
September 26th, 2007 | 
Author: While working with a SMB customer this week I came across an unexpected problem. The customer wants to boot all of his ESX servers from the SAN as well as the VC2 server and a handful of other physical servers. They have an IBM Bladecenter and ordered several new HS21 blades without hard drives. So, after spending a day with the storage admin and developing the best array, LUN, and host group design we started to build the solution. Turns out that the customer’s SAN controller is a DS4300 turbo and is limited to a max of 8 partitions. (IBM calls host groups partitions for some reason.)
The host groups were consolidated as follows:
- ESX3 boot
- ESX4 boot
- ESX5 boot
- VC2 boot
- ESXRanger boot
- SAP boot
- Content Manager boot
- DC1 boot
- App1 boot
- VMFS LUNs for all ESX servers
Not to mention the customer already had 4 partitions (host groups) in use. 1 of the 3 was the VMFS LUNs (#10 above) already used for their first three ESX blades which had local storage and did not boot from SAN. This design pushed them to a total of 13 host groups needed. What’s really ironic to me is that there was such focus on keeping them from having to order another blade chassis that the partitions licensing was never checked!
Now the customer has decided to order a DS4500 controller and swap it out. By default the DS4500 comes with 16 partition licenses and can be licensed up to 64. End result is that the project has been put on hold for a few weeks while the controller is upgraded.
Personally, very rarely do I even suggest a company boot their ESX servers from SAN. The install is so quick and easy and the there is always a good reason to use the local storage – admin VMs or VAppliances(s), VMFS dedicated to backups, etc. I’ve never come across it before, but now I have another reason to not boot from SAN!
Related Posts
Posted in 
Tags: -
Kirsten Dextraze
-
Tracie Petroski
