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

Bluebear’s Kodiak!
Bluebear’s Kodiak, what’s all the fuss about…
Kodiak 0.02 coming out real soon…

That’s not to mention coverage by virtualization.com, Reuters.com, and numerous other bloggers, experts, and analysts.

But where is Bluebear headed with Kodiak? What is their vision? Well, I don’t speak for Bluebear, but I did want to share some insight I’d gathered during a conversation with one of the Kodiak developers. I was curious to know how VMware’s announcements of cross-platform vCenter Server and cross-platform VI Client at VMworld 2008 would affect Kodiak. Perhaps because of VMware’s market leadership, most people see Kodiak as only a cross-platform VI replacement. The truth is, according to my information, Kodiak’s true value lies elsewhere. While it can be viewed as a VI Client replacement, and while it does bring cross-platform functionality to the table, there’s more to it than just that. Thus, cross-platform support by VMware—while sorely needed for quite some time—shouldn’t really impact Kodiak all that much.

So what is the value of Kodiak beyond cross-platform support? Good question! Here’s a couple of points I gathered from of our conversation:

• Multi-hypervisor management: One stated goal for Kodiak has always been to provide the ability to manage multiple, different hypervisors—not only ESX and ESXi, but also Xen, VirtualBox, etc. This is an area that only Microsoft is dabbling in with SCVMM, which will manage Hyper-V and ESX (via VirtualCenter only). Kodiak can manage ESX directly or via VirtualCenter.
• Management via visualization: I don’t know if this is what drove Bluebear to use Adobe AIR or if it’s a result of using Adobe AIR, but the idea behind managing virtualization with Kodiak is more through visualization than anything else. Bluebear wants users to be able to respond quickly to potential issues by making it possible to see those potential issues instead of waiting for a notification or an e-mail that something’s wrong.

I’m sure that Bluebear has all sorts of super-secret stuff in the works that will further differentiate their product from VMware’s cross-platform VI Client, even though the two products aren’t intended to directly compete.

And, of course, this doesn’t take into account Bluebear’s hardware side, aka Koala, which doesn’t get nearly the same amount of attention as Kodiak. Personally, I’m kinda hoping that the Koala will end up affordable enough for me to pick one up, as I could surely use it to host various virtual servers at home for media streaming, home automation, etc. But I digress…

Anyway, I think I have a pile of beta invites for Kodiak, so if anyone is interested post a comment here and I’ll see what I can do. Then you can take a look at the product yourself—keeping in mind that it is a very early beta—and see what you think about the future of Kodiak.

• Kodiak Continues to Develop
• Bluebear and Kodiak
• VirtualCenter Patch Released
• Other VMworld 2008 Resources
• Mac RDP Client Wishlist

• I’m working on an article discussing when to use various NIC teaming configurations with VMware ESX. There are some significant repercussions here for a variety of network configurations, but especially so for configurations involving IP-based storage (iSCSI or NFS).
• I’m finally wrapping up an article on the Xsigo I/O Director. I’ve been working a Xsigo VP780 in the lab for quite some time, and this article will provide a brief overview along with some tips and tricks.
• I received word from HP that I should be getting a ProCurve switch in my lab soon, so that means I can provide a ProCurve-oriented version of this NIC teaming and VLAN trunking article.
• I have some notes on using NetApp Open Systems SnapVault (OSSV) in conjunction with VMware ESX that I plan to post here as well.

New versions of the Linux and Solaris AD integration articles are on the way as well, starting with an update of the Solaris instructions to accommodate Solaris 10 Update 5 and Windows Server 2008.

If there’s anything else you’re interested in seeing, let me know in the comments. Thanks for reading!

UPDATE: The NIC utilization article is available here.

• Some Things I’m Working On
• Articles in Progress
• NetApp OSSV with VMware ESX Server
• Pending Articles
• A Couple More Articles Published

