Virtual Connect FlexFabric and Direct-Attach FC 3Par Caveat

When configuring a new C7000 Blade Enclosure with a couple of FlexFabric 10Gb/24-port modules I ran into a rather annoying issue during setup.

HP Virtual Connect 3.70 introduced support for Direct-Attach setups of HP 3Par StoreServ 7000 storage systems, where you can eliminate the need for dedicated FC switches. For full details, have a look at Implementing HP Virtual Connect Direct-Attach Fibre Channel with HP 3PAR StoreServ Systems.

This is excellent for setups where all your hosts are HP Blades, and you have a Virtual Connect FlexFabric setup. After all, less components means less complexity, right?

The problem I ran into is a bit strange though, and it took some time figuring out what was wrong. The HP 3Par StoreServ 7200 was racked, stacked and configured when the FC SFP+  modules where installed in the FlexFabric module, and I pretty much thought it would be plug and play from there to get the blades to talk FC to the HP 3Par after going through the Virtual Connect setup.

Sadly, that was not the case. It seems there is a bug in the web GUI for VC 3.70 that prevents getting a working setup. I know 3.75 is released, but nothing in the release notes seem to indicate that this has been fixed in that release.

For some reason, the “Fabric Type” dropdown where you should be able to select either “FabricAttach” or “DirectAttach” is greyed out, thus preventing the proper configuration of the SAN Fabric in “DirectAttach” mode. It defaults to “FabricAttach”, and in a Direct-Attach scenario that simply does not work. You will not be able to get a FC link and the SFP+ module will be listed as “unsupported”.


The solution was to create the SAN Fabric manually by using the Virtual Connect CLI interface. T
he following commands created the two fabrics required for redundancy (VC module in Bay 1 and in Bay 2)

[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]
add fabric Fabric-1-3PAR Bay=1 Ports=1 Type=DirectAttach
add fabric Fabric-2-3PAR Bay=2 Ports=1 Type=DirectAttach

As you can see, by using the add fabric command it was possible to define the correct Fabric Type and I could then proceed to add Port 2 from Bay 2 to Fabric-1-3PAR and vice versa to create a fully redundant setup.


Why the VC GUI prevented me from setting the correct fabric type is beyond me, but for some reason it simply did not allow me to change this rather important setting, and prevented the setup from working without using the CLI for configuration.

Quick and Dirty HTTP Based Deployment

A lot of the scripted installation tools that VMware offers allows the usage of a central HTTP based repository for hosting the files. Today I stumbled over a little gem that might just help you create a “quick and dirty” HTTP based deployment scenario by running a simple command in your terminal. By default, this command works on any system that has Python installed on it, so OS X and Linux should be ready to go as is. As for you Windows users out there, well, your mileage will vary.

The trick here is a one line Python command that simply creates a HTTP server listing the files in your current directory over a given port. On my MacBook, I opened Terminal and ran the following command:

[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]
python -m SimpleHTTPServer 8000
Serving HTTP on port 8000 ..


If I then open my browser, and point it to the IP address of my MacBook, I get a directory listing showing the contents of the current directory.

Quick and Dirty HTTP Deployment #01


As you can see, the directory contains a few files, namely a Damn Small Linux appliance packaged as an OVA, as well as the Linux installation files for ovftool.

In this particular case, I wanted to install ovftool inside a running vMA instance I had in my infrastructure. So, by running the following commands I got ovftool downloaded via HTTP, from my MacBook, inside a running vMA instance by only downloading the files in to a given directory and serving it via HTTP from there to vMA.

By running the following command (output edited for verbosity)

[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]
[email protected]:> wget && sudo sh VMware-ovftool-3.0.1-801290-lin.x86_64.bundle
100%[======================================>] 36,631,447  1.46M/s   in 23s
2013-05-14 12:13:06 (1.52 MB/s) – `VMware-ovftool-3.0.1-801290-lin.x86_64.bundle.saved [36631447/36631447]

vi-admin’s password:
Extracting VMware Installer…done.

Do you agree? [yes/no]: yes

Installing VMware OVF Tool component for Linux 3.0.1
[######################################################################] 100%
Installation was successful.
[email protected]:/tmp>

I was able to download and install ovftool, in one command.

The same deployment method could also easily be used to install host patches, deploy OVF based appliances and even install VIB files from a central repository. In fact, that`s the next thing to do here, deploy the Damn Small Linux appliance, by using the newly installed ovftool package.
The flexibility of having a small HTTP server available by running a single command is great, and I`m sure there are many other use cases that I have yet to consider.