blog.scottlowe.org

Two of my most-used applications have been updated to new versions. OmniGraffle is now updated to version 5.1, and OmniFocus is now updated to version 1.5. (Funny, I just noticed how the versions numbers are reversed—5.1 and 1.5.)

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.

So, I’ve been searching for a good way to establish connectivity to the lab at my office for a while. My first attempt was to work with one of our CCIEs at the office to establish an IPSec-based VPN against a Cisco router at the edge of the lab network, but despite our best efforts we couldn’t get the IPSec VPN client I was using, IPSecuritas, to connect and authenticate. No amount of fiddling would make it work.

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.

A short while ago, I had a colleague in the blogging industry ask me if the reason I was writing “Short Takes” was because I was too busy to write in-depth articles. At the time, I told this colleague no, but now I’m wondering if I should change that answer…

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!

I’m sorry, folks, but I’m not going to have the time or the resources to publish an update to my existing instructions for integrating Solaris 10 into Active Directory. Quite some time ago I had posted that I planned on creating an update to the original instructions so as to incorporate some lessons learned, but it keeps get pushed aside for other tasks that are more important and more relevant to my day-to-day work. Rather than keep readers hanging on for something that will likely never appear, I’d rather just be upfront and frank about the situation. As much as I’d love to spend some time working on the Solaris-AD integration situation and documenting my findings, I just don’t have the time. Sorry.

After noticing a link I’d added to my Delicious.com bookmarks about a cheat sheet for Linux/UNIX, a reader shared with me a cheat sheet that he had created for VMware ESX. The cheat sheet can be downloaded here, and the reader’s weblog is available here. Thanks for sharing this information!

I’ve had this link sitting in my “Articles To Read” list for quite some time, but—to be perfectly honest—I’ve been just too busy to really do anything about it. Now that a hectic few weeks has wrapped up and I have a small breather before the next hectic few weeks, I wanted to comment briefly on Doug Gourlay’s discussion of FCoE versus MR-IOV.

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.

It looks like I may be able to blog about some of the content that was covered this week at NetApp Insight in LA after all. I’m still working out the details, but I hope to have things straightened out very soon. Stay tuned to this space for more details!

VKernel, whose SearchMyVM search-based management product I wrote about back at the beginning of September, is launching a community site called CompareMyVM. The site is expected to formally launch in early December.

The idea behind the site, according to VKernel, is to provide a means whereby users can share information on how they are allocating resources to VMs. The idea is that as users share how they are configuring certain VMs for certain workloads, that information may be very useful to other users who are looking for that sort of information. Not sure how much memory to allocate to a small Linux-based web server? CompareMyVM wants to be able to provide that information.

Clearly, the site will only be effective if lots of users contribute information and share their VM configurations. I’ve been out of town all week so haven’t had the opportunity to take a look at the site, but I do plan to do so very shortly. In the meantime, I’d encourage readers to have a look and feel free to report back here in the comments.

I started to mention this in Virtualization Short Take #22, but I felt that burying mention of a security notice amongst a bunch of other links just wasn’t the right way to bring it to everyone’s attention. I don’t want to be accused of crying wolf, but I do want readers to be aware of this sort of issues when they arise.

Via Infosecurity.us and Tarry Singh, I saw that VMware had released a security notification regarding a potential flaw in both the hosted products (VMware Workstation, Server, ACE, and Player) as well as ESX and ESXi. At the root of the issue is a potential flaw in the way that these products handle the Trap flag, and this potential flaw might lead to privilege escalation within the guest operating system. Yes, you read that right—a flaw within the host could lead to privilege escalation in the guest.

The full VMware security advisory, VMSA-2008-0018 (incorrectly listed as VMSA-2009-0018), provides full details on the specific versions that are affected and provides links to applicable patches for vulnerable products. Interestingly enough, the latest versions of the hosted products—VMware Workstation 6.5, VMware Server 2.0, and VMware ACE 2.5—are not affected.

If you aren’t keeping your VMware ESX hosts patched using Update Manager, now might be a good time to start.

