HP Virtual Connect. Like it or Hate it?

[phowarth]

Are you using or have used in the past the HP Virtual Connect with the c-Class Blade Enclosures? Do you like it or hate it and why?

Pete

[kjb007]

I use several enclosures all with various virtual connects. While it's nice to have some of the advanced features, they're almost more trouble than they're worth. Don't get me wrong, I don't know of any other blade system where I can get 10+ pNIC as wel as 2 HBA's, and for that, I like them. What I don't like is the software to manage them. I suppose it's early on in the virtual connect lifetime, but I've had issues with the interface being slow, and being buggy. I've had to resort to command line often to get things done which refuse to work through the web-based access. Not to mention that firmware updates are like gnawing off your own arm, very slow, and very painful.

If they can fix the software, they'd be golden.

-KjB

[phowarth]

I liked it and found it some what buggy too in the management. But it's still early. What I like is the reduction in number of cables needed behind the enclosure. I'm off the project that had it and on a new one and one of the guys really hates it. I looking for what most people here on the communities think so that I can get a good feeling for proposing to use it in my designs or not. Or to just stick with pass-thru.

Pete

[kjb007]

For the most part, I think it's cool, and it's worth the hassle of getting it setup, since you do get the benefits you and I both mentioned already. For that, you can't beat it with a passthrough. Having a passthrough that could provide the same I/O would mean 4-5 times the number of cables as you mentioned.

-KjB

[gdesmo]

We are using BL680c. They are performing very well. The number of vm's we are getting on these quad core's is amazing.

I have also been frustrated with the c7000 enclosures. Mainly with the vc firmware updates. Since there is a redundant partner with every component. Shouldn't the updates not drop network/fiber connectivity to the blades? This is very frustrating. And makes the ha capability of esx useless in an enclosure.

[phowarth]

I agree. I actually like the Virtual Connect. I think the reduction in cables behind the server is definitely worth it and I didn't have any problems with my hosts. I was just curious because a guy I work with now hates it.

Before I left my last contract I had a po out for another full rack 4 encl. 32 Quad-Core BL 685's. 128gb of mem. How many machines are you guys getting on a host that have these boxes? And what's the average number of procs and mem your assigning to your guests?

Pete

[cfrantsen]

I like Virtual Connect, it can take a while getting used to the terminology and how they work and I think that's the part those who hate them haven't bothered with. Less cabling is a big plus, the profile concept is very nice, being able to switch out a blade and keep the WWN for example is worth alot. I haven't felt that the software is that buggy, I had a few issues when doing firmware upgrades but nothing major. The more recent versions are working alot better though.

I missed a few features in the early days, like being able to connect more than one SAN fabric and sharing network uplinks for both tagged and untagged traffic but these features are now available in recent firmware as well.

I have also been frustrated with the c7000 enclosures. Mainly with the vc firmware updates. Since there is a redundant partner with every component. Shouldn't the updates not drop network/fiber connectivity to the blades? This is very frustrating. And makes the ha capability of esx useless in an enclosure.

The redundant interconnects are still treated as separate boxes, just as you would connect a regular server to 2 different rack switches for redundancy the blades are connected to both interconnects via the enclosure paths. When you update firmware for the interconnects they are rebooted so naturally that module will drop the link to the server but the other in the redundant pair is still running so if you get outages because of this then you have a configuration error on the server end (NIC/HBA failover etc).

[BenConrad]

We decided not to use it:

1) I believe that in order to have hosts using 802.1q (ESX) and non-802.1q required the use of separate Eth ports on the interconnects.

2) the docs on these HP interconnects is so-so (really light on the details compared to Cisco), didn't want to deal with trying to find the one engineer a Blade Network Tech. that understands Virtual Connect if I had any issues.

Ben

[cfrantsen]

We decided not to use it:

1) I believe that in order to have hosts using 802.1q (ESX) and non-802.1q required the use of separate Eth ports on the interconnects.

2) the docs on these HP interconnects is so-so (really light on the details compared to Cisco), didn't want to deal with trying to find the one engineer a Blade Network Tech. that understands Virtual Connect if I had any issues.

Ben

1) Firmware 1.31 allows you to use the same uplink for both, they call it "Map VLAN Tags" IIRC.

2) I agree, so far I have found the online help to be one of the best sources of information although they can be quite cryptic at times as well

[kjb007]

You can't use the same physical port to both map and tunnel your VLAN tags. You have to either create a tunnel, and you can map several 802.1q VLANs on top of that uplink set, but you can not then use that same uplink set to tunnel 802.1q tags through those same set of ports.

-KjB

[cfrantsen]

What i meant was the following:

- Under advanced settings enable "Map VLAN Tags"

- Select "Multiple Networks" in the server profile, you get a pop-up window where you can choose to send one or more VLANs to the server, and one of them can be selected as untagged.

With this it should be possible to have a single 802.1q uplink set that you can use for both ESX blades (tagged) and standalone servers blades (untagged) as long as all the networks you need can be found on that single uplink set.

[kjb007]

While that's true and will work, if you're using untagged frames on the ESX side. With ESX doing the tagging, using untagged here will strip the VLAN tags that ESX adds, so you don't get to control what network you are on from ESX. This will work if you are only tagging all of your frames from virtual connect, and not from ESX, which is usually the prefered method.

