vsphere 5 on b230

[cy-harrild]

We've got two sites each with it's own UCS.

Site A - Fully operational - local data centre

7 x b200 m2 - Oracle Enterprise Linux RAC 11g w/ RDBMS

2 x b230 m1 - vSphere 5

Site B - Build in progress - remote data centre

7 x b200 m2 - Oracle Enterprise Linux RAC 11g with RDBMS

2 x b230 m1 - vSphere 5 (in progress)

The Site A b230's installed without problem and are fully functional

The Site B b230's however boot from the install iso (the same that was used for Site A) and appear to install correctly to the assigned boot LUN. On reboot however all i get is "Reboot and Select proper boot device or Insert Boot Media in select Boot device and press a key"

The service profiles, aside from the VLAN's assigned to the vnic's and the vhba's, are identical. Both the boot and first datastore are presented during the install but the boot lun, being only 12GB, is what is being install to and it is LUN 0 for the host on the EMC VNX5500.

Both UCS' have the same codebase, 2.0(1m), and were upgraded with the identical progression (1.3 to 1.4(1j) to 1.4(3i) to 2.0(1m)) to ensure they were identical (they weren't installed in parallel due to environmental issues)

FC Upstream for Site A is a Brocade Director 48K

FC Upstream for Site B is a pair of MDS9148's. Zoning is correct and is operational. Cisco Data Centre Network Manager (DCNM) has been deployed and is monitoring both the MDS' and the Site B UCS.

Has anyone seen this behaviour before? It's got me baffled.

[mipetrin]

Hi Cy,

Helped a customer with a similar issue last week.

https://supportforums.cisco.com/thread/2119100?tstart=0

If you're zoning and everything else looks good, chances are it is one of the following:

1) Depending on if the array is active/active or  active/passive, it is also important to verify which storage processor  currently owns the LUN and ensure that the vHBA communication is hitting  the appropriate storage processor

2) Also ensure that you have correctly configured the order of  your Boot from SAN targets (primary vHBA - primary target, primary vHBA - secondary target, secondary  vHBA - primary target, secondary  vHBA - secondary target). The order in which it attempts to boot  from the LUN is important.

Have a look over these two items and ensure that everything is correct.

Let me know the result and we can go from there.

Cheers,

Michael

[cy-harrild]

Michael,

Checked the whole storage thing, we had wound it down to have a single path (which had a single initiator and single storage target) in it, but had no effect. Basically we ran through all the lessons learnt while deploying Oracle Enterprise Linux on UCS (like order of the Boot targets) to no avail.

This led me to roll the firmware of the adapter back to 1.4.3i, which seemed to work but it's a step back for us. Upon looking a bit deeper into the problem I saw that 2.0.1m has got a deferral notice, and most the bugs were against ESX and B230's. So I've upgraded to 2.0.1t on the FI and UCSM, applied 2.0.1t firmware to the FC adapter and it works beautifully.

As we are trying to keep both UCS' at the same codebase (as they are designed for BCP not DR), Site A will now get an upgrade (and with any luck before christmas).

Thanks for your help.

Cy