blog.scottlowe.org

A colleague at work just turned me on to the news that Brocade will be buying Foundry for $3 billion. This sets the stage for Brocade to compete even more directly with Cisco, not only in storage networking but now also in Ethernet networking.

Thanks for the heads-up, Greg!

In early December of 2006, I wrote a very popular article on VMware ESX, NIC teaming, and VLAN trunking. In that article, I laid out the configuration for using both NIC teaming and VLAN trunking. In particular, the NIC teaming configuration in that article described the use of Cisco Gigabit EtherChannel for link aggregation, in which both the physical switch and the vSwitch are configured to distribute traffic across all the links between them.

Since that time, the question has come up many times: which method is better, with EtherChannel or without? Many engineers prefer not to use EtherChannel (or its standardized equivalent, static LACP/802.3ad) because of the added complexity involved. It’s easier to just team the NICs at the vSwitch level and leave the physical switches alone. That is true, but what about performance? And what impact does this have on NIC utilization?

There are two ways of handling NIC teaming in VMware ESX:

1. Without any physical switch configuration
2. With physical switch configuration (EtherChannel, static LACP/802.3ad, or its equivalent)

In the NIC teaming/VLAN trunking article I referenced above, I noted that there is a corresponding vSwitch configuration that matches each of these types of NIC teaming:

1. For NIC teaming without physical switch configuration, the vSwitch must be set to either “Route based on originating virtual port ID” or “Use explicit failover order”
2. For NIC teaming with physical switch configuration—EtherChannel, static LACP/802.3ad, or its equivalent—the vSwitch must be set to either “Route based on ip hash” or “Route based on source MAC hash”. The majority of the testing I’ve done is with “Route based on ip hash,” so that’s where I’ll focus most of this discussion. Either way, the physical switch’s link aggregation mechanism should match whatever configuration is set on the vSwitch.

In order to better understand how these settings and different configurations affect NIC utilization, I set out to do some tests in the lab. Most of my tests were centered around IP-based storage from the host (i.e., using NFS or iSCSI for VMDKs), and only tested two basic configurations: using “Route based on originating virtual port ID” and no link aggregation and using “Route based on ip hash” with link aggregation. Although the tests were slanted toward IP-based storage traffic, the underlying principles should be the same for other types of traffic as well. Here’s what I found.

NIC Teaming Without Link Aggregation

First, it’s important to understand the basic behavior in this configuration. Because the vSwitch is set to “Route based on originating virtual port ID”, network traffic will be placed onto a specific uplink and won’t use any other uplinks until that uplink fails. (This is described in more detail in this PDF from VMware.) Every VM and every VMkernel port gets its own virtual port ID. These virtual port IDs are visible using esxtop (launch esxtop, then press “n” to switch to network statistics). That’s simple enough, but what does this mean in practical terms?

• Each VM will only use a single network uplink, regardless of how many different connections that particular VM may be handling. All traffic to and from that VM will be place on that single uplink, regardless of how many uplinks are configured on the vSwitch.
• Each VMkernel NIC will only use a single network uplink. This is true both for VMotion as well as IP-based storage traffic, and is true regardless of how many uplinks are configured on the vSwitch.
• Even when the traffic patterns are such that using multiple uplinks would be helpful—for example, when a VM is copying data to or from two different network locations at the same time, or when a VMkernel NIC is accessing two different iSCSI targets—only a single uplink will be utilized.

This last bullet is particularly important. Consider the implications in a VMware Infrastructure 3 (VI3) environment using the software iSCSI initiator with multiple iSCSI targets. Even though multiple iSCSI targets may be configured, all the iSCSI targets will share one uplink from that vSwitch using this configuration. Obviously, that is not ideal.

Note that this doesn’t really impact VMotion traffic, since VMotion is a point-to-point type of connection. VMotion would only be impacted if placed on a vSwitch with other types of traffic and their virtual port IDs were assigned to the same uplink.

NIC Teaming With Link Aggregation

In this configuration, EtherChannel/static LACP/802.3ad is configured on the physical switch and the ESX vSwitch is configured for “Route based on ip hash.” With this configuration, the behavior changes quite dramatically.

