Aaron Delp’s BladeVault.info

I ran across this one a few weeks ago and I wanted to share it. If you are using the BNT (Nortel) switch modules in the IBM BladeCenters and booting iSCSI to various OS’s, you might run into problems using the default values on the Nortel switch. We were seeing our LUN’s intermittently not attach at boot and/or crash loading up. This happened with Windows, Linux, and VMWare. After some searching I came up with this link to turn OFF autonegotiation. This setting used to be off but in the latest BNT firmwares, the default value was changed to ON. If you switch it back to off, you are able to boot everything fine.

This has been out a few weeks but it just came to my attention. IBM recently announced a Retain tip that the IBM BladeCenter Optical Passthru Module needs to be replaced because it will fail after 511 days of activity. This ECA (Engineering Change Announcement) is considered MANDATORY. Please see this link for more information and how to submit a form to have IBM replace the module:

IBM Retain Tip on faulty OPM

I found this out while configuring some 10G Ethernet cards for a customer recently.  Be careful who makes your 10G cards.  It turns out the NetXen 10G card (OEMed to HP, IBM and Others) has a hard limitation of only being able to address 32GB of system memory in the box.  If the system has more than 32GB of memory, the card will start dropping packets.  My sources tell me there will not be a firmware fix for this at this time.

To say this was a surprise to me is an understatement!  I have never seen a card with a limitation based on memory before.  IBM has pulled support for the card on the 3850 M2 model even though it is still a valid configuration in the configuration tools.  I haven’t had a chance to check the DL580 but be careful if you are considering either of these boxes with the 10G card.  Right now you will have to go 3rd party and your level of support may vary.

Link to IBM Technical Tip

Link to HP Technical Tip

This is an update to this article on the IBM HS21 BIOS 1.07B.

IBM has confirmed to me that this is a problem that should be addressed in another BIOS patch. The only OS that seems to be affected is Red Hat. According to IBM support, it turns out that the BIOS looks at the stepping levels of the chips and if the second CPU level is different than the fist CPU level, it will “mask” them to the OS so this problem will be avoided.

For some reason, there is a bug in the code as of 1.07B that this doesn’t happen. It has been confirmed and should be corrected shortly.

It appears we have found a possible bug in the Deploy from Template Command in ESX 3.5. When you create a Windows Server based template and then try to deploy directly into an Active Directory with customization, the new system will get an error that a service failed to start when the machine is launched. This is because the VMWare BootRun service is not removing itself properly after deployment. This does not happen with deployments into a workgroup.

If you aren’t familiar with the BootRun service, this service will make all of the customizations after the sysprep work is complete during the deployment. You usually never see it because it runs on the first boot, makes the changes, and then removes itself from the machine.

In this case, the files are removed but the service entry is still there, hence the error that it can’t start up. VMWare has confirmed this to be a problem and they are investigating.

This article has been updated here. 

This one is a little dated but I wanted to share in case you are seeing this problem in the field. Back in November IBM released version 1.07 BIOS for the HS21 Blades. With certain types of processors, you would see a 199 (Processor Mismatch) error on the next boot if two processors were installed in the machine. This would happen even if the stepping levels were matched. I brought this to IBM’s attention and BIOS 1.07b was released on Dec 21, 2007.

This BIOS fixes the problem but we have found an instance where loading Redhat Workstation 4, Update 3 (SeverProven OS by the way) will cause a kernel panic during installation if the stepping levels of the OS are mismatched and the highest stepping level is in CPU slot 0. I don’t know if other versions of Red Hat are affected. The work around for now is to swap the lowest stepping level into slot 0 and reinstall the OS. It has been years since we’ve had to worry about stepping levels so hopefully IBM is working on a fix. I spoke to support a few days ago and they were passing this along to the BIOS team. I’ll post here with updates.