We finally gave up on that and instead I went with an OpenBSD box to which I could establish an SSH session and then tunnel traffic from there. That worked reasonably well, especially after I discovered the GNU Screen utility. Talk about a handy little tool! Anyway, I continued using the SSH gateway for quite some time and I had resigned myself to living with the limitations.

Then a co-worker from the office casually mentions that he’s set up a Linux-based OpenVPN server on another subnet in the lab (we have a range of different subnets for different engineers in the lab). He, too, is a Mac user, but still running Mac OS X 10.4 on an older 13″ PowerBook G4 and using the Tunnelblick OpenVPN client. I thought to myself, “Hey, this might actually work!”

Alas, some additional research indicated that Tunnelblick had some stability problems under Leopard, which I’m running on my MacBook Pro. Bummer! I continued to research the issue but didn’t bother trying to use the OpenVPN server until just a couple of weeks ago when I uncovered Viscosity.

Viscosity is a shareware, Leopard-only OpenVPN client. It supports Growl notifications (which I very much like) and operates as a simple menu icon that easily allows you to connect or disconnect individual connections. Owing partially to how OpenVPN works, Viscosity uses (and includes) a TUN/TAP driver for OS X and creates a new TUN/TAP interface for every connection. This makes routing much easier and much more logical, in my opinion.

I’m so pleased with OpenVPN thus far, in fact, that I’m going to be setting up my own OpenVPN server here at the house.

My experience thus far has been quite positive. If you are looking for a good OpenVPN client for your Mac, Viscosity would be an excellent choice. At only $9 for a license, it’s well worth it.

• GrowlCamino
• YAMB (Yet Another Mac Browser)
• Mac Bookmark Managers
• Preferred Mac OS X Applications
• Very Handy Add-On

Deduplication enhancements improve NetApp on VMware ESX

NetApp storage area network (SAN) deduplication is useful for reducing storage requirements and saving space out of the box. When combined with a VMware Infrastructure 3 (VI3) or a virtual desktop environment, however, a few simple configurations can offer additional space savings and minimize the overhead of running deduplication on a storage array.

Physical network design options for VI3

VMware ESX offers outstanding support for a wide variety of networking configurations. Users have the option of using network interface card (NIC) teaming with or without physical switch support; numerous VLAN configurations, three of which are described in more detail in VST, EST and VGT tagging tips; support for both active and standby NICs, including per-port group active/standby NICs; and jumbo frame support. With all these options, it can be daunting to find the right configuration for your environment. In this article, we take a closer look at some network design decisions and how they play into the physical side of the network.

As usual, these articles have been added to my Delicious.com bookmark list and tagged with “Articles”; you can view my full list of articles here. (Oh, I added a video I shot while at VMworld 2008 to that list as well, in case you were wondering why it’s there.)

• Provisioning LUNs for Use with Deduplication
• Quick Guide to Setting up NetApp Deduplication
• Using NetApp Deduplication with Block Storage
• NetApp Adds Deduplication to Their VTL
• Storage Short Take #4

In addition, version 1.5 of OmniFocus for Mac (OF/Mac)—currently at RC2 status—will synchronize with OmniFocus for iPhone (OF/iPhone) via MobileMe, WebDAV, or Bonjour on local Wi-Fi. This weekend, version 1.1 of OF/iPhone finally got approved and pushed out to the App Store servers. The new version adds Bonjour sync over local Wi-Fi, meaning that it’s now possible to quickly and easily synchronize the OmniFocus database on my laptop with the OmniFocus database on my iPhone. Sweet! (Version 1.1 of OF/iPhone also improves performance and has a few other improvements as well.)

Unfortunately, in the late hours last night, I just couldn’t get things to work. No matter how hard I tried, OF/iPhone just wouldn’t synchronize with OF/Mac. It would see my laptop advertising via Bonjour, but wouldn’t synchronize. My first suspicion proved to be a good one: the IPFW firewall on my laptop. (I use a custom IPFW ruleset in addition to Little Snitch to control traffic moving into and out of my laptop.) I was able to confirm that the firewall was blocking the traffic with this command:

