The second part of the session delved into some NetApp-specific information:

• NetApp has a PVR-only tool called HyperVIBE that helps to coordinate storage array Snapshots with the hypervisor, providing VSS integration to quiesce the VMs before taking a Snapshot on the NetApp array. This is only supported on Server Core and requires a special release of SnapDrive 6.0. (It’s only available via PVR, so don’t go searching the NetApp web site for a free download.)
• The various members of the SnapManager family—SnapManager for SQL, SnapManager for Exchange, and SnapManager for Sharepoint—are all fully supported on Hyper-V, but only for iSCSI LUNs.
• NetApp SnapDrive 6.x is supported both on Hyper-V hosts as well as guest VMs. On the parent partition, it can manage both Fibre Channel LUNs and iSCSI LUNs; on a child partition, it can only manage iSCSI LUNs.
• Version 5.x of the Host Utilities Kit is strongly recommended for use with Hyper-V, and supports Fibre Channel, iSCSI, and mixed connections. It runs on either the parent or child partition, although it seems to me that it would only make sense to run it on the parent partition.
• Data ONTAP DSM 3.2R1 is the supported and recommended DSM for MPIO support with Hyper-V. On the parent partition, it supports and manages Fibre Channel, iSCSI, and mixed paths, but in a child partition it only supports iSCSI paths. It’s also only supported in child partitions running a server OS (so no Windows XP or Windows Vista support in child partitions).

For more information, readers can refer to TR-3701 and TR-3702. Note that updated versions of TR-3702 are expected to be released in the coming months to address additional product integrations.

• Storage Protocol Performance Whitepaper from NetApp
• A Collection of Hyper-V Links
• Proving VMware Over NFS
• VIR358: Hyper-V Architecture, Scenarios, and Networking
• VIR367: Hyper-V Security and Best Practices

So, over the next few days, look for blog posts about some of the sessions that I attended during NetApp Insight. They all be tagged Insight2008, in case you would like to browse them that way.

Note that a fair number of these sessions discuss timelines or targeted feature sets for future products. None of the information I post here should be taken as any sort of commitment from NetApp as to when a product will be delivered or what features it will contain. Just like any other company, things still in development may change before they are released. (No, NetApp did not ask me to say that—in fact, they are not reviewing this content at all. I’m just trying to help good sense prevail.)

• At NetApp Insight This Week
• VMworld 2006 Day 3 and Wrap-Up
• NetApp Insight Posts
• Comparison of WAFL and ZFS
• NetApp Suing Sun over ZFS

• Any iPhone App Recommendations?
• Apple iPhone
• ActiveSync on the iPhone
• OmniFocus for iPhone First Impressions
• The Adventures of OmniFocus Bonjour Sync

(Yes, I know the holiday isn’t until Thursday, but I’m leaving with my family for a short out-of-town vacation and wanted to go ahead and wish everyone a happy Thanksgiving before leaving.)

To those readers who do not celebrate Thanksgiving but do celebrate something similar, I wish you a very enjoyable holiday as well.

• Happy Thanksgiving!
• Happy Thanksgiving!
• A Short Break
• Happy July 4th!
• Finally Back From Vacation

The OmniGraffle update brings one feature that I have especially been anticipating: the ability to import Windows Metafile images in Visio diagrams. This extremely useful feature, first hinted at here back in March, will tremendously ease Visio compatibility and should open up lots of Visio shapes to be used in OmniGraffle that previously were not usable. I tested this functionality this morning on a complex NetApp-VMware-IBM BladeCenter diagram from a co-worker, and it works as advertised. Future tests will see how well this functionality works in bringing Visio stencils into OmniGraffle. This is a free upgrade for current OmniGraffle 5.0 customers.

The OmniFocus update brings this GTD application’s official 1.5 release, and with it synchronization with OmniFocus for iPhone. Now that both the Mac and iPhone versions support Bonjour sync—although this is not without its own travails—I find myself using them more and more. If you’ve been following the pre-release versions of OmniFocus (the so-called “sneaky peeks”) then you won’t find many new features in this official release, but users who have been waiting for the official release to upgrade are in for a real treat. As with OmniGraffle, this OmniFocus upgrade is a free upgrade for existing OmniFocus 1.x customers.

• OmniFocus for iPhone First Impressions
• Any iPhone App Recommendations?
• NetApp OmniGraffle Stencils
• The Adventures of OmniFocus Bonjour Sync
• OmniGraffle Just Keeps Getting Better

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

In any event, here’s my list of links and tidbits that I found interesting, amusing, or useful over the last week or so. Enjoy!