• Traffic to or from a VM could be placed onto any uplink on the vSwitch, depending upon the source and destination IP addresses. Each pair of source and destination IP addresses could be placed on different uplinks, but any given pair of IP addresses can use only a single uplink. In other words, multiple connections to or from the VM will benefit, but each individual connection can only utilize a single link.
• Each VMkernel NIC will utilize multiple uplinks only if multiple destination IP addresses are involved. Conceivably, you could also use multiple VMkernel NICs with multiple source IP addresses, but I haven’t tested that configuration.
• Traffic that is primarily point-to-point won’t see any major benefit from this configuration. A single VM being accessed by another single client won’t see a traffic boost other than that possibly gained by the placement of other traffic onto other uplinks.

This configuration can help improve uplink utilization on a vSwitch because traffic is dynamically placed onto the uplinks based on the source and destination IP addresses. This helps improve overall NIC utilization when there are multiple VMs or when a VMkernel NIC is accessing multiple IP-based storage targets. Note again, though, that individual connections will only ever be able to utilize a single uplink.

Practical Application

I come back again to the question I asked earlier: what does this mean in practical terms?

• If you want to scale IP-based storage traffic, you’ll have to use link aggregation and multiple targets. Using link aggregation with a single target (destination IP address) won’t use more than a single uplink; similarly, no link aggregation with multiple targets will still result in only a single uplink being used. Only with link aggregation and multiple targets will multiple uplinks get used.
• Link aggregation will help with better overall uplink utilization for vSwitches hosting VMs. Because there are multiple source/destination address pairs in play, the vSwitch will spread them around the uplinks dynamically.
• To achieve the best possible uplink utilization as well as provide redundancy, you’ll need physical switches that support cross-stack link aggregation. I believe the Cisco Catalyst 3750 switches do, as do the Catalyst 3120 switches for the HP c-Class blade chassis. I don’t know about other vendors, since I deal primarily with Cisco.

Clearly, this has some implications for efficient and scalable VI3 designs. I’d love to hear everyone’s feedback on this matter. In my humble opinion, extended conversations about this topic can only serve to better educate the community as a whole.

I recently wrapped up some testing in my lab around VMware HA; specifically, around VMware HA isolation response. My tests involved various network configurations and attempted to clearly document the behavior of VMware HA isolation response under different circumstances. I thought I’d share some of my findings here in the hopes that others would find this information useful as well. (Keep in mind that some of the stuff listed below is just common sense, but I’m including it here anyway just for completeness.)

• Ensure that the vSwitch hosting the Service Console has at least two uplinks. Keep in mind that instead of leaving that second uplink primarily unused, you can place other traffic on the same vSwitch and use the “Override vSwitch failover order” option to direct traffic preferentially onto certain uplinks. (I’ll most likely post a separate blog entry about that so that I can explain that in more detail.)
• Ensure that DNS is working correctly on all ESX hosts in the HA-enabled cluster. You should verify host name resolution for both short names as well as fully-qualified domain names (FQDNs). Although I’ve seen numerous recommendations to hard-code entries into /etc/hosts, this approach is difficult to manage and does not scale well. Just fix DNS instead.
• Ensure that the Service Console’s default gateway responds to ping. If it does not, you’ll need to use the das.usedefaultgateway and das.isolationaddress parameters to change where VMware HA should check to see if it is isolated. Chad Sakac recently discussed these items as well, so check that entry for additional information.
• In a Cisco networking environment, ensure that Portfast is enabled on all physical switch ports. This will help reduce the possibility of an isolation response occurring due to transient network issues. Otherwise, the delay to put the port into a forwarding state is longer than the isolation response timeout, and a brief loss of connectivity could easily result in triggering VMware HA isolation response.
• If you are going to use a second Service Console port, be sure to specify a different IP subnet for the matching vswif interface. Otherwise, the Service Console’s routing table gets involved and tries to route everything through vswif0. That kind of defeats the purpose behind the secondary Service Console. My tests showed that isolation response was triggered every single time connectivity to vswif0 was lost when the secondary Service Console shared the same IP subnet as the primary Service Console interface.
• It should go without saying, but be sure that the secondary Service Console port is placed on a different vSwitch than the primary Service Console port. (Common sense, I know, but it’s worth pointing out anyway.)
• My tests have not shown that it’s not necessary to use a secondary isolation address when using multiple Service Console ports. The same post by Chad I linked to earlier seems to imply (unless I’m reading it incorrectly) that you should have multiple isolation addresses. I’m certainly open to any additional clarification any readers may be able to provide.

