blog.scottlowe.org

I came across this great article on the HP Fibre Channel VirtualConnect module tonight. Excellent work! Combine this with my TechTarget article on Ethernet networking with HP VirtualConnect and you have some good resources for using VirtualConnect in your environment.

Here’s a quick list of a few of the articles that I currently have in progress:

• I’ve been looking at the recently-announced products from Altor Networks and have their VNSA (Virtual Network Security Analyzer) running in the lab right now. Look for a short post on the product and my initial thoughts. (One piece of advice I can offer to Altor right now: use the virtual appliance OVF format and save your customers a lot of trouble.)
• I’m going to have some hands-on time with a Xsigo I/O Director over the next few weeks, so look for an article on that product.
• Prodded to action by Nick’s comment in my article on thin provisioned VMDKs on NFS, I’ll have an article on using SnapRestore to clone VMs on NFS without losing the thin provisioned VMDKs.
• The Active Directory integration articles are getting a bit long in the tooth, so look for updates to both the Linux and Solaris integration instructions. (By the way, speaking of Solaris integration: I came across this article a short while ago.)

If anyone has any other topics they’d be interested in seeing me tackle, feel free to mention them in the comments below. I can’t make any promises, but I’ll certainly consider them!

UPDATE: The article on preserving thin provisioned VMDKs with SnapRestore is now available.

I’m relatively new to NetApp deduplication (formerly A-SIS), so this article won’t be an advanced treatise on NetApp deduplication or its deep inner workings. Instead, this is intended to be a quick guide to setting up NetApp deduplication for others, like myself, who may be familiar with Data ONTAP but not necessarily deduplication.

Obviously, the first step will be to ensure that your NetApp storage system is licensed for deduplication. As of March 10, NetApp made the NearStore option, which was a prerequisite for deduplication, free. Yes, you read that right: free. Since NearStore is a prerequisite, you’ll need to be sure to license that first:

license add <Code for NearStore>
license add <Code for Deduplication>

Once deduplication is licensed, then you can enable it on a per-volume basis using the “sis on” command:

sis on /vol/<volname>

Note, however, that the volume cannot exceed a certain size, based on the storage system model, in order for deduplication to work. These volume size limits are laid out in TR3505. Note that the volume must never have been any bigger than the size limits described, so this means you can’t size it down to the limits set forth and then run deduplication.

Once it’s running, you can check the status with:

sis status /vol/<volname>

After it’s finished running, you can see your space savings like this:

df -s /vol/<volname>

After running deduplication on a small NFS volume that housed only three VMs, the “df -s” command showed a space savings of 64%. That’s pretty impressive!

Moving forward, deduplication will run automatically every night at midnight, as shown by this command:

sis config /vol/<volname>

That should be enough to get most everyone started. Feel free to post comments or corrections below.

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.

This is a handy little trick that many of you may already know. Starting with version 3.5, VMware added support for Cisco Discovery Protocol (CDP) on the ESX Server vSwitches. CDP support is enabled on a vSwitch with this command:

esxcfg-vswitch -B both vSwitch0

The “-B” parameter is case-sensitive; the “-b” (note the lowercase B) displays CDP status while the “-B” (uppercase B) configures CDP.

Once CDP support is enabled on the vSwitch—and assuming it is enabled on the physical switch—running the “show cdp neighbor” IOS command will show the link between each physical switch port and the matching ESX Server NIC. The output will look something like this:

Capability Codes: R-Router, T-Trans Bridge, B-Source Route Bridge
                  S-Switch, H-Host, I-IGMP, r-Repeater, P-Phone

Device ID Local Intrfce Holdtme Capability Platform      Port ID
s3        Gig 0/26        147      T S     WS-C3524-XFas 0/24
esx04     Gig 0/22        168       S      VMware        ESXvmnic0
esx04     Gig 0/21        168       S      VMware        ESXvmnic1