sudo ipfw show

Sure enough, I saw the default deny rule’s counters incrementing every time I tried to synchronize. With this command I quickly disabled the IPFW rules:

sudo ipfw flush

OK, that got me a bit farther, but OF/iPhone was still reporting an error. The error was different this time, though, so I was convinced that I had made some progress. Unsure of what could be wrong next, I tested a hunch and logged into the Squid proxy server that controls outbound HTTP/HTTPS traffic and checked the access logs. Bingo—OF/iPhone was hitting the proxy every time I tried to synchronize. But how to fix that? My network is configured such that the Cisco PIX firewall won’t allow any traffic out that doesn’t first go through the Squid proxy, so turning the proxy settings off on my iPhone would be a temporary fix at best. Nevertheless, to test my settings I disabled the proxy settings on the iPhone (under Settings > Wi-Fi and scroll all the way to the bottom). That did it—OF/iPhone was now able to synchronize with my laptop. Rather quickly, too, might I add, which is a definite improvement over the WebDAV setup I’d been using previously.

But I was still left with two problems: a) the firewall on my laptop was disabled; and b) the proxy settings on my iPhone were disabled. So I set out to fix those two issues.

Fixing the firewall should be easy, right? Just find out what port OF/Mac listens on and create a firewall rule to allow the traffic. It would be easy, except for the fact that the port on which OF/Mac listens changes every time the application launches. OmniGroup, if you’re listening: change this to a static port, PLEASE! Or at least provide some sort of hidden preference that would allow geeks like me to make it use a static port. As it stands right now, I had to use a rule that opens up a broad range of ports. That really, really stinks. OK, firewall issue resolved.

The proxy issue proves to be more challenging. There’s no way to configure the proxy to ignore the traffic; that has to be done client side. Unless the full-blown version of Mac OS X, there’s no option in the iPhone to ignore certain network ranges or certain DNS domains. But—and here’s the kicker—the iPhone does support automatic proxy configuration via a PAC file. So I create a very simple PAC file like this:

function FindProxyForURL(url, host)
{
 if (isInNet(host, “172.16.1.0″, “255.255.255.0″))
  {
  return “DIRECT”;
  }
 else
  {
  return “PROXY server.domain.com:3128″;
  }
}

The first round of testing didn’t go so well; the Apache HTTPd configuration on my server didn’t allow files with a .PAC extension. Oops! After fixing that problem, testing from my laptop went very well. A few seconds later, I had my iPhone reconfigured with the PAC file. And it worked! I was able to successfully synchronize OF/iPhone with OF/Mac while still maintaing access to Internet-based resources. And since the PIX firewall won’t allow traffic direct from the iPhone to the Internet, I know that the proxy is still involved in those connections. Reviewing the Squid proxy’s access logs also confirmed that the iPhone was not hitting the proxy during synchronization attempts.

Problem all solved, right? Well…not exactly. I left the PAC configuration on my laptop until this morning, when I fired up Adium. Bam! Adium throws an error message stating that it doesn’t support PAC files. I reconfigured my laptop back to my old configuration and testing the OF/iPhone-to-OF/Mac synchronization again, and it still worked. It appears that as long as the iPhone’s proxy configuration is correct, then the synchronization will work.

So, lessons learned:

• OF/Mac uses a dynamically assigned port on which it listens for synchronization requests. This means that users with an IPFW firewall configuration will have to open up a wide range of ports until OmniGroup gives us the option to statically assign a port. (Hint, hint…)
• HTTP proxy settings on the iPhone will interfere with OF/iPhone synchronization, but that can be solved with a PAC file as described above.

