Aaron Delp’s BladeVault

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.

I saw this article over at xAnalysis and after some digging I came up with the new CPM Product Announcement . The big difference I can see is the new product no longer requires "octopus" cables. The announcement states the product will have 14 external network connections to match one:one the internal blade connections. I would love to see a picture on this sucker, I can’t believe they managed to get that many ports on a module.

UPDATE: Simon was nice enough to leave a comment with a link to the product picture .  That is an impressive use of real estate!

UPDATE#2: I have learned the ICPM also supports Serial Over LAN (SOL) and KVM.  Also, the ports will switch to 100MB speed instead of the previous requirement for 1GB.

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 have come to the conclusion that SAN Booting VMWare ESX is just a bad idea in production. By production, I mean in an environment where you have at least two redundant paths to your storage, and the machines are intended for 24/7 up time.

I admit I am talking more about iSCSI than FC because I haven’t investigated FC as much. What do you think? I normally would post a bunch of links to support my theory and I will be happy to do so if there is interest (In other words, I can’t find them right now but I wanted to post this).

Why would you not want to SAN Boot ESX? Isn’t that the rage? Yes, yes it is.

If you SAN booted it, wouldn’t you be able to replicate the boot LUNs to another site and have all in one DR? Wouldn’t you get deduplication of the ESX LUN, snapshots, and all the other great things that make SANs the end all be all of storage? Yes, yes you would.

So, it you are gaining all these great advantages, why not do it? One simple reason, local fail over. From what I have seen and heard, ESX just really doesn’t have the multi-path code in place today to handle having the connection to the boot LUN ripped out from under it. I would think the FC is more robust but I haven’t tested it. If you are doing this and have tested it, please let me know!

Anybody get the Portal game reference?  If you are a gamer and you’ve been under a rock, look it up and go play Portal!  Best ending of a game ever.

So, I’m here but I have simply been too busy with work and some personal issues to post.  You probably won’t see anything until this weekend.  I have some really good information on the IBM 3850/3950 and the HP DL580 regarding back plane bandwidth constraints and recommendations from some customer research.  I have also been living in VMWare VDM (Virtual Desktop Manager) product for the last few weeks as well as some impressions about the VMWare Update Manager Product.  More to come…  But I’m still alive…