If you have any additional information or recommendations to share, please include them in the comments.

Here’s Virtualization Short Take #12, a collection of links I’ve gathered over the last week or so and my thoughts on them. Enjoy!

• For those that missed it in the Release Notes, VMware added support for Storage VMotion and 10Gb Ethernet with iSCSI SANs, as outlined in this VI Team blog entry. I went back and reviewed the Release Notes and didn’t see this listed anywhere, so this is news to me. Of course, I already knew that Storage VMotion worked just fine with iSCSI, but this added formal support for iSCSI.
• Virtualfuture.info published some good recommendations for running Citrix in a VI3 environment. If you run Citrix Presentation Server…er, XenApp…in a VI3 environment, these tuning tips may prove quite handy.
• VMware’s Virtual Reality blog posted an entry on some of the architectural advantages of VMware Infrastructure in comparison to the two leading competitors, Xen (any Xen-based solution) and Hyper-V. Many of the things listed as advantages by VMware are severe points of contention with the other vendors, such as the direct vs. indirect I/O model. Ultimately, time will tell which model was the best; I honestly don’t know enough about the deep dark internals to really state which is better. One thing I am glad to see pointed out is the true comparison of hypervisor sizes; Microsoft can say all they want that Hyper-V is only 600K in size and therefore is the “thinnest” hypervisor, but the truth of the matter is that Hyper-V can’t run without Windows Server 2008 in the parent partition. As a result, it doesn’t really matter how “thin” Hyper-V is, does it?
• Via Mike Laverick, I learned that Microsoft may have brought up the whole 64-bit hypervisor vs. 32-bit hypervisor argument yet again. Mike used a snippet from this Microsoft Virtualization Team Blog entry; in reading it myself, I don’t get quite the same 64-bit vs. 32-bit that Mike picked up. That’s good, because I didn’t want to have to go there again. Personally, the tone I picked up from the whole article was one of educating people far too accustomed to Virtual Server/VirtualPC and trying to educate them on how Hyper-V is different.
• Virtualization analyst Chris Wolf recently posted an entry in which he questioned if Apple would capitalize on the opportunity that virtualization is creating. It’s an interesting scenario, one that is similar to a scenario that I discussed a couple of years ago in a piece titled “Application Agnosticism.” In that article, I suggested that seamless host-guest interactions with virtualization software (now implemented by VMware as Unity and by Parallels as Coherence) would usher in a new wave of computing. I suggested that Mac OS X was ahead of the curve because of its ability to run native OS X applications, UNIX applications, X11 applications, Windows applications via WINE (or the commercial variant CrossOver Office), and applications from any other operating system via virtualization. Sounds like I may have been a bit ahead of my time!
• Chad continues discussing VMware HA with another post on some additional configuration options for HA. Also check out the comments with links to even more information on HA’s advanced configuration options.
• This VMware KB article has some good information on getting LUN identification information. The breakdown of the command-line output from esxcfg-mpath is particularly helpful (and for that reason I’ve added it to my del.icio.us bookmarks).
• Rich of VM /ETC shares with us a “Doh!” moment he had when he saw this simple method for identifying VMs with snapshots. Sometimes it’s the simplest solutions that evade us the longest. Here’s what I want to know: Aaron, what exactly does “/HEADDESK” mean, anyway?
• This article at SearchNetworking.com brings to light some of the challenges networking professionals face with server virtualization. I do agree with one point made in the article regarding the mapping of applications—what the end users really care about—to the networking infrastructure. VMware’s support for CDP in recent versions of VMware Infrastructure is a step in the right direction, but there is still more work to do for sure. I’m not so sure about the rest of the points in the article, but I may be an exception to the norm; I was a CCNA for a while (on track for CCNP) and have done my fair share of Cisco configurations, so I’m no stranger to the networking world. The use of VLANs to ease configuration in a server virtualization environment seems just second nature to me. Also, I did note that the author indicated that “server administrators sometimes inappropriately configure the switches to create a loop” (referring to vSwitches in ESX). How exactly does that happen? I’ve never seen a way to link two vSwitches together without using a VM.

As always, readers’ thoughts are welcome in the comments!

