blog.scottlowe.org

Some time last week, one of my NetNewsWire subscriptions turned up an article titled “HP VirtualConnect” from Brent Ozar. It turns out that Brent’s blog, while heavily SQL Server-oriented, has a few nuggets of HP Blade information:

HP C-Class Blade Chassis Review
HP C-Class Blade Chassis Review Part 2: The Cisco/Brocade Interconnect Switches
HP Virtual Connect

Of course, Brent must be pretty smart since he linked back to my site…

Seriously, though, have a look at Brent’s HP c-Class articles for a good overview of the product and its associated technologies.

SearchVMware.com recently published an article of mine about using HP VirtualConnect with ESX Server and the impact it has on configuring ESX Server networking.  Based on the comments to my original post about the article, it appears that I didn’t adequately explain the interaction between VirtualConnect’s Standard Ethernet Networks and VLAN tagging.  I’d like to thank those readers that asked about this issue and take a moment to clarify.

Standard Ethernet Networks are defined in the HP VirtualConnect Manager and allow you to control the mapping between physical NIC ports on the blades (the “downstream ports”) and the connections from the VirtualConnect switches to the external network infrastructure (the “upstream ports”).  For example, I could define a Standard Ethernet Network called “Production” and specify that Production would uplink either via Slot 2 Port 7 or Slot 2 Port 8.

That part is pretty straightforward.  Here’s how it plays into VLAN tagging with ESX Server.  Most organizations prefer to use VST (Virtual Switch Tagging; described in more detail in this article).  To use VST, the ports on the network infrastructure must be configured as 802.1Q VLAN trunks so that the external physical switches will pass the VLAN tags to the vSwitches inside ESX Server, where ESX Server can then handle the traffic appropriately.

To use VST with VirtualConnect and Standard Ethernet Networks, there is no difference.  The VirtualConnect upstream ports, as defined in the Standard Ethernet Network configuration, must be plugged into physical switch ports that are configured as 802.1Q VLAN trunks.  When you plug the upstream port into an 802.1Q VLAN trunk, the downstream port—the port going to the ESX Server—automatically becomes an 802.1Q VLAN trunk as well.  The VLAN tags will pass all the way to the ESX Server’s vSwitches, where ESX Server can deal with the traffic appropriately.

Likewise, if the VirtualConnect’s upstream ports are plugged into a static access port—a port which is not configured as an 802.1Q VLAN trunk but instead carries traffic only for a single VLAN—then the downstream ports also become static access ports and you are, effectively, using External Switch Tagging (EST).

I stated this in the original article in the third paragraph in the section titled “How Virtual Connect differs in ESX”:

In either way, these Ethernet networks will “pass through” the 802.1Q status of the physical switch port to which it is uplinked. If the physical switch port to which they are connected is configured as an 802.1Q VLAN trunk, then the downstream ports will act as 802.1Q VLAN trunks. Likewise, if the uplink is connected to a switch port that is configured as a static access port, then the downstream ports will act as static access ports.

Shared Uplink Sets, on the other hand, are different.  They don’t behave in the same way as Standard Ethernet Networks.  With Shared Uplink Sets, you are forced to use EST because the VLAN tags are stripped away at the VirtualConnect level.  The associated networks that are defined in VirtualConnect Manager define the different VLANs, and each downstream port is connected to an associated network.  Unlike with Standard Ethernet Networks, no VLAN tags are passed up to the ESX Server with Shared Uplink Sets.

So, to summarize:

• Standard Ethernet Network uplink connected to external switch port configured as 802.1Q VLAN trunk allows ESX Server to see VLAN tags and supports both VST and Virtual Guest Tagging (VGT)
• Standard Ethernet Network uplink connected to external switch port configured as static access port only allows EST configuration
• Shared Uplink Set only allows EST configuration

I hope this clarifies the interaction between HP VirtualConnect and ESX Server networking.  I welcome any further questions or clarifications in the comments below.  Thanks!

In a recent article discussing Novell’s leadership change, one analyst was quoted regarding the change as being positive for Novell in that they (Novell) could stop building very high quality products and instead build products that are just good enough.  I don’t know about you, but this spirit of mediocrity is exactly the wrong kind of thinking for IT vendors.

Specifically, the quote stated this:

“Ron Hovsepian appears to be an astute business person, one who will be able to quickly take stock of the environment and Novell’s position within that environment. This, I hope, will help Novell move from its current position of very slowly building extremely high quality products to quickly building and marketing products that are good enough to satisfy the market,” concluded Kusnetzky.

So what is he (Dan Kusnetzky) proposing then?  It sounds to me that Dan thinks IT software vendors should make their products just good enough to pass muster, instead of making them the best that they can be.

In my opinion, this spirit of mediocrity—this willingness to accept products that are knowingly released with imperfections and flaws because they are “good enough”—is exactly what brought the industry to where it is today.  This mediocrity is what brought SQL Slammer, Blaster, and Melissa.  This is the view that accepts that rebooting your computer a few times a day is just a part of life, and that our operating systems and applications shouldn’t be expected to be stable and reliable.  Just good enough?  When was the last time you recommended a product, service, or vendor because they were “just good enough”?  No, just good enough isn’t good enough.