-KjB

Message was edited by: kjb007 : changed virtual center to virtual connect

[cfrantsen]

Why wouldn't it work with tagged frames on the ESX side? Just choose the networks you want to presented to the ESX blade in the profile and don't touch the the "Untagged" checkbox. VC will send the frames tagged with the corresponding VLAN to the ESX where the tags can be stripped, and on the way back the ESX adds the tags needed and VC can then send the frame untouched through the uplink set.

[kjb007]

Untagged does not mean that it will create a tunnel for the 802.1q tags. Untagged means that the frames going in/out will be untagged. The tags will be stripped at the virtual connect level, so all frames going through that network profile will be on the native VLAN for that trunk.

-KjB

[cfrantsen]

Untagged does not mean that it will create a tunnel for the 802.1q tags. Untagged means that the frames going in/out will be untagged. The tags will be stripped at the virtual connect level, so all frames going through that network profile will be on the native VLAN for that trunk.

Exactly... so if you don't check the "untagged" checkbox for your ESX profiles (as I said in my previous post) it will send the frames tagged to the ESX blades. And for your normal servers profiles you do check the "untagged" checkbox so VC will send the VLAN of your choice untagged to that server port.

[kjb007]

Again, as I posted, if you check untagged, then any tags you apply from the ESX server side are removed. The point being to apply tagging at the ESX level, and not at the Virtual Connect level. Based on the bugginess of the software, if I didn't have to use the virtual connect, I wouldn't use it at all based on all of the issues we've had with them.

-KjB

[cfrantsen]

If you actually bothered to read my earlier posts you will see that I never once mentioned anything about sending untagged frames to an ESX server.

I suggest you go read "HP Virtual Connect for c-Class BladeSystem User Guide", check out pages 151-156 and maybe you will understand what I have been trying to say.

over and out.

[kjb007]

Reading is all well and good, and I'm glad you're helping to solve the problem the posters have had. If you were following along the thread and read the concerns and posts, you would see the relevance of my answers. Seeing a user guide and performing tasks in real life are two very different things.

The concern earlier in the thread, was about using a shared uplink set to send both tagged frames from an ESX host, and tagged/untagged frames from a virtual connect network profile, which virtual connect does not allow. So, you either create every single tagged/mapped VLAN on the virtual connect to support every contingency on a virtual connect, and then do the same thing on every single virtual connect you have, or you do it from ESX. You can not use the same set of ports to both tunnel and map VLANs.

-KjB

[BenConrad]

"2) the docs on these HP interconnects is so-so (really light on the details compared to Cisco), didn't want to deal with trying to find the one engineer a Blade Network Tech. that understands Virtual Connect if I had any issues."

So I needed some clarification on interoperability between HP <> Cisco re: Spanning Tree. Specifically, I wanted to know why adding more than 1 vlan in STG 1 created STP loops in my network (Cisco Aggregation is using PVST+ and Rapid-PVST+). HP sent my ticket to Blade Network Technologies and also scheduled a $200/Hr phone call with me today at 09:30 EST. It's now 10:34 EST and no phone call. I've since fixed the issue but this level of support is not what I expected.

Ben

[cfrantsen]

Seeing a user guide and performing tasks in real life are two very different things.

Yes it is, and I have both read the user guide as well as implemented it in real life.

The concern earlier in the thread, was about using a shared uplink set to send both tagged frames from an ESX host, and tagged/untagged frames from a virtual connect network profile, which virtual connect does not allow. So, you either create every single tagged/mapped VLAN on the virtual connect to support every contingency on a virtual connect, and then do the same thing on every single virtual connect you have, or you do it from ESX.

I'l try and explain in more detail exactly what i mean..

I have a blade chassi with 3 ESX blades and 5-6 other blades where I use a single shared uplink set to feed the ESX tagged traffic and the other blades untagged traffic.

Example config:

• Server VLAN Tagging Support: Map VLAN Tags

• Force server connections to use the same VLAN mappings as shared uplink sets : Enabled

• 1 Shared Uplink Set called "Trunk" with the following Associated Networks:

• Test1, VLAN10

• Test2, VLAN20

• ESX Profiles

• Ethernet Network Connections

• Network Name: Multiple Networks

• Shared Uplink Set: Trunk

• Test1 and Test2 selected, untagged NOT checked

• Other Profiles

• Ethernet Network Connections

• Network Name: Test1 or Test2

Then configure the ESX vSwitch as you would any setup where you feed it a trunk, by setting the VLAN ID in the Port Groups.

So, it's very much possible to use the same uplink set to feed tagged and untagged traffic to different blades at the same time. What actually happens is that VC strips all the VLAN tags from the packets coming in on the shared uplink set and then applies new tags to the packets before sending them to the ESX servers, and the other way around on the way back. This could also be used to NAT VLANs if you for some reason needed that.

There are some limitations though:

• You can only select 28 VLANs when configuring "Multiple Networks" in the server profiles, if you need more than this then you need to use a separate uplink and create a VLAN tunnel instead.

• All VLANs you want to use in ESX need to be defined in VC as well as they won't just get passed through like when you use a VLAN tunnel.