I ran into a recent issue with a customer who was having problems getting VLANs to work as expected with ESX. The basic scenario was that ESX would refuse to work properly with a VLAN that was marked as the native (or untagged) VLAN. This was causing no end of grief for this customer.

I’ve discussed VLANs extensively—first with this blog post, then again here, and again in this SearchVMware.com tip—so I was confident that I could help the customer resolve this issue. Granted, the customer was using Nortel switches, with which I am completely unfamiliar, but a switch is a switch, right?

Not quite. While the configuration seemed correct in all ways, it turns out there is a checkbox somewhere labeled “untag-default-vlan”. If this box is not checked, then the default VLAN gets tagged. Since ESX wasn’t configured with a VLAN tag, then it doesn’t see the network traffic. Once that box gets checked, then the default (or native) VLAN doesn’t get tagged and will be properly recognized by an ESX port group without a VLAN tag configured.

So, if you’re using Nortel switches and having problems with VLANs, double-check this setting.

My original article on Hyper-V’s issues with NIC teaming has gotten a fair amount of attention.

First Keith Ward over at Virtualization Review blogged about this issue. In his initial post, Keith basically pointed out the issue and then asked the readers for feedback: is this really as big of an issue as it seemed? The readers who responded were split; one blasted Hyper-V and the other wasn’t too concerned.

Keith followed that up with another post in which he provides a response from Microsoft regarding this issue:

NIC Teaming is a capability provided by our hardware partners such Intel and Broadcom. Microsoft supports our partners who provide this capability. This is true whether the customer is running Windows, Exchange, SQL, Hyper-V, etc. We’ll have a detailed KB article about this coming out soon.

Keith’s second article was then also picked up by DABCC.

While Microsoft is sticking to the “this is a device driver issue” mantra, I’m not so sure I agree. I can see their position to a point. In Keith’s second post, analyst Chris Wolf brings up storage drivers. This is similar in that Microsoft relies upon the storage vendors to provide device-specific modules (DSMs) that provide the multipathing functionality. So, like with the NIC teaming, Microsoft is pushing the functionality back to the device drivers and vendors who write them.

But that’s as far as this comparison can be taken. Microsoft officially supports storage multipathing; they don’t officially support NIC teaming. (See this KB article or this KB article.) In addition, Microsoft provides an official framework in which the storage vendors can operate: the MPIO framework. There is no such framework for network redundancy. In fact, if such a framework existed then much of the dissatisfaction with Microsoft over this issue would be alleviated, in my opinion.

Instead, there is no framework to provide official NIC redundancy for any Microsoft product running on Windows Server, and Windows itself doesn’t provide that functionality. Users are forced to adopt unsupported means to provide NIC redundancy. Why shouldn’t they be upset?

By the way, since publishing the first article I’ve been contacted by one of the presenters of the VIR358 session during this which issue came to light, but he has not yet been able to provide any additional information. As soon as more information is available, I’ll be sure to let everyone know here.

After the conclusion of VIR358, I went up to the front to speak with the presenters about the question I had during the session: what about NIC bonding or NIC teaming? You’ll recall that I wondered about that during the VIR358 session.

Well, it turns out that Hyper-V does not support any form of NIC teaming or NIC bonding. Yes, you read that right: you can’t link more than one NIC to a virtual switch in Hyper-V.

If you follow my del.icio.us linkstream, you will probably have noted that I recently bookmarked a Microsoft KB article that describes how using HP’s Network Utility can cause Hyper-V to stop responding. I guess this just goes to further support Hyper-V’s lack of support for NIC teaming or bonding.

In my opinion, that is a huge problem. How does one go about providing network link redundancy to guests hosted on Hyper-V? Surely using Failover Clustering and Quick Migration isn’t the answer here, is it? One of the presenters offered to get back to me with more information; I’ve already sent him an e-mail so he has my contact information. As soon as I hear something back, I’ll be sure to update this post.

Day 3 of Tech-Ed 2008 is upon me, and the first session of the day is another session with Jeff Woolsey. This session, VIR358, is titled “Windows Server 2008 Hyper-V Architecture, Scenarios, and Networking.” I suspect there will be some duplicate content from Jeff’s Day 1 session, and I’ll try to weed that out wherever possible. I’m particularly interested in the networking discussions, as I was unable to gather any real information on Hyper-V networking from the Day 1 session or from my private discussion with Jeff.