Other than this adventure, I am thus far quite pleased with the update to OF/iPhone. If you are unhappy with the earlier version—the most common complaint was speed, or lack thereof—you owe it to yourself to check out version 1.1. It’s much improved, in my opinion.

• OmniFocus for iPhone First Impressions
• OmniGraffle and OmniFocus Updates
• ipfw Rules for Bonjour
• Any iPhone App Recommendations?
• How Do Non-Geeks Fix Problems?

As a follow up to that article, I’ve been running some additional tests with a focus this time on the behavior of virtual machines (VMs) in configurations both with and without link aggregation. The results are very consistent with the findings from the previous set of tests, but with a few key items to keep in consideration when applied specifically to VMs.

Without Link Aggregation

As stated in the earlier article, using NIC teaming without link aggregation means the vSwitch is configured with one of these three load balancing settings:

1. Route based on the originating virtual port ID
2. Route based on source MAC hash
3. Use explicit failover order

The primary focus here is “Route based on the originating virtual port ID,” since that’s the default vSwitch setting and the recommended setting from VMware when not using link aggregation.

Just as all the VMware docs explain, the tests show that a VM will use only one uplink, regardless of how many different connections are involved, and it will stay on that uplink until the uplink fails, at which time the VM will be moved to a different uplink according to the NIC failover order configured for that port group or vSwitch.

There are, however, a few other things to consider:

• There is no guarantee that the VMs will be evenly distributed across the uplinks on a vSwitch or port group. Although I’ve seen references in the VMware documentation to indicate that VMs are balanced in some fashion (I could not find those references, however), real-world experience seems to indicate otherwise. In my tests, I had instances where four VMs were all “linked” (via their virtual port ID) to the same uplink.
• It’s unclear at what point VMware ESX creates the link between the virtual port ID and the uplink. In my tests, I rebooted the guest OS and power cycled the VM only to have it come back on the same uplink again. Only a VMotion off the server and back again caused a VM to move to a new uplink. I’ve been trying to track down more information on the timing of the association between the virtual port ID and the uplink, but have thus far been unsuccessful.
• There is no control over the placement of VMs onto uplinks without the use of multiple port groups. (Keep in mind that you can have multiple port groups corresponding to a single VLAN.)
• Because multiple VMs could be assigned to the same uplink, and because users have no control over the placement of VMs onto uplinks, it’s quite possible for multiple VMs to be assigned to the same uplink, or for VMs to distributed unevenly across the uplinks. Organizations that will have multiple “network heavy hitters” on the same host and vSwitch may run into situations where those systems are all sharing the same network bandwidth.

These considerations are not significant, but they are not insignificant, either. The workaround for the potential problems outlined above involves using multiple port groups with different NIC failover orders so as to have more fine-grained control over the placement of VMs on uplinks. In larger environments, however, this quickly becomes unwieldy. The final release of the Distributed vSwitch will help ease configuration management in this sort of situation, but that’s still out in the future yet.

VM Networking with Link Aggregation

Using NIC teaming with link aggregation means that the vSwitch is configured with “Route based on ip hash” and that the physical switch has been configured for EtherChannel or static 802.3ad/LACP.

<aside>By the way, static 802.3ad/LACP in the Cisco IOS world means the use of the “channel-group X mode on” command as opposed to “channel-group X mode active”; the first command uses static link aggregation whereas the second uses dynamic link aggregation. Static is supported; dynamic is not.</aside>

In this environment, the tests showed exactly what we expected; traffic from VMs was distributed across the uplinks in a dynamic fashion based upon the source and destination IP addresses. While some of these things may be common sense, there are a few things to consider:

• Depending upon the number of uplinks, it’s certainly possible that some traffic streams may end up getting hashed onto the same uplink. One a traffic stream is placed onto an uplink, it won’t move off that uplink until the flow is complete.
• The way in which outbound traffic from the VMs will be placed onto the uplinks won’t necessarily be the same as the way the physical switch places inbound traffic onto the uplinks. A good resource on how Cisco handles placing traffic onto members of an EtherChannel bundle is this page.
• Multiple connections to or from a VM might utilize multiple uplinks but aren’t necessarily guaranteed to use multiple uplinks.

