One of the key capabilities we offer on BladeSystem is Virtual Connect.  Virtual Connect is a very powerful technology that allows customers to be self-sufficient.  Not surprisingly, competitors have since begun offering products with similar sounding names or features as that of Virtual Connect.  But in reality, they are very different.

When we developed Virtual Connect, we were really thinking of how to simplify how customers connect their servers to LANs and SANs.  Customers have told us that the server administrators have difficulty with adds/changes of servers, because there is an interdependency of the server configurations to the LANs and SANs.  Adding a server, moving a server, or swapping out a server requires the LAN administrator to reprogram LAN switches, the SAN administrator to reprogram switches, and the storage administrator to modify the storage LUN presentation.  We wanted to develop a product that would allow the server administrator to be self-sufficient in managing the server infrastructure. 

Virtual Connect provides a clean separation between the servers and the LAN and SAN.  Virtual Connect allows customers to add, remove, or change servers without requiring corresponding changes to the LAN or SAN.  This results in server adds or changes to be implemented in minutes instead of days or weeks, and makes everyone more time efficient.  Virtual Connect controls the LAN connections – MAC addresses, VLAN connections, and PXE – as well as SAN connections – WWIDs, zones, and boot parameters – to allow the complete LAN and SAN connection information to be tied to a server or server bay. 

Dell and IBM have both come out with products that have features or names that sound sort of like Virtual Connect, but the similarity stops there.  They do not provide a clean separation between the servers and the LAN and SAN.  They force customers to either choose pass-through modules with many cables or enclosure switches, which results in many switches to manage.  These products allow MAC address and WWID modification, but this does not make the server administrator self-sufficient.  If a MAC address is moved from one server to another, the VLANs are still tied to the old server.  This change requires the LAN administrator to reprogram a switch.  The same goes for fibre channel zone information, which requires SAN administrator intervention to reprogram SAN switches.  As a result, these products fail the basic test of enabling server administrators to be self-sufficient – they still require all three teams to get involved in making a change.

We did not develop Virtual Connect for the sake of having a MAC address migration feature, which does nothing to simplify server connection information to be moved from one server to another.  We designed Virtual Connect to make server administrators more self-sufficient.  We wanted to make BladeSystem useful for you, and Virtual Connect is a key technology that enables this.