As the session begins, Jeff reminds everyone of the MAP 3.1 beta. I described MAP in more detail in a session yesterday. This new version adds some additional functionality and features, primarily around Windows Server 2008 Hyper-V. Jeff went into some additional detail about MAP, but I won’t worry about covering that again here.

Jeff’s agenda lists a virtualization comparison. I’m guessing that will mean a comparison of Hyper-V with other virtualization solutions. Will that comparison be against other vendors’ products?

According to IDC, virtualization penetration is estimated to be only 17% in 2010, up from 5% in 2005.

(The session is very crowded, perhaps the most crowded session I’ve attended thus far.)

With regards to system requirements, Hyper-V requires hardware assists (Intel VT or AMD-V) and hardware-enabled data execution prevention (DEP; in the form of AMD NX or Intel XD). Without these features, Hyper-V will not operate. Hyper-V is 64-bit also, meaning that you must use x64 processors.

Jeff describes the hypervisor itself as running in “Ring -1”, which he explains as less than Ring 0 due to the hardware assists provided by Intel VT or AMD V. This allows child partitions (guest VMs) to run at native Ring 0.

The architecture slide that Jeff takes some time to walk through contains much of the same information as VIR367 on Day 1. Going back to I/O again, Jeff revisits the concept of emulation (used in Virtual Server) vs. synthetic devices. Emulation provides great backward compatibility, but performance was awful. Hyper-V uses “driver enlightenment,” or synthetic devices, which leverage VMBus. VMBus is a point-to-point high-speed connection between a child partition and the parent partition. Note that synthetic devices are only available to “enlightened” guest operating systems. You can consider Hyper-V’s synthetic devices and their corresponding drivers to be the equivalent of VMware Tools, VI Tools, etc. Some vendors also call these paravirtualized drivers. Virtualization Service Providers (VSPs) and Virtualization Service Clients (VSCs) are part of this synthetic device architecture and VMBus.

The partnerships between Microsoft and Linux vendors (like Novell) allows for enlightened drivers to be available for Linux distributions as well, preventing them from having to use emulation and suffering the performance penalty that results.

Hyper-V features checklist includes support for up to 64GB of RAM per VM, up to 4 logical CPUs per VM, integrated cluster support (this provides both HA and Quick Migration functionality), support for BitLocker (earlier sessions seemed to question Hyper-V support for BitLocker), live VM backups through integration with Volume Shadow Service (VSS), pass-through disk access for VMs, VLAN and load balancing support, and snapshots. For the most part, this puts Hyper-V on par with most other virtualization solutions, with the glaring exception of live migration. Live migration is supported by VMware, XenServer, and Virtual Iron, among others. Microsoft does have an advantage with the VSS support for live VM backups.

Jeff references a white paper due to be published soon that details how to use BitLocker with Hyper-V.

Jeff did cover one slide on Hyper-V security. I won’t reproduce that stuff again; refer back to my coverage of Jeff’s discussion on Day 1 in VIR367.

Next, Jeff reviews the results of the TAP, RDP, and MSIT deployments. Based on thousands of VMs running on Hyper-V running in production across a variety of industries, Jeff says there have been zero performance blockers, zero deployment blockers, zero application compatibility bugs, and zero scalability blockers. According to Jeff, “the little red phone” that TAP or RDP customers can call if there’s a problem hasn’t rung even once. He also revisits the use of Hyper-V for the TechNet and MSDN web sites.

Mike Sterling then takes over to provide a demo of Hyper-V. Following the demo of Hyper-V, Mike also provides a brief demo of System Center Virtual Machine Manager (SCVMM) 2008. I’ve covered that product extensively in other sessions, so I won’t cover that material again here.

Once Mike concludes his demo, Jeff starts into a discussion of networking. Microsoft recommends at least two network adapters; obviously, more would be better. If you are going to use iSCSI, use another dedicated NIC for storage. That brings it up to three NICs at a minimum. I recommend an absolute minimum of three adapters with other virtualization solutions, so this is nothing surprising or unusual. In terms of connecting the NICs, connect one NIC to a management network (this is where the parent partition will communicate) and separate NICs connected to storage and production networks. Only VMs should be exposed to production networks.