Again, some of the points above are simple common sense, but they should be kept in mind nevertheless. If the workloads that are being hosted on VMware ESX are such that having more aggregate bandwidth would be beneficial, then using link aggregation is really the only way to do it. I suppose it would be possible to use NIC teaming inside the guest OS, assuming the VM was configured to use e1000 NICs, but I’ve never tested this configuration. (Anyone else tested it?)

• Understanding NIC Utilization in VMware ESX
• VMware ESX, NIC Teaming, and VLAN Trunking with HP ProCurve
• Setting VMware ESX vSwitch Load Balancing Policy via CLI
• ESX Server, NIC Teaming, and VLAN Trunking
• VMware HA Configuration Notes

This article today from InfoWorld seems to make the story much clearer:

With the new product, called Windows Server on WAAS, branch offices can host services locally including Active Directory, Microsoft Print Services, Microsoft Domain Name System Server and Microsoft Dynamic Host Configuration Protocol Server. That can improve performance for branch workers and reduce costs related to wide area network connectivity and branch systems management. An IT administrator can remotely manage the Windows Server functions using Microsoft System Center.
 
Cisco used embedded virtualization technology in its appliance to enable Windows Server 2008 to run on it.

Now, the real question is this: what “embedded virtualization technology” did Cisco use?

UPDATE: Based on the comments below, it looks like KVM is the technology Cisco chose to virtualize Windows Server on WAAS. Very interesting!

• Microsoft Virtual Server Management Tool Being Readied
• A Couple More Articles Published
• Cisco Investing in File Virtualization
• VIR353: Planning for Server Virtualization with Windows Server 2008 Hyper-V
• More on Hyper-V for the ESX Engineer

• My VMworld 2008 Schedule
• One More Tech-Ed Schedule Change
• My VMworld Schedule
• No Liveblogging of Lunch Session
• Small Tech-Ed Schedule Change

The session starts out with yet another overview of VDC-OS. This session will focus on technologies that fall into the vNetwork infrastructure vService. The agenda for the session includes networking I/O virtualization, virtualized I/O, and VMDirectPath.

Starting out, the presenter first defines what exactly networking I/O virtualization is. Networking I/O virtualization is providing muxing/demuxing packets among VMs and the physical network. VMs need to be decoupled from physical adapters, and the networking I/O virtualization must be fast and efficient.

Now that the audience has an idea of what networking I/O virtualization is, the presenter changes focus to talk about the architecture that provides I/O virtualization. First, there is a virtual device driver that can either model a real device (e1000, vlance) or that can model a virtualization-friendly device (vmxnet, a paravirtualized device). I’m glad to see the vendor refer to this as a paravirtualized device, since that’s really what it is.

Below the virtual device and virtual device driver, there is the virtual networking I/O stack. This is where features like software offloads, packet switching, NIC teaming, failover, load balancing, traffic shaping, etc., are found.

Finally, at the lowest layer, are the physical devices and their drivers.

The next discussion is tracing the life of a received packet through the virtualized I/O stack. After tracing the life of a packet, the presenter discusses some techniques to help reduce the overhead of network I/O. These techniques include zero copy TX, jumbo frames, TCP segmentation offload (large send offload and large received offload).

The problem with using jumbo frames, though, is that the entire network must be configured to support jumbo frames. Instead, the use of TSO (or LSO, as it is sometimes known) can help because it pushes the segmentation of data into standard size MTU segments down to the NIC hardware. This is fast, but even a software-only implementation of TSO can provide benefits.

(As a side note, it’s difficult to really understand the presenter; he has a very thick accent.)