As you can see in the output above, the CDP output clearly links the physical switch port and the ESX Server NIC. This makes it incredibly easy to identify the NICs in the server. This is particularly helpful in blade situations, since you can’t exactly unplug the NIC and see which one goes down with “esxcfg-nics -l” (a common approach to identifying the NICs in the server). Of course, this requires Cisco switches in the blade chassis. Since the internal port mappings on the blade chassis determine which NICs connect to which ports, this command adds the mapping within ESX Server and lets us quickly and definitively identify the NICs in the server as seen by ESX Server.

A friend and colleague of mine recently launched a blog of his own, The Blade Blog.  If the useful information that’s been posted there so far is any indication, this will be a definite addition to your RSS subscriptions.  Keep up the good work, Aaron!

UPDATE:  After some great feedback on the launch of his site, Aaron’s moved away from Blogger to a hosted WordPress solution and has gotten a new domain name.  You can now find Aaron at the Blade Vault.  More information and updated URLs available here and here.

For some good information on using HP VirtualConnect with VMware ESX Server, go check out this article just published by SearchVMware.com:

While the idea of server profiles can be useful in VMware Infrastructure 3 (VI3) environments, Virtual Connect’s ability to integrate with VLAN tagging configurations is perhaps more applicable to ESX Server deployments on c-Class blades. In this article, we’ll take a look at how VirtualConnect integrates with ESX Server with regards to networking configurations.

Of course, I’m a bit partial to this particular author (wink, wink), but it is a good article nevertheless.

Feel free to hit me up with any corrections, comments, or thoughts.  And be sure to go read my article, so TechTarget will keep asking me to write for them!

Here are some VMworld links that I’ve been collecting over the last day or so.  As I have time, I’ll try to expand upon them and add my own thoughts and views, but wanted to mention them here briefly, at least:

• VMworld 2007: Embedded ESX a can of worms:  Alex Barrett of SearchServerVirtualization.com comments on the release of ESX Server 3i and what impact it may have on the usage of ESX Server in the enterprise.  Certainly it will have an impact, but I think the impact will be greater for third-party vendors than for IT managers.
• VMworld 2007: ESX price is not the problem
• VMworld 2007: VMware users say, “Lower prices”:  So are prices an issue, or not?  The guys and gals at TechTarget seem to be reporting conflicting views.  I’ll have to delve into this in a bit more detail.
• Open Virtual Machine Format Specification (OVF) Submitted to DMTF:  The OVF was announced earlier at VMworld 2007, but no details have really surfaced (at least, none that I’ve seen yet—feel free to forward information you may have found on OVF).
• VMworld 2007: bigger, broader and Viridian:  VMworld, strangely enough, isn’t just about VMware, so here’s some information from Microsoft on their developing hypervisor, code-named “Viridian”.  Here’s another blurb about virtualization security as well.

I’ll try to add some more information and my thoughts on some of these issues as soon as possible.  In the meantime, I’m off to my final session here at VMworld 2007 on Day 2!

VMware has made a number of announcements today, jointly making the announcements in general sessions at Partner Day/Technology Day here in San Francisco, CA, this morning along with official press releases:

• VMware Unveils Next Generation Hypervisor to be Integrated in Server Hardware:  News of this was broken on the Internet (mostly via virtualization.info) several months ago, but now VMware has publicly announced the movement of their hypervisor into the server firmware.  This movement is expected to bring about a number of significant improvements, many of which were alluded to by Diane Green during her speech this morning and seconded by Scott Davis (Chief Data Center Architect at VMware and Virtual Iron co-founder) during his speech as well.
• VMware Introduces Next-Generation Disaster Recovery with VMware Site Recovery Manager:  VMware Site Recovery Manager attempts to bring about some automation and workflow to disaster recovery (DR) solutions built on top of VMware.  Personally, I haven’t seen a great deal of information on this product, although I knew about it under NDA before today’s public announcement.  I’m looking forward to seeing more details on this solution, as well as getting the opportunity to have a look at the technical portion of the product.  (You know me—I love the technical details.)
• VMware Enables Enterprise Desktop of Tomorrow:  Virtual Desktop Manager 2 is VMware’s first (public) foray into the VDI broker space, whereas they have previously relied upon Propero (whom they acquired), Dunes (whom they are rumored to have acquired), Leostream, Provision Networks, Citrix, and others.  Personally, I hope that VDM 2 is much better than the previous-generation Propero solution, which I found unwieldly, complex, and unreliable.  (Of course, your mileage may vary.)  From what I understand, it is expected that VMworld attendees can apply for the VDM beta at the conference this year.  I don’t know that for certain, but I’ll be finding out tomorrow when VMworld officially starts.

