I find myself in a position where I have to run Windows on my laptop, and use it on a daily basis. This does not make me a happy moggie, as I have run Ubuntu exclusively (except for gaming) for several years. I finally decided that the best solution would be to run Ubuntu in VirtualBox on top of Windows.
(Yes, I still run Hardy, as I still haven’t recovered from trying out the unmitigated disaster that was Intrepid. I may give Jaunty a spin some day; VirtualBox makes this so much easier… but in the meantime, Hardy it is. Besides, it’s an LTS release.)
Why not the other way around? Three reasons: Windows is a PITA to virtualize (not least from a licensing POV); I never do anything really performance-sensitive in Linux, but I do in Windows; and doing it this way around means I can suspend and hibernate, something Linux still can’t do. (Cue angry comments from Linux fanboys insisting that suspend and hibernate work just fine and I’m an idiot; sorry, but no, it has never worked for me on any of the laptops I have owned or managed—even those manufactured by companies that spend millions of dollars every year on Linux development.)
Running Ubuntu in VirtualBox is not as easy as it sounds, though. You can’t just create a new VM, pop in the CD, and install. There are several issues that took me quite a while to resolve, and the VirtualBox web forum was no help at all: the moderators arrogantly shut down any thread touching on issues covered by the FAQ, even when the answer given in the FAQ is incorrect and / or insufficient.
The first thing you do after installing, of course, is install the “guest additions”: various bits and pieces of useful software, such as support for mounting shared folders from the host OS. With a default setup, you simply press RightCtrl+D while logged in; VirtualBox will mount an ISO image containing the software, and Ubuntu will ask you to confirm that you want the autorun script to run. If you accept, the script will install two kernel modules, two X.org drivers, and some init.d scripts and other miscellanea.
Here’s the first gotcha. If you apt-get dist-upgrade after installing the guest additions, and the upgrade includes a new kernel, you will have to reinstall them, because you need new modules to go with the new kernel. Otherwise, you will get obscure error messages (either “no such file or directory” or “device not found”) when trying to mount shared folders. I can’t remember that ever being an issue with VMWare; Linux is generally pretty good at maintaining binary compatibility for kernel modules, so it should simply be a matter of installing it somewhere else than in the current kernel’s module directory. I guess Sun prefers the inconvenient-I-know-but-at-least-we-won’t-have-to-worry-about-KBI-changes approach.
The second gotcha is the X configuration. Out of the box, X will have a lot of trouble determining available screen resolutions and using the right one. Actually, “a lot of trouble” is an understatement: it will fail miserably. In addition, the mouse will behave strangely, randomly refusing to move past a certain row or column. All in all, X will be pretty much unusable.
These are, inarguably, bugs in VirtualBox—these things should work out of the box. I’m willing to accept a restricted choice of display resolutions, but the mouse issue is unforgivable. Both issues are fixable, but still—like the kernel module issue, you shouldn’t need to fix them manually.
The solution to both X issues is to use the display driver (vboxvideo) and the mouse driver (vboxmouse) included in the VirtualBox guest additions. Forget about displayconfig-gtk, though; all I got when I tried to use it was a mangled xorg.conf with duplicate sections.
The thing is, with VirtualBox, you don’t need much of an X configuration. There is only one display, which uses a simple driver which does not require any special options. There is only one monitor, which—being virtual—does not require any frequency ranges or mode lines to be specified. There is only one pointing device, which uses a simple driver which does not require any special options. There is only one keyboard, which uses the same keyboard driver as in any other X setup, with the same options. There is only one screen, which combines the aforementioned display and monitor, and supports any resolution(s) you fancy. Finally, there is only one server, which associates said screen to the the aforementioned mouse (the keyboard is implicit).
In other words, all you need is this:
Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "XkbRules" "xorg" Option "XkbModel" "pc105" Option "XkbLayout" "us" EndSection Section "InputDevice" Identifier "VBox Mouse" Driver "vboxmouse" Option "CorePointer" EndSection Section "Device" Identifier "VBox Video" Driver "vboxvideo" EndSection Section "Monitor" Identifier "VBox Monitor" EndSection Section "Screen" Identifier "Default Screen" Device "VBox Video" Monitor "VBox Monitor" SubSection "Display" Modes "1024x768" "1400x1050" EndSubSection EndSection Section "ServerLayout" Identifier "Default Layout" Screen "Default Screen" InputDevice "VBox Mouse" EndSection
You should of course adjust the keyboard layout and the screen resolution(s) to fit your needs. I use Norwegian keyboards (because that’s what’s available in Norway, and I prefer the European placement of the Enter key) with the US layout (because programming in C-like languages using anything but the US layout is torture); in most of Western Europe (all except the Netherlands, I believe), you should use the “pc105” model with the appropriate layout for your country, while in the US, you should use the “pc101” model with the “us” layout. As for screen resolution, I use 1400×1050 so I can run in full screen on my laptop, and 1024×768 in case I want to run in a window for more than a few minutes.
That’s it. It’s really not that hard. It’s just not documented properly anywhere that I could find.