On the receive side, the technology called NetQueue is intended to help improve performance and reduce overhead. When the NIC receives the packet, it classifies the packet into the appropriate per-VM queue and notifies the hypervisor. The presence of multiple queues allows this solution to scale with the number of cores present in the hardware. It also looks like NetQueue can be used in load balancing/traffic shaping, although I’m unclear exactly how as I didn’t understand what the presenter said.

Zero copy TX was discussed earlier (copy the packet from the VM directly to the NIC), but there was no discussion of zero copy RX. With NetQueue and VM MAC addresses being associated with the various queues, it’s also possible to do zero copy RX. The caveat: the guest can access the data before it is actually delivered to it.

The focus on the presentation now shifts to a discussion of VMDirectPath, or I/O passthrough. This technology initiative from VMware requires hardware I/O MMU to perform DMA address translation. In this scenario, the guest controls the physical hardware and the guest will have a driver for that specific piece of hardware. VMDirectPath also needs a way to provide a generic device reset; FLR (Function-Level Reset) is a PCI standard that provides this.

SR-IOV (Single Root I/O Virtualization) is a PCI standard that allows multiple VMs to share a single physical device. If I understand correctly, this means that VMDirectPath will allow multiple VMs to share a single physical device via SR-IOV. Part of SR-IOV is creating virtual functions (VF) that the guest sees and mapping those to physical functions (PF) that the physical hardware controls and sees.

Challenges with VMDirectPath include:

• Transparent VMotion: Because the guest controls the device, there’s no way to control device state, so VMotion won’t be possible. This is logical and fully expected, but certainly has an impact on the usefulness of this technology.
• VM management: Users are now placed back into the issue of managing device drivers into VMs based on the hardware to which they are connected.
• Isolation and security: A lot of the features provided by the hypervisor (VMsafe, MAC spoofing, promiscuous mode, VMware FT, etc.) are lost when using VMDirectPath.
• No memory overcommitment: Physical devices will DMA into the guest memory, but this requires that memory overcommit is disabled so that this works.

Although these limitations around VMDirectPath are significant, there still can be valid use cases. Consider appliance VMs or special purpose VMs, such as a VM to share local storage or a firewall VM, where technologies like VMotion or VMware FT aren’t necessary or aren’t desired.

Generation 2 of VMDirectPath will attempt to address the challenges described above. One way of accomplishing that is called “uniform passthrough,” in which there is a uniform hardware/software interface for the passthrough part. This allows a transparent switch between hardware and software from the hypervisor while the guest is not affected or even aware of the mode. This puts the control path under the control of the hypervisor, but bypasses the hypervisor for the data path.

This Gen2 implementation allows for migration because the mode is switched from direct to emulation transparently and without any special support within the guest OS.

Another way of implementing is described by Sean Varley of Intel. This method is called Network Plug-in Architecture. Most of the functionality in this solution is embedded inside the guest device driver, which typically would be VMware’s paravirtualized vmxnet driver. Sean underscores the need for SR-IOV support in order to really take advantage of VMDirectPath, because it doesn’t really scale otherwise.

This particular solution consists of a guest OS-specific shell and an IHV-specific hardware plug-in. The interface of the guest OS-specific shell will be well-known and is the subject of a near-future joint disclosure between Intel and VMware. The plug-in will allow various other IHVs to write software that will allow their hardware to be used in this approach with VMDirectPath.

This plug-in also allows for emulated I/O, similar to what ESX offers today, in the event that SR-IOV support is not available or if the user does not want to use VMDirectPath. Upon initialization, the guest OS shell will load the appropriate plug-in and (where applicable) create a VF that maps onto a VMDirectPath-enabled physical NIC.

Migration in this scenario is enabled because the hypervisor remains in control of the state of the shell and the plug-in at all times. The hypervisor can reset the VF, migrate the VM, and then load a new plug-in on the destination via the initialization process described earlier.

