HP Virtual Connect: Common Myths, Misperceptions, and Objections, Second Edition

#11: VC doesn’t provide network visibility into the VC Domain for

network administrators

Incorrect: Virtual Connect provides several user interfaces options and features for managing and

monitoring Virtual Connect to fit with the variety of methods our customers use. VC supports both a

Web interface (HTTPS) and a CLI interface (SSH). In addition, VC supports per-interface statistics for

every server NIC port, server HBA port, VC Ethernet uplink port, and VC Fibre Channel uplink port.

These statistics can be monitored via the management interfaces or via SNMP/SMI-S polling. In

addition to local statistics and SNMP polling of statistics, VC provides SNMP traps for events that

cause VC Domain status changes.

Virtual Connect also supports port mirroring, to an external network analyzer, of Ethernet traffic

to/from any server NIC port(s).

#12: Many customers experience problems with VC deployment

consistency

Incorrect: Any mature, flexible, and feature-rich product provides the administrator with options for

configuring and customizing it. These configurations and customizations should be tested and

methodically applied to the product as it is deployed by the user. Virtual Connect is just such a

product and HP always recommends that an administrator purposefully customize and deploy a VC

configuration that is tailored to their environment.

To help simplify and ensure configuration consistency across similarly configured VC Domains, HP

provides enhanced configuration features. Virtual Connect allows VC Domain configurations to be

exported from a configured VC Domain and then imported on a non-configured VC Domain.

Scripting via the VC CLI can also be used to deploy consist VC Domain configurations across multiple

enclosures. Virtual Connect Enterprise Manager also provides enhanced configuration consistency

across VC Domains that are grouped together as “like” configurations.

#13: VC doesn’t support non-disruptive firmware upgrades (“hot code

load”)

Incorrect: Virtual Connect allows the administrator to upload firmware to each individual VC

Ethernet or Fibre Channel module without interfering with that module’s operation or the operation of

any other VC module. Once the new firmware is uploaded, VC allows the administrator to choose

when to activate the new firmware on a module-by-module basis (usually during a change window). If

using a “no single point of failure” configuration for the HP server blades, individual VC modules may

have their firmware activated while other VC modules maintain connectivity for HP server blades.

When upgrading VC firmware, there are two VC components to consider – the VC Manager interface

(analogous to a supervisor module on a Cisco 6500) and the individual VC modules (analogous to

the individual switch modules inserted into a Cisco 6500 chassis). The VC Ethernet modules in bay 1

and bay 2 of the c-Class enclosure work together to provide redundancy for the VC Manager

interface (like redundant supervisor modules in a Cisco 6500). A customer can choose to upgrade VC

Ethernet in bay 1 while VC Ethernet in bay 2 runs as the active VC Manager. This provides a means

for upgrading VC firmware while maintaining an active VC Manager. In addition, all server blades

are connected to multiple VC Ethernet and VC Fibre Channel modules when using HP’s best practices.

Since server NICs and HBAs are redundantly connected to VC Ethernet and Fibre Channel modules,

each VC module can be individually upgraded and activated while adjacent VC modules in the

enclosure provide active connectivity for the server (when using NIC Teaming for Ethernet and MPIO