I Might be Moving back to VMWare
Back in the late 90s I saw an ad for a free trial of something called VMWare workstation. Seeing that I’d been playing around with Wine and DOSEmu (Better alternatives today are DOSBox for games and FreeDOS for legacy apps) on Linux to gain access to some legacy applications, I assumed this was just another emulator more like Bochs. I downloaded the limited trial, installed it on my laptop and my jaw dropped.
Until this time, I was used to slow emulation where doing something like playing a 3D game (software accelerated) or playing a video was just not reliable or usable. But VMWare Workstation was different. It was also fairly inexpensive since they were new. After spending a few weeks with it, I was convinced that it was not emulation, but something completely different. I paid the price to own a copy and was in OS flipping nirvana.
My laptop running Redhat 7 could also run Windows 2000 on VMWare at what felt to be at least 80% of normal speed. I was able to play Unreal, watch music videos in MPEG and AVI formats and… do it all without a hiccup while doing the same things in Linux at the same time. I brought it into my then new employer’s offices to show it around. People were impressed.
As the price climbed, I couldn’t afford to keep up with newer versions and then I discovered the freebies like QEMU and Xen. Those worked nearly as well, but weren’t as slick. No matter for me because I like working closer to the metal anyway. The focus eventually became Xen (installing and building from source on top of Fedora, then Gentoo). When the time came to implement a new web based groupware system, Zimbra, the free Xen wasn’t up to the task. I did some more research and found an excellent commercial product based on Xen called Virtual Iron.
Virtual Iron really had everything right in terms of their implementation of the management. The management server could be run on Windows or a few supported flavors of Linux. It provided a central repository of ISOs to use for initially installing your VMs and a boot image that each of your x86_64 virtual machine hosts would boot off of via TFTP. The beauty of that is that you didn’t need to install anything on the virtual machine hosts at all. They just boot up with the custom Xen and XenLinux kernels and they’re ready to host whatever VMs you throw at them. Everything was there including hiccup free live migration.
This past Summer, Oracle acquired Virtual Iron and it currently looks like they plan to turn it more into a virtual desktop hosting solution to complement their Oracle VM product. At this time it is unclear to me how many of Virtual Iron’s former (very rockin’) support and engineering staff they retained. At one point it even looked like they might bury the product entirely, but a recent issue of Information Weekly indicates that there might still be life left in it. However, the time came for me to re-evalute virtualization.
Over the past few months as time has allowed, I’ve been investigating many of the options available for virtualization. Since my VMs are all Linux, that means I have a lot of options ranging from free/libre (as in speech, not beer), free of charge (but pay for support), or ungodly expensive. I also have to factor in support from HP for the virtualization platform which narrows the field a little. So right now it looks like it’s between Novell/Suse Enterprise (can host or be virtualized with near bare metal performance on HyperV), Redhat Enterprise, Centos, Ubuntu Server 9 + KVM or Xen, and VMWare.
This is where it gets interesting. When I first went over to the Xen side of the table, VMWare ESX and GSX were the server platforms and they were extremely expensive. ESX was unique when it came out because it was the first virtualization product for the x86 platform that didn’t require a full OS running under it. It was a hypervisor. The Xen microkernel, offered essentially the same thing, only it was free if you wanted to make the minimal investment of time to build it from source. Seeing that kernel compilation is something of a breeze for me, I gave it a try and was duly impressed.
But, VMWare didn’t stop there. They have an advantage that I don’t believe Xen is yet positioned to compete with. They can over commit your server’s RAM in some very interesting ways. Of course, anyone familiar with Xen is aware of how you can “balloon”  RAM for your Linux “guests”  If you assigned only 256 megs to a guest and now you need 512, you can use the ‘xm’ utility to resize the amount of RAM that guest has. If you’re paravirtualized, which I used a lot initially, the change in the guest is immediate. As a result you can move RAM between VMs as the demands dictate.
VMWare can also do this. But the coolest thing that VMWare can do that others can’t yet is to share similar areas of RAM between multiple VMs. As they point out on their marketing site, this allows for much more efficient use of RAM. Where products that are based on Xen like Citrix or MS HyperV are limited by how much RAM is on the host machine, VMWare can run many more VMs on the same hardware. On their example server with 4 gigs of RAM, they could only run seven and six 512 meg Windows XP VMs compared to VMWare’s 20 VMs. This is because the system copies portions of the first VMs running image that are the same on successive VMs. It then keeps track of changes to maintain independent functionality.
They argue that while they might cost more you get a lot more VMs for your dollar. And they’re right. So, I’ll be eager to see this in action as I test the various VM technologies. I want the best one I can find, and VMWare is very interesting right now.
 The Obsessively Compulsive blog is really excellent for virtualization info. I’ve followed it on and off for a while, it never disappoints.
 Guest is the wrong terminology in Xen parlance, but it will suffice for this blog post.
Filed under: Computer Basics, Computer Technology, Main | 1 Comment