I also had the opportunity this morning to attend a great in-depth session on VMware Consolidated Backup.  I’ll try to post more information on that session later today.

All in all, it’s a busy time for VMware, who is taking this opportunity to solidify their lead in the virtualization market against up-and-coming competitor Xen (now owned by Citrix) and Microsoft.  As developments occur and as I get additional information, I’ll post more here.  Thanks for reading, and feel free to clarify or correct any of my information in the comments.

It’s common in blade deployments to use multiple Ethernet switches in the blade chassis to provide network redundancy (I’ll refer to these as “chassis switches” moving forward).  For example, in both the IBM BladeCenter H and the HP BladeSystem c-Class, we can provision multiple chassis switches so that half of the NICs on the blades connect to one chassis switch and the other half connect to the other switch.  Within the OS, we load NIC teaming software to provide automatic failover if one of the links goes down.  In this scenario, if one of the chassis switches fails then traffic will automatically fail over to the other switch.

In cases like this, everything works as advertised.  But what about when the chassis switch stays up, but the uplink from that switch to the outside world goes down (perhaps the upstream switch went down or the link was unplugged)?  In that case, the link from the chassis switch to the blade’s NIC is still up, and therefore the NIC teaming software in the OS does not know that a problem has occurred and will not move the traffic to the other link.  In situations like this, we need to implement link state tracking.

<aside>Astute readers will recognize that link state tracking is actually applicable in any server deployment—not just a blade server deployment—where the servers connect to a distribution switch and not the core.  I’m just going to focus on blade server deployments here, but the configuration would be much the same, if not exactly the same, in non-blade server deployments.</aside>

Link state tracking is pretty easy to configure; you define one or more upstream ports and one or more downstream ports.  The upstream port(s) are the ports that uplink to the rest of the network; in a blade server deployment, this would be the ports (or port groups) that connect to the network backbone.  The downstream port(s) are the ports that connect back to the servers.

Here’s an example.  We have a Cisco chassis switch that has a GigabitEtherChannel port group defined as an uplink out to the outside world:

interface Port-Channel1
description Uplink to network backbone
switchport trunk encapsulation dot1q
switchport trunk native vlan 2
switchport trunk allowed vlan 2-4094
switchport mode trunk
link state group 1 upstream

Note the “link state group 1 upstream” command, which marks this port channel as an upstream port.  If all the links in this port channel go down (thus making the port channel itself go down), then the switch will notify downstream ports in the same group to mark themselves as down also.

The member ports of this port channel would not have the “link state” command present:

interface GigabitEthernet0/18
description Port group member for uplink to network
switchport trunk encapsulation dot1q
switchport trunk native vlan 2
switchport trunk allowed vlan 2-4094
switchport mode trunk
channel-group 1 mode on

So for the ports on the same chassis switch that are connecting to the servers in the chassis, we have this configuration:

interface GigabitEthernet0/10
description Web server NIC
switchport access vlan 2
switchport mode access
link state group 1 downstream
spanning-tree portfast

Note the “link state group 1 downstream” command, which marks this port as a downstream port from the Port-Channel1 interface.  If Port-Channel1 goes down (because all the member links in Port-Channel1 also went down), then GigabitEthernet0/10 will also go down.  Because GigabitEthernet0/10 went down, the NIC teaming software running in the OS on the blade will fail the traffic over to a different NIC, presumably a NIC that connects to the redundant chassis switch.

You’ll also need the global “link state track 1” global command to enable link state tracking (thanks for the clarification, Matt!).

Because of the nature of blade deployments, this sort of configuration is particularly applicable in blade deployments, but also applies in other situations as well (as mentioned earlier).  I hope this is useful!