This is going to be a quite long series of posts, so I’d better make this introduction as short and compact as possible. Here is a Q/A approach, just pick up the part you are interested in, and then jump straight to the first vendor in our series.

Why I decided to start this series?

Everyone already knows the revolution the blades had brought to our industry. I’m not going to repeat here what you already know. I’m not going also to promote the blades over the traditional rack servers, or try to answer the eternity question: “scale up or scale out?”. You might have already made you decision to go with blades, or still considering that, in both cases this series should help you to take your next step. My main and only focus here is vSphere. I’ll never try to promote a vendor over another, and I will never try to influence your decision to go with a specific design. Go to the next Q/A to see how can you benefit from this series, or at least how I think you might do.

Who might be interested in this series?

• Consultants or Customers: if you want to have an over whole idea on designing and/or implementing vSphere on specific blade vendors.
• VMware partners: if you are a partner, you may find this series useful to support your presentations to customers. I’ve seen many partners who can talk fluently about their hardware products, however, they can struggle to answer very simple VMware related questions like: how should I map the vSwitches’ uplinks to the blades nics, or how can I have redundancy for my networks, and soon and so forth!
• Knowledge seekers: anyone, like myself, who’s fascinated by VMware and willing to understand how these incredible software technologies can run on different hardware vendors with the same level of flexibility.

What vendors will be covered here, and in which order?

Any blade vendor that is listed in the VMware HCL might be included. I say “might” because it also depends on how fast I’ll be able to learn about this specific vendor technologies given the highly complex and variant architectures from one vendor to another. You should know also that I work on my own here, no help from anyone what so ever. It really takes a lot of blood, sweat and tears to understand each vendor’s approach in doing things.

There is no specific order in this series, I started with IBM because it’s simply the hardware platform that I have worked the most on. If you like the series/concept let me know your thoughts and feedback and based on that I’ll try to prioritize vendors over others. There is no preferences for me personally.

Are you a hardware vendor?

If you work for a blade vendor and stumbled through this series, please take a moment to read the following:

• If you’d like to comment, you are most welcome to add, correct, or amend any details in my posts that are related to your hardware. However, you are not welcome – under any way, shape or form – to bash your competitors in this series.
• I can work with you to highlight anything that can make the vSphere implementation more solid, unique or innovative on your hardware. On the other hand, I will not allow on my blog any vendor to criticize the design and/or implementation options of the other vendors. In short, no FUD please.

Alright then, enough introduction and scary thoughts and let’s get to it. I’ll keep the following list up-to-date to always reflect the new posts of this series.

• vSphere on IBM BladeCenter H