• Eric Sloof of NTPRO.NL points out that VMware has updated their best practices to “allow” the placement of VM swap files on NFS, rather than recommending VMFS. Does anyone have a link to the VMware KB article with those updated recommendations?
• Edward Haletky points out a process for performing “secure P2V” operations. Because the P2V process generally involves network communications with VirtualCenter and/or the VMware ESX Service Console, a straight P2V process would cross security boundaries. Edward’s phased approach helps with that issue.
• Into PowerShell, but finding the process of modifying Offload Policies too difficult? This should help out significantly.
• Expanding upon some earlier work, Rick has added “Resolution Paths” to common network issues and common licensing issues. Excellent work!
• Leo provides some good information on monitoring VI3 with Zenoss.
• Via Alessandro and Ben, I learned about the HVRemote tool for automating the configuration steps for enabling remote management of Hyper-V. HVRemote was created by John Howard and more information is available here.
• Symbolik shares his experience in troubleshooting a PSoD (Purple Screen of Death) with VMware ESX. In his case, the issue turned out to be related to NICs, but it’s nice to see that he was able to zero in on the issue and get it resolved.
• Larger installations with lots of LUNs and an active/active SAN may find this script published by Duncan very helpful. The problem that this script addressed underscores the need for robust multipathing support in VMware ESX such as that which will be allowed via the new vStorage APIs.
• Need more information on Enhanced VMotion Compatibility (EVC)? Both Gabe and Rich have recently tackled the issue on their own blogs. If you’re wondering what EVC is, the short answer is that it’s a way to automate this process in a supported fashion.

That’s it for this time around. Thanks for reading!

UPDATE: Eric Sloof responded about the updated recommendations regarding VM swap files. The new information was disclosed in session TA2784 at VMworld 2008. See slide 38. Thanks for the information, Eric!

• Recommended ESX Service Console Partitioning
• Virtualization Short Take #22
• I’m Honored, Too
• Virtualization Short Take #19
• Virtualization Short Take #20

• Solaris-AD Integration Update Coming
• Solaris 10-AD Integration, Version 3
• Samba in Solaris-AD Integration
• Some Things I’m Working On
• Pending Articles

• Tags, RSS, and Other Site Changes
• Bookmark Spam?
• An Interesting Viewpoint
• NetApp ONTAP Simulator and ESX Server
• XC Connect

First, some background: For those that aren’t familiar, FCoE is Fibre Channel over Ethernet, a T11 standard for running Fibre Channel Protocol over Ethernet, specifically 10 Gigabit Ethernet. More information on FCoE is found here. MR-IOV is Multi-Root I/O Virtualization, a PCI SIG specification for using PCI Express (PCIe) to connect and share multiple devices. More information on MR-IOV can be found here. MR-IOV is a multi-server extension to Single-Root I/O Virtualization, or SR-IOV.

Like Doug, I’ll put in a disclaimer that I haven’t read the report to which he’s referring in his article, either. However, as an individual who has done some research on the topic of I/O virtualization, I will say that anyone who compares FCoE to MR-IOV is comparing apples to oranges. These two technologies, in my mind, are designed to address two different problems.

FCoE provides the ability to use a single physical transport—10 Gigabit Ethernet, in this case—for Fibre Channel Protocol (FCP) as well as TCP/IP, iSCSI, and other Ethernet-borne protocols. This allows for the creation of a unified fabric, a single physical transport that carries all the various kinds of traffic that Ethernet-based Local Area Networks (LANs) and Storage Area Networks (SANs) carry separately today. Via the IETF Converged Enhanced Ethernet (CEE) standard—adopted by Cisco as Data Center Ethernet^TM—FCoE will ultimately have the same low, predictable latency and error-free operation that FCP enjoys today. FCoE is not, however, designed or architected to do anything other than allow FCP to run over Ethernet. It’s not intended to be a server interconnect technology. (Unless I’m missing something?)

MR-IOV, on the other hand, is intended to play in the server interconnect field. Its purpose is not to allow FCP to run over Ethernet, or to allow FCoE, iSCSI, and other TCP/IP protocols share the same physical connections. MR-IOV’s purpose is to allow multiple servers to share PCIe-based devices, like a FC Host Bus Adapter (HBA), or an iSCSI HBA, a 10 Gigabit Ethernet network interface card (NIC), or a video capture card. MR-IOV is intended to provide I/O virtualization, regardless of what type of I/O that might be. As long as the I/O runs across a PCI Express bus, MR-IOV comes into play.

I’ve heard multiple people refer to FCoE as an I/O virtualization technology, but I just don’t agree. FCoE only applies to FCP over Ethernet. It doesn’t apply to iSCSI. It doesn’t apply to video traffic, or audio traffic, or HTTP traffic. It only applies to FCP over Ethernet. While I might allow that FCoE does allow for a form of virtualization, by virtualizing the physical transport beneath FCP, I would not call it I/O virtualization. Further, FCoE and MR-IOV are complementary. You could use MR-IOV to share a single Converged Network Adapter (CNA), which provides FCoE and 10 Gigabit Ethernet functionality, among multiple servers. In this situation, what’s providing the I/O virtualization: MR-IOV, which is allowing multiple servers to use a single I/O card, or the CNA, which is putting the traffic onto the converged fabric?

I’m probably missing something huge here, some vital piece of information that would make sense why FCoE and MR-IOV would be considered competitive standards/specifications. Without that information, though, it just doesn’t make any sense to me to compare these two different yet complementary technologies. Someone want to enlighten me?

UPDATE: I’ve corrected my use of “Data Center Ethernet” to Converged Enhanced Ethernet (CEE) when referring to the IETF standard. As correctly pointed out in the comments, Data Center Ethernet^TM is a Cisco trademarked term referring to their implementation of CEE.

• Optimizing iSCSI Traffic with ESX
• Another Round with iSCSI and ESX Server 3
• Storage Protocol Performance Whitepaper from NetApp
• VIR250: Advanced Storage Connectivity for VMs
• Sanrad Configuration Basics