The key advantages of this particular approach are IHV independence, driver containment, and hypervisor control. This enables IHV differentiation and removes the VM management headache described earlier (VMs won’t need hardware-specific drivers). Hypervisor control is maintained because the SR-IOV split model of VF/PF is maintained, and the hypervisor controls plug-in initialization and configuration.

The session ends with a sneak preview demonstration of a migration using the plug-in architecture and VMDirectPath, migrating a VM between an SR-IOV-enabled NIC and a non-enabled NIC on a separate host. The presenter showed how the vmxnet driver loaded the appropriate plug-in based on the underlying hardware.

• TA2668: VMware ESX Architectural Directions
• PO1644: VMware Update Manager Performance and Best Practices
• VIR358: Hyper-V Architecture, Scenarios, and Networking
• Problems with 802.1Q
• VMworld 2007 IP-Based Storage Sessions

• VMware Fault Tolerance (FT), formerly “Continuous Availability,” (demoed at VMworld 2007, described in my liveblog here) provides real-time VM mirroring between two different hosts. If a host fails, the mirrored VM on the secondary host picks up automatically with no disruption to the users. Marathon Technologies is working on similar functionality for Citrix XenServer, and both companies are expected to deliver next year. If VMware wants a leg up on the competition, they need to deliver this first.
• The Distributed vSwitch enables administrators to define network settings at the cluster level, instead of on a host-by-host basis. This is huge for larger shops. Define your port group once, and you’re done.
• As has been pointed out elsewhere, Cisco is announcing the first third-party vSwitch for VMware ESX. Alessandro points out rumors that it will run NX-OS and will be a distributed vSwitch. In any case, it will certainly bring hard-core Cisco shops closer to embracing VMware as it will give them end-to-end control over the networking environment, all the way down to the virtual port level within any given VMware ESX host.
• vStorage Thin Provisioning will help on storage demands. I suspect this is just the use of thin provisioned VMDKs, but if anyone has any other information to share I’d love to hear it.
• Similarly, vStorage Linked Clones just brings to VMware ESX a feature that VMware Workstation and VMware Lab Manager have had for a while.
• VMware will finally enter the backup market with vCenter Data Recovery, which (to my understanding) will leverage VCB to provide a backup solution for the virtual infrastructure.

That’s quite an impressive list of features slated to be included in VDC-OS. What I’m also interested in seeing, though, is how the underlying components of VDC-OS—VMware ESX and VirtualCenter/vCenter—are going to change. I’ve seen rumors of 64-bit VMkernel and Console OS, and Duncan himself points out linked vCenters (which is quite cool, might I add). I suppose that will be part of the “Tech Preview” sessions that are going on later this week.

OK, that’s it for now; need to run off for another session. Stay tuned here and on Twitter for more information!

• VMware Consolidated Backup
• More on VMware ESX NIC Utilization
• Setting VMware ESX vSwitch Load Balancing Policy via CLI
• Recent Virtualization Links
• Virtualization Short Take #17

In this article, I’d like to discuss how to do the same thing, but using HP ProCurve switch hardware. The article is broken into three sections: using VLANs, using link aggregation (NIC teaming), and using both together.

Using VLAN Trunking

To my Cisco-oriented mind, VLANs with ProCurve switches are handled quite differently. Port-based VLANs, in which individual ports are assigned to one or more VLANs, allow a switch port to participate in that VLAN as either an untagged fashion or in a tagged fashion.

The difference here is really simpler than it may seem: the untagged VLAN can be considered the “native VLAN” from the Cisco world, meaning that the VLAN tags are not added to packets traversing that port. Putting a port in a VLAN in untagged mode is essentially equivalent to making that port an access port in the Cisco IOS world. Only one VLAN can be marked as untagged, which makes sense if you think about it.

Any port groups that should receive traffic from the untagged VLAN need to have VLAN ID 0 (no VLAN ID, in other words) assigned.