We now move into some networking examples. In example 1, we have 4 adapters. One adapter will be assigned to the parent partition for management, and the remaining three NICs will be used for VM networking. Storage in this case will not be iSCSI; it will be Fibre Channel or direct attached. In the Hyper-V configuration, selecting these three NICs for use with VM traffic creates three separate virtual switches. What about NIC bonding for virtual switches?

In example 2, we have 4 adapters again, but this time 1 NIC will be used for iSCSI traffic. This leaves only two NICs for VM traffic. This example shows multiple VMs sharing a single virtual switch, but I still don’t see anything with multiple NICs assigned to a single virtual switch.

When looking at the properties for NICs assigned to the parent partition, all the typical components will be bound. Conversely, for NICs assigned to virtual switches, only the Virtual Switch Protocol will be bound to the NIC.

When looking at a VM, emulated NICs will be listed as “Legacy Network Adapter,” whereas the new synthetic adapters will be listed simply as “Network Adapter.”

If you’d like to run Hyper-V on a laptop (perhaps for demos or testing), Hyper-V does not provide any support for wireless networks. It also doesn’t support sleep or hibernation, and multiple spindles (multiple physical hard disks) are highly recommended. You also need a laptop that uses the Santa Rosa chipset or a later chipset. These newer chipsets will allow you to use 4GB of RAM or more in the laptop.

Jeff went through a few more slides, describing his personal laptop configuration (dual-boot Windows Server 2008 and Windows Vista with dual hard drives), a cheap test/dev system, and the overall procedure for creating new VMs. I believe I described the process for creating new VMs earlier, but if you’ve used a virtualization solution before there’s nothing new here. Jeff speaks highly of the rapid deployment capabilities that are possible now with Hyper-V, SCVMM, and VM libraries; I would dare to say this kind of functionality is pretty standard with most every virtualization solution out there. That’s not a knock against Hyper-V, just a “level set” that this isn’t something that doesn’t exist with other platforms. This just brings Hyper-V on the same level with other products.

The next few slides were all material that’s already been covered else, like SCVMM, SCOM integration with SCVMM, other System Center components, etc. I won’t bore you with all the details again. If there is one thing that I’m tired of hearing here at Tech-Ed this year, it’s the story about bringing all of System Center together with Hyper-V. Every single session says it.

The virtualization comparison first compares Hyper-V with Virtual Server 2005 R2, and then moves on to compare Hyper-V with ESX 3.5. I don’t necessarily agree with the way in which Jeff makes the comparisons with ESX; for example, he lists Hyper-V as having “unified physical and virtual management” but ESX as having only “virtual management.” It’s not Hyper-V that provides this functionality; that’s System Center Operations Manager. That kind of comparison is, in my opinion, playing loose and fast with the boundaries of the products and related products. I may just have to perform and publish my own comparison…

That wrapped up the session. They gave away three copies of Windows Server 2008, SQL Server, Visual Studio, but I didn’t win. Bummer.

At the start of 2007, I wrote a pair of articles on Mac FTP/SFTP clients, lamenting the performance of the open source Cyberduck application and eventually settling on Interarchy as my replacement product.

Quite a bit has happened since that time, and I now find myself in a bit of a quandary. Cyberduck has replaced the underlying file transfer engine to dramatically improve overall throughput, and Interarchy has “refined” the user interface to make it look more Mac-like. Unfortunately, in the process, Interarchy has become downright ugly. I don’t like the ugly chiclet buttons in Leopard’s Finder, I don’t like them in Safari, and I don’t like them in Interarchy, either. I very much prefer “old school” color icons in the toolbars.

Given that the new Interarchy interface was really bugging me—the Finder, at least, is still usable when you turn off the sidebar and close the toolbar—I thought I’d try Cyberduck again. Simple, one-file performance tests showed that Cyberduck, with the option to transfer files via SCP enabled, was coming much closer to matching Interarchy’s performance; Interarchy remained in the lead for raw performance, however. I figured that I could live with the performance degradation for most tasks, and started trying to use Cyberduck whenever possible.

Until tonight, that was. I needed to transfer a large number of smaller files up to one of my web sites, and Cyberduck simply dragged. I guess it’s the method whereby Cyberduck manages connections that slowed down the process, since it appeared that it checked the connection to the server for each file it was transferring. In any case, I’ve found that it looks like I’ll just have to suffer through Interarchy’s new look; the alternative is just too slow.

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.