VC, SUS, vNet, VLANs and a partridge...

So, recently I've been doing a lot of research on Virtual Connect, primarily because I've recently purchased some!

I've bought the following:

1.  HP c3000 BladeSystem chassis
2. 2 x HP 1/10GB Virtual Connect Ethernet modules
3. 2 x Cisco 3020 Blade switches (wouldn't SwitchBlades sound cooler?!) for mezz 2 for storage connectivity (ISCSI/NFS).
4. 8 x bl460c G1 blades for ESX and Hyper-V hosts...and maybe some other nonsense.

This will happily replace my 7!!! DL360G5's and use less power, produce less heat and make less noise...well maybe not the last.  BUT it will do the first 2 which saves money!

On to the point of this post...

In trying to understand the joys of Virtual Connect magic, I acquired the HP Virtual Connect Ethernet Cookbook which can also be found here (along with other supposedly useful bits).

After reading thru this and analyzing the differences in the scenarios I've come up with these differences and explanations:

Virtual Connect

Its like a switch with its legs cut off...but it feels like a bridge except it has more then an in and out port, but maybe not really if you consider you setup virtual connections inside it from each blade out to the external net...so maybe many bridges virtually layered? Or just a switch that looks like a single contact point to an upstream switch (no spanning tree).  Or maybe it's a switch that won't participate in a Spanning Tree.  Bottom-line...its Virtual Connect!

vNet vs SUS

This was the harder one and really the juice of the VC for me to understand how to pass VLANs. Here's my simplest explanation.

• vNet = Check a box to Tunnel VLAN traffic and it will pass all traffic as it is received...it dumbly hands it from one interface to the other never looking inside the envelope.
• SUS = Is all nosey and analyzes VLAN traffic and is told whether Adam's Left hand (Blade A, onboard NIC 1) is allowed to see all the VLANs or only VLAN 0 or 101 or 0 AND 101-104; or his Right hand (Onboard NIC 2) can see this versus that.  And then Brenda's Left hand (Blade B port 0) can see this or that, etc.  Ok, that wasn't simple.  Basically, with SUS, you can determine exactly what VLANs (including 0) are mapped to exactly which blade ports (if not ALL or NONE).

So really SUS allows you much more granularity on your traffic...if you want it.

So for all those Virtual Connect experts out there...I invite more in depth or probably more accurate explanations  as I couldn't really find just that...vNet vs SUS for dummies.

Enjoy.

vCenter 5.1.0a: Rollercoasters and you

Hello,
So for the past week(!), I've been trying to get vCenter 5.1.0a installed for a certain environment and it has been an experience!

*NOTE FOR ANYONE NOT INTERESTED IN READING:  I want to give credit to a series of posts by Derek Seaman that I ended up using for reference.  They didn't end up solving (or having anything to do with) the problems experienced below, but they are well written and informative and I will refer to them in the future for a vCenter install.

For full disclosure, I did go in pretty blind.  I figured, I've been doing this for a while and pretty familiar with vcenter, lets just get the ISO going and see how it smells.  Well, when I saw multiple addons/prereq's, I realized it was a new beast.  Bear in mind, the current one is only 5.0 which was still the more traditional install.

At first, I tried to upgrade the current vCenter (running as a VM) and that blew up for some reason that I don't recall.  When I looked at the programs list though, there was a bunch of older version software (thanks for keeping 4.0, 4.1, 5.0 versions of the client installed) and honestly, that VM always felt a bit sluggish and the vcenter service would commonly not start.  So, I decided to move it to a different datastore and shut it down.

Before shutting it down, I deployed a new 2008 R2 vm from my template which I've used on many other machines. I took a snapshot of the vm at each stage while installing and was very methodical on installing the 3 different, check...4 different aspects to a modern vCenter install.

1. Single Sign-On
2. Inventory Service
3. vCenter
4. Web Client (supposedly optional, but required for 5.1 (and beyond) features...)
1. Check out my other post on this subject

Moving on, after installing the first 2 without a hitch, vCenter would NOT install.  I kept getting this...

and then this...

 

So I when hitting up Giggle for the problem, I found a link saying to give the Network Service permissions on the C:\ drive and that would fix it. Admittedly, this did reference older 4.0 or 4.1 installs, but was my exact error # 28038.  Now, I don't know if you know this, but it is not trivial to modify the permissions on C:\Program Files, c:\Program Files (x86) or c:\Windows in 2008 R2...meaning it won't let you.  Specifically Administrators has special permissions set and "Change Permission" is not one of them; obviously neither is Full Control.  Based on that and considering the web wasn't blowing up about 5.1 on 2008 R2, I theorized this wasn't my answer.

The other suggestions were around "making sure its not a domain controller" and "remove the ADAM or AD LDS role" which neither was installed of course.  I kept seeing references to IPv6 for name resolution, but I've used DNS once or twice in my time, so that wasn't the problem (yes I did triple check all resolution directions just to make sure).  IPv4 worked fine, but so did IPv6; if you just ping the name on a 2008R2 server, often you will get a reply from the IPv6 addreess.

Another thing was that my template was fully patched as of 6/10/2012 or something, but in the Programs list, it had Visual 2008 or 2005 redistributable patches as well as Silverlight.  I couldn't imagine how any of that was screwing this, but I uninstalled them anyway, but that didn't fix the install.

So...I was stumped and it was 2am.  I had 2 choices...completely registry-disable IPv6 and/or completely rebuild.  I of course was tired of screwing around and rebuilt.  Again very methodical...snapshots at each stage.  I didn't even patch the server...just install os, install vmware tools, configure IP, add to domain, and then start vcenter install. 

This time I chose the simple install considering I was doing just that.  Guess what...worked no problem including the web client install (which previoulsy had not worked due to some other variable I can't remember)! I suspect that either a patch was getting in the way or one of the pre-setup bits I had done on the template had somehow screwed it up.

So, sometimes punting really is the best and only choice.

Go Pats!

Again, for anyone looking for a very descriptive walkthrough of a 5.1 vCenter install, please reference Derek Seaman's 796000 step process to installing vCenter 5.1.0a! (its really only 13).

NEW!!! WEBIFIED vCENTER! Get your's now!

Soooo...VMWare has decided to scrap the "thick destkop client" and go to a web-based front end. 5.1 is apparently the last version that will "support" the desktop client and even now, the new features for 5.1, such as hardware version 9, are only available thru the web interface...so its required now.

I'm always fearful when a company tries to force a web frontend, but sometimes (often times?) they turn out ok. Many firewalls are web (personal favorite Astaro/Sophos has a very good web frontend), many NAS boxes are web, even enterprise storage like Nexenta is web, but VMWare Infrastructure (classic name) is a pretty complex product doing alot of things, so I hope they do it right and make it perform and not cumbersome to use. The desktop client was pretty durn good....

Also, a little birdie told me that this and the VCSA (Virtual Center Server Appliance) are coming from a desire at VMWare to be non-dependant on Microsoft to run their product (I'm cleaning up the language a bit on their behalf).  Now of course I can't fault them and appreciate simplicity, but it still needs to be usable.  Oracle as a backend (for more than 5 hosts) is certainly not what I would call "common" even in medium size companies so is that really the best choice? Plus as far as companies go, can anyone really argue that Oracle is somehow "better" than Microsoft?

I'm predicting the future of vCenter will ONLY be the VCSA (I guess they'll have to incorporate VUM somehow), but don't see Oracle-as-the-only choice being viable.

Good luck VMWare and I hope it turns out well.

Setting up VLAN's...finally!

So, yesterday, or most accurately, very early this morning, I finally figured out how to setup VLANs in my lab.  While I know VLANs are "the shizz" and have long understood them conceptually and have implemented elsewhere, I hadn't yet done so in my special bag of goodness.  Plus on top of that, I've just replaced my core network switches which made it both easier and "harder".

So, to review, the lab environment (above) is a Sophos (formerly Astaro) firewall, now connected to two D-Link DGS-1248T 48 port smart gigabit switches.  FYI, these switches are now end-of-life, but they still work so no harm, no foul.  Connected to those are my ESX hosts. Magical, right?  Previously, I was using a Cisco 4506 blade switch, which was very nice and "a proud banner of Cisco" in my lab, but it also used 500+ watts of power alone and is huge.  I will cover the pros & cons of why the DLink's over 4506 in another post.

Set VLAN in ESX

So many others have documented how to setup VLANs in ESX, but I will review quickly.  There are three ways to provision VLANs in ESX.

1. Set the VLAN on the virtual machine Port Group on the Virtual Switch.

2. Set the port group VLAN to 4095 which is a passthru, and set the VLAN inside the VM (like a physical / traditional server).
3. Set the VLAN ID inside the physical switch the ESX host and specific uplink port is connected to.  Drawback here is that the VLAN would only be respected outside the ESX host; internal to the hypervisor boundary there is only the port group limitation which acts very similar to a VLAN anyway.

Of the 3, option 1, is preferred as it is the most obvious (to setup and to "discover"/remember after the fact), the most straightforward as you don't have to customize the VMs at all and the most dynamic and mobile.

Set VLAN in Astaro/Sophos

*This article is based on Sophos UTM 8.306
For those of you not familiar, the Sophos UTM firewall (formerly Astaro) is what I would call a "packaged linux firewall".  While it isn't some highly customized or proprietary kernel as far as I know (corrections?), it is a very slick interface for a fantastic collection of network "utilities" including Web proxy, firewall, smtp filter, VPN endpoint, DNS, DHCP, etc.  Hell it even runs an NTP server.  While I'm sure many other firewalls do all this and maybe more, I very much like the interface.  Please do check out their website and they even offer a free-for-home-use license which is very feature-rich.

A standard "plug in cable from switch" interface is known as Ethernet Standard and this takes ownership of the physical network port/device. To configure an interface for VLAN, you actually create (or switch to) an Ethernet VLAN "virtual" interface and attach it to a physical interface.  You can not have a Standard and a VLAN interface on the same physical port, but you can have multiple VLAN interfaces sharing the same physical port.

Set VLAN on switch ports

The D-Link DGS-1248T, as I said, is now end-of-life, but most switches in this category, 1U, Smart / Web-managed, etc are pretty similar.  D-Link, Netgear, Trendnet, Cisco (repackaged Linksys) all have switches in this category...they work.  Since this unit is older, it only supports static Trunking vs LACP and only 6 LAGs (Link Aggregation Group) using up to 8 ports each, but it does have 9220 jumbo frames and 802.1Q VLAN support, so for my small purposes, it works quite well.

To set up the VLAN on one of these switches you have to:

1. enable Asymmetric VLANs
2. create the VID = VLAN ID(?)
3. configure one or more ports for the VLAN as either Tagged, Untagged or Not Member.

The (un)tagged nomenclature is a little confusing and I'm not the only one as evidenced by the amount of forum posts about this exact topic.  The most simple explanation I found for "tagged, untagged and non-member" came from here.  Short version: the title (tagged, untagged) describes the state of the packets coming in to the firewall.  So, if ESX is already assigning/labeling/tagging that port group traffic as VLAN 1002 then you would mark either that incoming port on the switch or in my case for simplicity, all ports, as Tagged; that way, the switch won't modify the packets at all and will pass them along correctly.

As you can see, I have multiple VLANs configured and available on all switch ports.  In my simplified case (as with most small/med businesses), there is no downside to having all VLANs available everywhere.  In larger environments, especially Cisco, you have to worry about Spanning Tree Protocol across the switch fabric as more VLANs equals more overhead, etc and becomes cumbersome to manage.  Be aware.

One thing to note, if your connecting one switch to another in this fashion and you want to maintain the VLAN info (why wouldn't you?), the uplink ports must be "tagged" for each VLAN regardless of the tag state of the incoming traffic.  By tagging the port, the switches maintain that VLAN id and don't drop it.

Summary

So as you can see, you have to configure the VLAN info almost everywhere...the cables are safe at least!  Once you do it the first time, its pretty easy after that.  The easiest way to test if it is working...PING.  Either ping will work or it won't if the VLAN is correct or not.  In my case, I was pinging from a guest VM on my RT VM port group to the firewall. Until I had it all correct, ping no worky!

Good luck and K.I.S.S.