Every major IT vendor out there—from HP, IBM, and Sun, to Apple, Microsoft, and Red Hat—should be held accountable for the quality of the products they release.  Hey, I understand that companies may make mistakes, and miss errors.  That’s understandable.  But any company that knowingly releases a product that’s “just good enough” when it could have been better is not a company we should be praising.  We should be supporting those companies that emphasize quality over “just good enough”.

Perhaps I’m overreacting.  Perhaps the analyst’s comments were merely directed at the speed with which Novell releases their products, and was instead trying to state that Novell needed to release competing products more quickly.  Even so, any vendor that values speed over quality is bound to get bitten sooner or later.  Microsoft got bitten, and changed their priorities (somewhat).  Apple will get bitten, too, if they start letting the quality of Mac OS X releases slide in favor of shorter development cycles.  The same goes for all the other vendors.

What about you?  I’d love to hear your comments on the matter.

There is an incredible amount of momentum growing around the open source Xen hypervisor, and it is increasingly looking like market leaders VMware and Microsoft should be less worried about each other and more worried about Xen.

Check out some of the recent news articles regarding Xen:

“Novell to integrate Xen 3.0 in the next Open Enterprise Server”
<http://searchopensource.techtarget.com/columnItem/0,294698,sid39_gci1176440,00.html>

“Virtual Iron annonces 3.0 commercial and free editions based on Xen”
<http://www.virtualiron.com/news_events/releaseDate-4-03-06.cfm>

“Red Hat Formally Announces ‘Integrated Virtualization’”
<http://www.redhat.com/about/news/prarchive/2006/virtualization.html>

“Virtual Iron, XenSource to Unveil Xen 3.0 Products at LinuxWorld”
<http://www.eweek.com/article2/0,1759,1945398,00.asp>

(Note:  all links are courtesy of virtualization.info.)

And those links are just from the last few days!  Clearly, there is lots of momentum and lots of support from big name vendors such as HP, IBM, Novell, Red Hat, and others around the Xen open source hypervisor.  While some have speculated that VMware’s move to release VMware Server for free (and Microsoft’s corresponding drop in price for Virtual Server 2005 R2) have been to stave off each other, perhaps their moves were in response to Xen instead?

I was issued a new HP Compaq nc8230 laptop today, with the standard corporate image of Windows XP Professional Service Pack 2 and the assorted applications.  One of the very first things I did was install Ubuntu 5.10.  Here’s some additional information on a few of the hurdles involved (there aren’t many, fortunately).

I was already familiar with Ubuntu 5.10, having already installed it for my daughters on two older Compaq laptops.  However, I’d never installed it on brand-new equipment, so I was a bit concerned that all the hardware wouldn’t be detected properly.  A bit of searching came up with this article indicating that Ubuntu 5.04 had installed succesfully, so I felt fairly confident that everything would be fine.

So I popped in the Ubuntu installation CD, pressed Enter when prompted, and was soon greeted with a blank screen.  That was odd.  I rebooted, and got the same behavior.  Upon the next reboot, I pressed F1 at the “boot:” prompt to review some parameters.  I quickly stumbled onto the “vga=771” parameter.  At the boot prompt, I used “linux vga=771” and the system booted into the installation menu.  My first hurdle was overcome.

The rest of the installation seemed to go smoothly, right up until the point where the installation crashed with a message that it couldn’t copy files from the CD-ROM.  In fact, it couldn’t detect that the CD-ROM drive even existed.

I rebooted, tried again, got a little bit farther, and got the same message again.  Examining the CD a bit closer, I didn’t see anything wrong with the disc (no obvious scratches, dirt, smudges, etc.), but cleaned the CD nevertheless and tried again.  This time the installation process was successful, and everything was golden.

Until the X Server didn’t work on the final reboot.  Sigh.  Referring back to this article I’d found earlier, I followed the instructions to remove (if possible) and reinstall the xorg-driver-fglrx package and then reconfigure X.  When I had finally completed those steps, the X Window System started up and dropped me onto a customized GNOME desktop.  Finally!

From there, I proceeded to install a 686 kernel (instead of the generic 386 kernel) and run an “apt-get upgrade” to pick up the latest packages from the Ubuntu repositories.  So far (knock on wood), everything has been pretty stable and pretty functional.

UPDATE:  Scratch that functional part.  The laptop has locked up more times in one afternoon than my PowerBook has in the 2+ years that I’ve owned it.  I’m not really sure what’s going on with this thing, but clearly something isn’t quite right.

I setup some cool networking stuff today with some HP ProCurve switches.  A customer of mine was converting from a T-1 based WAN to an Ethernet MAN.  The carrier brought in a separate Ethernet drop for each location, and I configured a separate port-based VLAN for each drop and then set up routing between them. All in all, it took about an hour to convert all the locations from the old WAN to the new MAN, and 50 minutes of that was spent driving from location to location (everything is in the same city).

I know it’s nothing unusual (I’m sure there are those of you out there that do this stuff everyday), but I was particularly pleased at how smoothly we managed to make the conversion for all 12 locations. Plus, I’d done this before many times with Cisco equipment, but this was only the second time using HP equipment.

I’ll probably do a write-up of this on my company web site.  If you are interested in more details, look there soon.