In the tests described in the paper, researchers used virtual machines on Xen 3.0 (the open source hypervisor not the commercial XenServer product, as far as I can tell), VMware Workstation 5.5, and “Open Solaris 10” (quotes mine). As pointed out in the paper, these three environments represent paravirtualization, full virtualization, and OS virtualization (or containers). I’m not sure if the researchers actually meant OpenSolaris; I suspect not since that’s a very recent release. Instead, I believe they probably just meant Solaris 10. On Xen and VMware Workstation, both running under Linux, they used Linux-based VMs; on Solaris, they used additional instances of Solaris. Each VM or instance ran Apache 2 and was tested using physical clients to connect to the HTTP server in each VM.

The results are interesting; VMware showed the best protection of well-behaved VMs from a misbehaving VM, followed by Xen with Solaris Containers providing the least protection. The level of protection was tested using a memory consumption stress test, a CPU stress test, a disk I/O stress test, and a network I/O stress test. I’d encourage you to have a look at the full paper for all the details.

These results are very interesting, but I wonder how much the results would change if we were to use VMware’s ESX server product line instead of one of the hosted products like VMware Workstation? As a product representative of “full virtualization” solutions, I’d be curious to know if the results seen with VMware Workstation were also seen with ESX.

In any case, the results are a validation of what we, as consultants, have been talking about: full virtualization provides the best isolation of well-behaved workloads from ill-behaved workloads, preventing a workload in one VM from affecting other workloads due to mishandling of CPU, RAM, disk, or network resources. As the researchers conclude in the paper, “…it is clear that VMware completely protects the well-behaved VMs under all stress tests. Its performance is sometimes substantially lower for the misbehaving VM, but in a commercial hosting environment this would be exactly the right tradeoff to make.”

• A Few More Quick Thoughts on Fusion
• Samba in Solaris-AD Integration
• VMworld 2006 Day 2 Keynote
• Virtualization Short Take #1
• Installing VMware Workstation on Ubuntu

• Via Eric, I learned that vimsh has morphed into vmware-vim-cmd in version 3.5. Xtravirt’s updated document can be found here.
• Via Duncan, it looks as if a number of patches for ESX/ESXi 3.5 have been released. Time to put Update Manager through its paces…
• As several other bloggers have mentioned, VMware is now discussing in much greater detail the VMware Certified Design Expert (VCDX) certification. I suspect that the BC/DR and VI architectural workshops that are taking place at Partner Exchange this week—which incorporate a fairly intensive review and presentation process—are prepping professionals for the rigors they will have to endure to achieve VCDX. Bring it on!
• Sys-Con Media—which has republished a couple of my articles—published this interesting article from a KVM developer regarding the placement and architecture of I/O and I/O drivers in various virtualization solutions. Of course, he feels that KVM is the best, but that’s not necessarily surprising.
• Author David Davis has published a brief blog entry at SearchVMware.com that summarizes the use of NIC teaming and load balancing with VMware ESX Server. This blog post is particularly useful since it references some of my own content.

In a future post, I’ll probably delve into more detail an interesting and thought-provoking article from DCS titled “Microsoft Unveils GSNW 2.0″. It’s an interesting take on the (possible) repetition of history. In the meantime, I’d love to hear other people’s thoughts on this article—go read it, then come back here and add your thoughts in the comments below.

• VMware Partner Exchange Starts Tomorrow
• Partner Exchange Wrap-Up
• Virtualization Short Take #6
• Virtualization Short Take #11
• At NetApp Insight This Week

Finally, I would like to share one registry change that we’ve found to be necessary in our AD integration. By default, the MS LDAP server only returns 1,000 results. As a university department with more than 1000 active students, this limitation has caused us some frustration.

This KB article shows how to increase the number of results returned in a query: http://support.microsoft.com/kb/315071

We recently set MaxPageSize to 5,000. I don’t know if this will
introduce additional problems down the road, but at least it lets me fully enumerate all our AD users from a Linux machine with `getent passwd`.