A tagged VLAN, on the other hand, adds the 802.1q VLAN tags to traffic moving through the port, like a VLAN trunk. If a user wants to use VST (virtual switch tagging) to host multiple VLANs on a single VMware ESX host, then the ProCurve ports need to have those VLANs marked as tagged. This will ensure that the VLAN tags are added to the packets and that VMware ESX can direct the traffic to the correct port group based on those VLAN tags.

In summary:

• Assign VLAN ID 0 to all port groups that need to receive traffic from the untagged VLAN (remember that a port can only be marked as untagged for a single VLAN). This correlates to the discussion about VMware ESX and the native VLAN, in which I reminded users that port groups intended to receive traffic for the native VLAN should not have a VLAN ID specified.
• Be sure that ports are marked as tagged for all other VLANs that VMware ESX should see. This will enable the use of VST and multiple port groups, each configured with an appropriate VLAN ID. (By the way, if users are unclear on VST vs. EST vs. VGT, see this article.)
• VLANs that VMware ESX should not see at all should be marked as “No” in the VLAN configuration of the ProCurve switch for those ports.

Using Link Aggregation

There’s not a whole lot to this part. In the ProCurve configuration, users will mark the ports that should participate in link aggregation as part of a trunk (say, Trk1) and then set the trunk type. Here’s the only real gotcha: the trunk must be configured as type “Trunk” and not type “LACP”.

In this context, LACP refers to dynamic LACP, which allows the switch and the server to dynamically negotiate the number of links in the bundle. VMware ESX doesn’t support dynamic LACP, only static LACP. To do static LACP, users will need to set the trunk type to Trunk.

Then, as has been discussed elsewhere in great depth, configure the VMware ESX vSwitch’s load balancing policy to “Route based on ip hash”. Once that’s done, everything should work as expected. This blog entry gives the CLI command to set the vSwitch load balancing policy, which would be necessary if configuring vSwitch0. For all other vSwitches, the changes can be made via VirtualCenter.

That’s really all there is to making link aggregation work between an HP ProCurve switch and VMware ESX.

Using VLANs and Link Aggregation Together

This section exists only to point out that when a trunk is created, the VLAN configuration for the members of that trunk disappears, and the trunk must be configured directly for VLAN support. In fact, users will note that the member ports don’t even appear in the list of ports to be configured for VLANs; only the trunks themselves appear.

Key point to remember: apply your VLAN configurations after your trunking configuration, or else you’ll just have to do it all over again.

With this information, users should now be pretty well prepared to configure HP ProCurve switches in a VMware ESX environment. Feel free to post any questions, clarifications, or corrections in the comments below, and thanks for reading!

• ESX Server and the Native VLAN
• VLANs on ESX with Nortel Switches
• VLANs and Port Groups
• Configuration for Protecting VMotion
• HP VirtualConnect Clarification

In VMware ESX 3.5 U2 (which users should be using if at all possible, now that it’s validated by Microsoft), the command to do this is vmware-vim-cmd:

vmware-vim-cmd /hostsvc/net/vswitch_setpolicy
–nicteaming-policy=loadbalance_ip vSwitch1

This command sets the vSwitch to use “Route based on ip hash”. To set the vSwitch back to “Route based on the originating virtual port ID”, use this command:

vmware-vim-cmd /hostsvc/net/vswitch_setpolicy
–nicteaming-policy=loadbalance_srcid vSwitch1

Obviously, users will need to replace vSwitch1 with the appropriate vSwitch that needs to be configured. Note that this command is a bit different than in earlier versions, which used vimsh.

I hope this is useful!

• More on VMware ESX NIC Utilization
• VMware ESX, NIC Teaming, and VLAN Trunking with HP ProCurve
• Understanding NIC Utilization in VMware ESX
• ESX Server, NIC Teaming, and VLAN Trunking
• Identifying ESX Server NICs in Blades