Teachers

Virtual Machines vs Parallel Installations

I spent the entire day today in the realm of proprietary software setting up my MacBook laptop to run Windows XP Professional via Bootcamp. Having now used Virtual Machines and Parallel/Dual-Boot installations on a couple of machines I wanted to take a few minutes to share my experiences and thoughts on the subject.

For those of you not familiar with the concepts, Virtual Machines or vmware and parallel installations are two different methods of running multiple operating systems from a single computer. This can be done either on a desktop or on a laptop and has both open source or proprietary options.

The ultimate decision of which option to go with will depend greatly on the individual’s usage habits and preferences. In my case I’ve grown to appreciate the advantages offered by parallel installations over vmware.

VIRTUAL MACHINES

Virtual machines, or vmware, are an innovation that enables you to run one operating system within another. This process relies on the presence of a vmware program, such as VMware Fusion for Mac, or VirtualBox for Linux, and creates an instance of a “guest” OS that can be booted from within the “host” OS.

In the case of both proprietary and open source options, you begin by first installing the virtual machine software. Once this has been done you create a new virtual machine within the Vmware program. The steps to add the guest OS will depend on the Vmware software, but generally speaking there will be a few steps involved in which you identify what the host machine will be (Linux, Mac, or Windows) and designate how much RAM you wish to make available.

Once this has been done the the bulk of the process is extremely similar to that of a standard installation on a brand-new machine..

When you want to login to the guest OS, it’s just a matter of loading the Vmware program and selecting the operating system from the list of available options.

Advantages: Virtual machines give you access to two operating systems at once, and therefore expand the available functionality you have access to. Often times software is not available for all platforms, so use of virtual machines would enable Mac Users to run Microsoft Outlook for example; or Linux users to run Adobe Photoshop, or RPG games.

Virtual machines can also be moved or deleted exceptionally quickly because from the perspective of the host machine they are just one large file. The Instance of Windows XP I had previously installed on my MacBook was a single 25 GB file for example.

A Note on WINE: In the case of Linux there is a third option that I haven’t discussed here, and that is WINE. To the best of my knowledge WINE stands for “Wine Is Not an Emulator” and enables you to run Windows software without actually installing the operating system itself. Like virtual machines use of WINE requires the installation and configuration of the software, but once this has been done you can run a variety of different software packages from within Linux.

VMware for evaluating new systems: One of the key benefits of virtual machines – which I continue to use – is as a quick way to evaluate new operating systems and Linux distributions. I am constantly tinkering and test driving new distributions in a never ending quest for new and interesting features. By installing new OS test beds as virtual machines I’m able to quickly and easily explore them without making any fundamental changes to my system.

If I decide I don’t like the OS, I can delete the virtual instance without any adverse impact to the host machine.

Disadvantages: Due to the nature of the technology, use of Vmware represents extra burdens on your system than exist normally because you are using the same limited resources to run two operating systems. As a result programs on the host machine will not run as quickly.

Drivers are another big issue – particularly for Linux/Windows installations. Many hardware manufacturers do not produce drivers that support Linux-based operating systems the open source community has had to develop them themselves. In some cases – particularly webcameras – drivers are still being developed; and the versions that are currently available require more advanced computer skills to get running.

In my case the expertise required to implement the drivers is above my skillset, so I’m not able to use my Logitech Webcamera while logged into Ubuntu.

In the context of the discussion on VMWare, guest machines get their drivers and hardware information from the host. So despite the fact drivers are widely available for Windows, if you’re running XP as a virtual machine within Ubuntu you’re not going to be able to use the webcamera. This isn’t the case with parallel installations because the extra layer of the host-guest relationship doesn’t exist.

PARALLEL INSTALLATIONS

With Parallel Installations or Dual-Booting, you are running two completely separate operating systems on one box. In this case when you first power-up the computer you are prompted to select which system you wish to log into. Once logged in you will only have access to the software components that you’ve installed on that specific OS, and not both (as is the case with virtual machines).

Historically setting up a dual-booting system has been fairly complicated – especially for new users. However increasingly software companies have begun to ease the process.

Mac’s new Leopard release for example (OS 10.5) comes with a utility known as Bootcamp, which vastly simplifies the set-up process for installing Windows machines in parallel. The set-up is largely wizard based and takes you through the process of re-partitioning the harddrive to make way for the new Windows instantiation, and then rebooting into the Windows install process.

Additionally Ubuntu has gone one step further by enabling insterested parties to test drive the OS without actually installing it, to install an instance within Windows, or dual-boot the machine.

Advantages: One of the main advantage of parallel installations is the fact you can dedicate 100% of your system resources to the host machine. As a result programs and the operating system in general run much more quickly.

Secondly, and equally importantly, is the fact that you don’t face the same driver issues in dual-booting that you do in vmware. For example, if Linux is your OS of choice you can use Ubuntu as your primary default OS, but revert to Windows XP for web conferencing. (That said there are of course existing open source options for Linux users; this option is just one possibility.)

Finally though perhaps trivially, you won’t face issues of keyboard shortcuts with nearly the same frequency as virtual machines.

Disadvantages: Unlike virtual machines which are housed within single large files within the host machines folder heirarchy, parallel installations require dedicated partitions to function. So the process of setting up a dual-boot machine requires additional steps that change the landscape of your harddrive rather than working within the pre-existing conditions.

These changes can be undone later to a degree; but re-partitioning of a harddrive is never to be taken lightly. So this factor should be borne in mind (e.g. back-up first!)