If you have an Active Directory domain with more than 1,000 users in the DN specified in your LDAP configuration, then this is a Registry change you’ll want to investigate. Otherwise, you could find that your UNIX/Linux servers aren’t able to fully enumerate all the users in the domain.

Thanks, Scott!

• Local Logins Refused in AD Integration Scenarios
• Using Samba in Linux-AD Integration
• One Potential Issue in AD Integration Scenarios
• LDAP Signing in AD Integration Situations
• Linux-AD Integration With Windows Server 2003 R2

It’s very cool technology, and it’s also very exciting to see VMware bringing this technology to VMware Workstation. I hope that VMware also takes some of the new Unity features—like the badge that helps identify which windows belong to a VM and to which VM they belong—and backport that to future versions of Fusion as well. Of course, I’d love to see all of Workstation’s functionality ported over to Fusion, but that’s just me.

There’s more information on Workstation’s new Unity functionality from Christian Hammond, a VMware developer, on his blog.

• A Few More Quick Thoughts on Fusion
• Unity: Real or Rumor?
• Unity: Definitely Real!
• Workstation 6.5 and Server 2.0 Released
• VMware Fusion 2.0 Beta 1

We traded e-mails back and forth for a while, and eventually he found the solution himself:

We work with a locked down version of OSs and in this case a domain policy on the Windows server was preventing the RHEL machines from accessing account info.  The policy was “Domain controller: LDAP server signing requirements” which was set to “Require signature.”  When I changed this setting to “None” it worked great.

This is good information and important to keep in mind; I’ll be sure to incorporate this into the next revision of the Linux-AD integration instructions. (No, I don’t have a timeframe on when that will be!)

In the meantime, if anyone has a workaround for this problem that will allow LDAP to work with signatures enabled or required, I’d love to hear it. Speak up in the comments below!

• Using Samba in Linux-AD Integration
• CentOS 5 Active Directory Integration Problem
• LM and NTLM Authentication in AD Integration
• Next Integration Task(s)
• A Couple Cool Mac Discoveries

If you were like me, you may have been wondering exactly how Cisco was putting KVM to use. No need to wonder any longer! Colleague and fellow blogger Colin McNamara has written up a detailed and in-depth discussion of the ASR1000 and how it uses KVM to provide virtualized instances of IOS-XE. Colin also discusses the role of the QuantumFlow processor and, believe it or not, the role of Popeye and Spinach. (Go read the article. It will make sense when you’re done.) Nice work, Colin!

• Another ePlus Blogger
• VMware Addressing Virtual Security Concerns
• Virtualization Short Take #5
• Virtual Mac OS X
• Second VDI Article Published

The book is subtitled “A fast and practical guide to supporting multiple operating systems with the Xen hypervisor,” and it does live up to that subtitle.  The book very quickly moves into some hands-on exercises using a Linux host and the open source Xen hypervisor.  The exercises are fairly pertinent to the topic being discussed, and I especially liked the “What just happened?” sections after each hands-on procedure.  In those sections, the author breaks down the steps, the intended results, and the reasoning behind the procedure.  In my view, that’s a very helpful way to build understanding of the product.

My only complaint is—as I mentioned earlier—that English appears not to have been the native language for the author and/or editors.  The wording sometimes gets in the way of the content, making it more difficult than it should be to understand what the author is trying to say.  I would also say that I don’t think the book is worth the $40USD price tag that marked on the back.  At only 127 pages, $40 seems a bit steep.

Those issues aside, I found the book to be helpful in understanding Xen and some of Xen’s concepts.  I wouldn’t necessarily recommend this book to people who are both new to virtualization as well as new to Linux, as the material assumes a certain level of knowledge and experience with Linux.  Otherwise, if you have some Linux experience and want to get started with Xen, this book would be a good place to start.  (Just try to find the book on sale.)

• My review of “Linux in a Windows World”
• Book Review: VMware ESX Server in the Enterprise
• New Book on Linux-Windows Integration
• VI Toolkit for Windows in Beta
• My New Job