Ok you lost/confused me there at the end. You stated that you followed our directions and went as far as installing an OS to that LUN then you changed the boot order and had issues. WHY did you change the boot order again ?? You should have a working boot policy and local disk policy implemented that allowed you to boot up initially, be seen in flogi database, able to view the LUN as a remote device to install to when you boot an .iso image on virtual media. Then you install the OS and reboot the server and the ONLY thing you should now change is unchecking the "Map" checkbox if needed for mapping the virtual media. You made a change that broke the correct configuration, why and what was it. As explained before you shouldnt' use "diskless" boot with boot from san for several reasons most of which I dont agree with so dont get me going on here, offlice would be better. Your boot policy shouldn't ever change. I like to create a "SAN-BOOT" policy boot order policy to implement, using vHBA templates I create prior, with known working SAN Boot Targets onfigured in all 4 slots, vHBA0 Primary and Secondary as PRIMARY SAN Target, and vHBA1 as SECONDARY SAN Target will also have a Pri and Secondary SAN Target WWN configured there to ensure redundancy of pri and sec on both the A and B Fabrics. So that covered local disk policy is important as SAN LUN is sees as a disk your policy cannot contain "No Local Storage" which is contained in the "diskless" policy in UCSM by default. I have seen this actually power off or at least disable adapters on MB. Those devices arent manageble via the BIOS natively or via UCSM BIOS policy, but you can apply that and watch the FSM and see it happen, and then in the BIOS you will no longer see any hdd's that may have been attached be visible nor will hdd boot be available in BIOS boot screen, so not good. If there are disks installed create a SAN with "any configuration" or use the any config for now. Again you should eject your local hard drives but if using ESXi 4.1 U1 you can leave them. For your level in SAN boot and UCS I would certainly EJECT them for now, Boot it up with all this discussed, see the LUN, ensure LUN is ZERO and install to LUN with .iso as virutal media. by ensuring your boot order has cd-rom first always, then SAN via local storage adapter, then vHBA's and targets discussed prior. Dont allow local hdd devices after the SAN. Install OS, reboot and it should boot from SAN if followed as is. Put an IP address on the proper interface and vlan # if needed you can access ESXi with vcenter. Now log into that IP and see what is viewable using the Storage and Storage Adapters screens and tools in ESXi on that blade with those SAN settings you are aware of for that new zone. Add another LUN to that zone and refresh the storage and make sure you can see it and it's the proper size and read/write acces is there. Then before moving on, I would do this exact process on a 2nd blade and boot it up the same. Ensure that the LUN 0 boot for this first blade is NOT viewable by the 2nd blade you're testing with. After getting this zoned, 2nd biggest issue I see is masking it off properly to LUN 0 for the host, and then ensuring that other hosts also see ONLY their respective LUN 0, NOT the other one or you will overwrite the data and boot sector, or corrupt it at the very least. If 2nd one doesnt see the LUN 0 bootable to the first, you are good to go, emulate for each going forward. When 2nd one is running ESXi again using client or vcenter make sure 2nd one can see the same LUN as the first one for shared storage among them both, with this you have covered all bases needed for basic ESXi booting from SAN and shared storage for VM's and vmotion capabilities.
SAME working SAN boot policy and local disk policies can be applied to SP template to spin many off, or at least included in new Service Profiles for same type san boot machines, same targets and all, will work fine.
ALSO so now all this is done, and ESXi is 4.1 Update 1 or better, you can power down the blade and insert the hard drives again ejected during san boot install. A fix in update 1 allows local storage while booting from san, but having them ejected during install even if installing 4.1 U1 ensure smoother boot when not sure on setup and san zoning by removing many variables. Adding back later like I said here nsures OS brings them properly also with SAN targets having lower numbers, hdd's higher which always matters at the PCIe level where those boot order preferences actually dont matter as you'll see per the notes on the UCSM page when viewing, PCIe order rules.
Good Luck and let me know.