Despite the fact that I’m out of town this week at NetApp Insight, I wanted to go ahead and get out the latest installation of Virtualization Short Takes—my sometimes-weekly collection of interesting or useful links and tidbits.

• Much ado has been made about VMware’s acquisition of Trango and the announcement of VMware MVP (Mobile Virtualization Platform). Rich Brambley has a great write-up, and I completely agree with Rich and Alex Barrett about what this really means: don’t expect to see Windows XP on your smartphone any time soon. Alex said it best: this is virtualization, not emulation, and Windows XP doesn’t run on ARM.
• I’m curious—how many people agree with my comments in Alex’s article about the Citrix ICA client for the iPhone. Is there any real, actual value in being able to access a Windows session from your iPhone? I tend to think not, but it would be an interesting discussion. Speak up in the comments.
• Duncan points out that the issue with adding NICs to a team and keeping them all active—the workaround for which required editing esx.conf—has now been fixed in ESX 3.5 Update 3. It’s now possible to add NICs using esxcfg-vswitch and there’s no need to edit esx.conf. Excellent!
• If you haven’t yet checked out Leo’s Ramblings, go give it a look. He’s got some good content. It’s worth subscribing to the RSS feed (I did).
• Rick provides a helpful tool to resolving common system management issues with VMware Infrastructure. Thanks, Rick!
• Regular readers may recall that Chad Sakac of EMC and I had a round of VMware HA-related posts a few months ago (check out the VMwareHA tag for a full list of VMware HA-related posts). As part of that discussion there was lots of information provided about Service Console redundancy, failover NICs, secondary Service Console connections, additional isolation addresses…all sorts of good stuff. Duncan joined in the conversation as well with a number of great posts, and has been keeping it up since then. His latest contribution to the conversation is a comparison of using failover NICs vs. using a secondary Service Console to prevent VMware HA isolation response. According to the documentation, using a secondary Service Console can help reduce the wait time for VMware HA to step in should isolation actually occur. Good stuff, and definitely worth some additional exploration in the lab.
• As a sort of follow-up to the discussion about using NFS for VMware, this VMware Communities thread has some great information on why the NFS timeouts should be increased in NetApp NFS environments. If you’re like me, you like to know the reasons behind the recommendations, and this thread was very helpful to me. Let me also add that we’ve recently started recommended to customers to increase their Service Console memory to 800MB when using NFS, so that might be something to consider as well.
• Need to change the path of where Update Manager stores its patches? Gabe shows you how here.
• Eric Gray of VCritial explores the question: what would things be like without VMFS? Well, as he states, you can just ask a Hyper-V user, since Hyper-V doesn’t (yet) have a shared cluster filesystem. Yes, that will change in 2010 with Shared Cluster Volumes in Windows Server 2008 R2 and Hyper-V 2.0. I know. Or you can just add Melio FS from Sanbolic today and get the same thing. This is not anything new to me; I discussed this quite extensively here and here. Now, what would really be interesting is for VMware to work with Sanbolic to co-develop a more advanced version of VMFS that eliminates the SCSI reservation problems…
• Need a nice summary of the various network communications that occur between different components of a VI3 implementation? Look no further than right here. Jason’s site is another one that’s worth adding to your RSS reader.
• If you really like living on the edge, here’s a collection of some RPMs for VMware ESX 3.5. Keep in mind that installing third-party RPMs like this is not recommended or supported…
• Andy Leonard picked up the DPM video by VMware and is looking forward to DPM no longer being experimental. What he’d really like, though, is some feature to move his VMs via Storage VMotion and spin down idle disks. Andy, I wouldn’t hold my breath.
• If you are a Fusion user (if you own a Mac and need to run Windows, you should be a Fusion user!), this hint might come in handy.
• Eric Siebert has a good post on traffic flow between VMs in various configuration scenarios—different vSwitches, same vSwitches, different port groups, same port groups, etc. Have a look if you are at all unclear how VMware ESX handles traffic flow.

That does it for this round. Speak up in the comments if you have any interesting or useful links to share with other readers. I’d also be interested in readers’ thoughts on the whole Citrix on the iPhone discussion—will it really bring any usefulness?