Secondly you are restricted to the software and functionality of one operating system at a time.

MY OPINION

Having used both options on a few different machines I personally prefer dual-boot systems over virtual machines for general usage (as I said there is just no beating vmware for testbed installations). While it is nice to have the ability to quickly access PC software from the Mac without having to do a full restart, I found it cognitively difficult to work between the two operating systems within one environment.

For one, while in XP the key-board shortcuts were a hybrid – not quite PC, and definitely not Mac. So I was constantly making mistakes when typing that resulted in a loss of efficiency over time. I’ve heard that you can remap keys; but to be honest I wasn’t in love with vmware enough to bother.

Having set-up the same laptop with XP dualbooting through Bootcamp on the other hand, I’m much more pleased with the set-up. On my home machine I’ve got Ubuntu dual-booting with Windows XP Media edition AND a virtual instance of XP running within Ubuntu and have found that I never use the virtual machine. To me there’s nothing quite like logging into the full operating system.

But as I said, it all comes down to user preferences.

Previous Posts @ TechTicker:

I recently ran across a strange problem with the Play Framework and Netty: on Linux, my Play app could easily handle thousands of concurrent connections; on OS X, the same app maxed out at around 50 concurrent connections. It took a while to figure out the problem, so in this post, Im documenting the solution in case other folks run into the same issue in the future. Note: if youre using raw Netty, the fix is very straightforward; if youre using Play, its much trickier, and I hope it will be fixed in Play itself in the near future.

tldr: set the backlog option on Nettys Bootstrap object to a higher value (example).

Symptoms

On OS X, your Play or Netty app cannot handle more than ~50 concurrent connections. A simple way to test this is to use Apache Bench:


As soon as you set the concurrency level (the -c parameter) above 50, youll get the error "apr_socket_recv: Connection reset by peer (54)". Moreover, your Play or Netty app will never actually see the request and nothing will show up in the logs.

However, if you run the same experiment against the same app running on Linux, even with the concurrency level set to several hundred or several thousand, all requests will complete successfully, without errors. Therefore, there must be something OS specific causing this problem.

To be fair, its rare to use OS X in any production or high traffic capacity - for example, at LinkedIn, we use OS X in dev, but Linux in prod - so the concurrency limitation is rarely a problem. However, we had a few use cases where, even in dev mode, we had to make many concurrent calls to the same app, so we had to find a solution.

The Cause

It turns out that "50" is the default size for the "backlog" parameter in Javas ServerSocket. It is even explained in the JavaDoc:

The maximum queue length for incoming connection indications (a request to connect) is set to 50. If a connection indication arrives when the queue is full, the connection is refused.

Therefore, whatever code manages sockets in Netty must use different configurations for the backlog parameter on Linux and OS X. This code is likely tied to the selector implementation for the OS: Im guessing the Linux version uses epoll, while OS X uses kqueue. The former probably sets backlog to some reasonable value (perhaps from OS settings) while the latter just uses the default (which is 50).

The Solution (pure Netty)

After some more digging, this StackOverflow thread reveals that the Netty ServerBootstrap class lets you set an option to override the backlog:

If youre using pure netty, just use the code above and the 50 concurrent connections limit will vanish immediately!

Also worth noting: this issue exists in Netty 3.x, but apparently Netty 4.x sets a better default than 50 on all OSs, so upgrading Netty versions may be another solution.

The Solution (Play)

Play instantiates the ServerBootstrap class inside of NettyServer.scala. Unfortunately, neither the class nor the boostrap instance inside of it are accessible to app code. This should be easy to fix via a pull request, but until that happens, and until a new version is available, here is a two part workaround to get moving.

Note: this is an ugly hack with lots of copy/paste from the original Play source code and is only meant as a temporary workaround. It has been tested with Play 2.2.1; figure out which version of Play youre on and be sure to use code from that release!

Step 1: make a local copy of NettyServer.scala called TempNettyServer.scala

Youll want to put TempNettyServer.scala in a different SBT project than your normal app code - that is, dont just put it in the app folder.  See SBT Multi-Project Builds for more info.

The folder structure looks something like this: my-app is my original Play app and monkey-patch is a new SBT project for TempNettyServer.scala:

Copy the contents of the original NettyServer.scala into TempNettyServer.scala, with two changes:

1. Replace all NettyServer references to TempNettyServer
2. In the newBootstrap method, make the change below to allow configuring the backlog option

Now, configure this new SBT project in project/Build.scala:


Step 2: override the run and start commands to use TempNettyServer

Ready for more copy/paste?

Grab PlayRun.scala and copy it into the project folder under some other name, such as TempPlayRun.scala and make two changes:

1. Replace all PlayRun references with TempPlayRun: there should only be one, which is the class name.
2. Replace all NettyServer references with TempNettyServer: there should two, both in String literals, used in the "run" and "start" commands to fire up the app.

Now, update the settings in project/Build.scala to use your versions of the "run" and "start" commands:


A note on OS limits

After making the changes above, you should be able to handle more than 50 concurrent connections. However, depending on how your OS is configured, you might still hit a limit at 128 or so. This is probably due to the kernel config kern.ipc.somaxconn, which controls "the size of the listen queue for accepting new TCP connections" and has a default of 128.

To tweak this limit, you can run the following command:

Your Netty or Play app should now be able to handle over 1000 concurrent connections (or more, depending on what limits you set above).