VirtualBox
There’s a hosted hypervisor called VirtualBox available for various platforms that’s rather interesting, and has managed to capture the attention of many folks looking for a freeware virtualization product. For one thing, it’s freeware and open source (GPL). And many people have reported that it runs Windows guests rather well.
I tried it about six months ago when I had some trouble with VMware Server 1.0.3 and wanted to try alternatives. (FYI, as the discussion thread shows, if you’re having problems with VMware instantly hard locking the system, and are running a 64-bit kernel, check if you’ve got the kvm modules loaded. They put the kernel in VMX Root mode, which VMware also tries to do and subsequently renders the system hard-locked. Apparently this isn’t a problem on a 32-bit kernel.)
So I tried the Debian-packaged version of VirtualBox. I ended up getting this error
Unknown error initializing kernel driver (VERR_VM_DRIVER_VERSION_MISMATCH).
VBox status code: -1912 (VERR_VM_DRIVER_VERSION_MISMATCH).
It turns out that VirtualBox’s kernel component and userspace component must have the same bitness. The kernel part doesn’t support both 32-bit and 64-bit userspace. (Just about everything else does, and in fact kernel-space stuff ought to support both 32-bit and 64-bit processes, since it’s part of the platform, and the platform offered by a 64-bit kernel is meant to support both 32-bit and 64-bit processes. Oh well. Another culprit that suffers from this limitation is the OpenAMT project, which also requires the kernel component, the HECI driver for the chipset-integrated Management Engine, and the userspace component, the OpenAMT stack, to have the same bitness. An unnecessary limitation.)
So I created a 64-bit chroot environment (and apparently someone copied my comment in the support ticket into the VirtualBox wiki that illustrates how to do this on Debian sid) and installed VirtualBox into that.
Now VirtualBox would no longer complain about the kernel driver mismatch. However, it would now immediately go into “Aborted” mode. Investigating, it turned out that it was crashing.
I like to use Bridged networking on my guests—so that they appear as part of my LAN and accessible as peers by my laptop—and I had configured the VM to use this. Unlike VMware, VirtualBox brings up a standard Linux TUN device and expects you to provide scripts to add the TUN device to a host-based bridge with a physical network interface when the VM comes up, and to remove it from the bridge when the VM is brought down again.
It turns out that kernel version 2.6.18 onward, you effectively need root access to write to a TUN device. VirtualBox was trying to write to it, failing, logging an error, triggering a failed assertion and crashing. Moving the VM and all configuration files to the root user and setting the root user up to work with VirtualBox (by adding it to the vboxusers group) fixed this. (Of course, one wonders what the point of the vboxusers group is if I need to run VirtualBox as root anyway in order to use bridging . . .)
The whole painful process is outlined in the how-to document prepared from my comments in the ticket.
My impressions are that when VirtualBox works, it works well; however, when it doesn’t work, it’s miserable to work out its issues. It seems to have dodgy error handling (e.g. cryptic or inaccurate logging and crashing rather than notifying the user of the problem, although in at least one instance—checking if the system is already in VMX Root mode—it beats VMware, which prefers to hardlock instead) and has extremely poor error messages, without any reference on the web site explaining what the error messages are and how to resolve them.
[Edit: Going through VirtualBox's changelog, it appears that since I last tried VirtualBox, a lot of error handling has been improved, with better error messages, more notification with less spurious crashing, and more tolerant code. Good, it's making progress.]
I’m also appalled at the lack of polish regarding bridged-mode networking. I didn’t think that was an uncommon enough use case that it would require the user to set up a persistent bridge on the host himself and write scripts to enable VirtualBox to add its TUN device to the bridge and remove its TUN device from it. The whole needing to run as root is also appalling.
It’s also unfortunate that VirtualBox doesn’t support 64-bit VMs at all.
There are two advantages to VirtualBox—it’s open source, so that when you inevitably run into an obscure error message or a crash, it’s possible to debug it yourself; and it’s available on platforms that don’t have other freeware hosted virtualization software (such as Mac OS X and OpenSolaris—the former has Parallels and VMware Fusion, neither of which are freeware). However, based on the level of polish alone, I prefer to use VMware Server.
VMware Server 2.0 beta 2
Speaking of VMware Server, I gave the Server 2.0 beta 2 a spin. It’s tolerable—now it has some semblance of user management and I don’t need to log in as root or hack a file to let a non-root user log in, and its web-based UI is slimmer now, using just ~80 MiB of RAM as opposed to the hundreds of megabytes the first beta used, but it’s still annoying. For one thing, the rich-client VMware Console is long gone. The only way to interact with the VMs on Linux is via the command line or through the Web UI. It uses a hacked-up version of VMware Player to provide VM consoles, but you can only have one console open at a time.
It is also fragile—I had vmware-hostd die quite frequently with certain legacy VMs, and some of the changes you can make to VMs through the Web UI aren’t easily undoable. And Lord help you if it decides one of your VMs is invalid. It’s a right pain to get it to believe the VM is valid again, and this usually involves removing it from the inventory, removing whatever setting is in the .vmx that confused it, and re-adding it in. >_<
Other versions of VMware don’t touch things like virtualDev settings in your VMs when first adding them into the inventory—so for instance if you have a 64-bit VM, you might want to use Ethernet.virtualDev = ”e1000″ since VMware doesn’t support the AMD PCNET emulated device in a 64-bit VM, you’ll have to jump through hoops (i.e. edit the .vmx manually) to re-enable your change. Similar with sound.virtualDev (for some reason VMware Server 2 seems to prefer “sb16″ over “es1371″ despite the latter working better in 64-bit VMs).
As far as the Web UI is concerned, it doesn’t work at all in Opera. It works in Gecko-based browsers and Internet Explorer. I installed the Mozilla Firefox 3 beta 5 which allowed me to use it. As mentioned earlier, you can only have one VM’s console open at a time (although, aggravatingly, it’ll let you open up multiple copies of the console for the same VM). The alternative is the bundled VMware Virtual Infrastructure Client 2.5, which (of course) runs only on Windows.
This VI Client is a .NET application, so it won’t even run under Wine.
I thought I might be able to give it a go under Mono. However, it’s packaged as a non-.NET InstallShield installer that uses Windows Installer as its backend, so I thought perhaps I could install it using Wine and then use Mono to run it.
No such luck. Wine’s Windows Installer implementation appears to be incomplete and cannot handle the .msi’s format. Oh well.
In any case, posts on the VMware Communities indicate that Mono’s .NET Framework implementation isn’t complete enough to run the VI Client under Mono anyway. How unfortunate.
There is a rumor that a Virtual Center client is being written for Linux. However, that probably won’t help me since as I understand it, Virtual Center is quite expensive.
Come on, VMware, give us a decent Server 2 product.
Oh well. For now I’m going to stick with Server 1.0.x and pray that VMware decides to produce a freeware VI client for Linux sometime in the near future.
VMware with ALSA
VMware seems to really love the OSS interface for Linux audio. The recently-released version 2.6.25 kernel killed off even more OSS drivers, and OSS is deprecated, and yet even as of their Server 2.0 beta 2, VMware continues to use OSS. So do VMware Player 2.0.x and Workstation 6.0.x.
This presents a problem for the vast majority of users, who do not have sound cards that support hardware multiplexing of PCM audio streams, which is to say, mix sounds from multiple tasks together. And Linus et al believe that mixing of audio in software doesn’t belong behind the kernel interfaces, even if that would make it transparent.
ALSA has the dmix plugin that tries to do this relatively transparently in software. It works well enough—but only if all your applications use ALSA to output audio. If any application uses the compatibility OSS interface (accessing /dev/dsp directly), it either won’t be able to access it if any ALSA application has the corresponding ALSA sound device (usually /dev/snd/pcmC0D0p or similar) open, or if it manages to access it, no ALSA application will be able to output sound.
Fortunately, ALSA also provides a conversion library (alsa-oss) that can be preloaded into a process to take over system calls such as open(), write(), ioctl(), close() and so on, in order to trap attempts to open and write to /dev/dsp or similar and convert them into ALSA library calls to use the ALSA device instead. Ordinarily, you prefix the aoss command to a process, and it’ll use the LD_PRELOAD environment variable to instruct the dynamic loader, ld.so, to override functions using /usr/lib/libaoss.so.0.
It’s a bit tricky with VMware, though, since the app you use to control the VMs isn’t what the VMs run inside. Rather, it’s /usr/lib/vmware/bin/vmware-vmx that the VM actually runs inside. Even more tricky, it’s setuid root, which means that LD_PRELOAD overrides will not take effect unless the preloaded library is itself setuid root.
Fortunately, this is simple to fix with a shell script. Rename /usr/lib/vmware/bin/vmware-vmx to vmware-vmx.real and replace it with a shell script that uses LD_PRELOAD. Also make /usr/lib/libaoss.so.0.0.0 setuid root.
sudo mv /usr/lib/vmware/bin/vmware-vmx{,.real}
sudo chmod u+s /usr/lib/libaoss.so.0.0.0
sudo tee /usr/lib/vmware/bin/vmware-vmx <<_EOF_
#!/bin/sh
LD_PRELOAD=libaoss.so "$0.real" "$@"
_EOF_
This works rather well, and my VMs are able to output audio using dmix. For some reason, though, input (via dsnoop) doesn’t work unless I start the VM, disconnect its audio, stop all applications using the sound device (e.g. using sudo fuser -k /dev/snd/pcmC0D0p, though this is a bit extreme), remove the sound driver (using sudo modprobe -r snd-hda-intel), load it again (using sudo modprobe snd-hda-intel and then reconnect the VM’s sound. And I need to do this every time I start a VM that I want to be able to capture sound in.
(Recently I had to build the ALSA 1.0.16 modules because capture stopped working at all on the Linux host as well as VMs with the 2.6.24 stock driver. I haven’t tried capturing audio in a VM since then, so I don’t know if the bug persists in ALSA 1.0.16.)
Mozilla Firefox 3.0 Beta 5
Speaking of Firefox 3, it’s much improved over Firefox 2 in all ways—it even provides a Show Image context menu item. I usually browse with image loading turned off for the sake of speed, so this is a welcome development. Firefox 3 is blistering fast compared to Firefox 2, uses far less memory and manages memory much better.
Unfortunately, the Show Image feature doesn’t work so well. However, there is the imgLikeOpera extension. It hasn’t been updated for Firefox 3, with the result that Firefox sees it as an incompatible extension, but this is easy to fix. The .xpi is just a ZIP archive. I unzipped it, edited the manifest, updated the maximum supported version and removed the update URL (which must apparently now provide for some level of security in order for Firefox 3 to accept it), then zipped it up again. The resulting .xpi installed perfectly in Firefox 3 and provides for excellent functionality. The only thing I wish it did was to provide for toolbar buttons to toggle the image loading mode; right now I need to hit Tools → Add-ons to get at the image loading mode.
Still, it isn’t seamless. I still prefer Opera’s functionality and am using last week’s Opera 9.50 weekly build. This week’s unfortunately for the first time introduced some image loading bugs, which makes it unusable for my purposes. Opera 9.50 is pretty fast, but it has a large memory footprint. Not nearly as big as Firefox 2’s, but big enough to be concerning. Still, it’s blazing fast and reasonable stable, so it’s my browser of choice.
GMail and Opera 9.50 weekly builds
FYI, if you’re using an Opera 9.50 weekly build and use GMail, you might notice that unlike Firefox and Internet Explorer users, Opera users only manage to get the version 1 UI rather than the version 2 UI (which offers things like colored labels and does not wait for server round-trips every time you do something, so is much more pleasant to use). It seems it works fine with Opera 9.50 as long as you tell GMail not to check the browser by using a URL like this:
http://mail.google.com/?ui=2&nocheckbrowser&disablechatbrowsercheck
It works rather well.
Evading crashes due to crappy drivers
I’ve been having hardlocks once every two or so times I try to burn a DVD, and I’ve been experiencing this for months, since at least the 2.6.22 kernel in Debian sid, along with the frequent inability to eject the tray, either using the button on the drive, or the eject command. I thought it was because my DVD±RW drive was dying, but then I installed Windows in a dual-boot configuration and found that it worked perfectly in Windows.
I figured the problem was the driver for the Marvell PATA controller on my Intel DG33FB motherboard (whose chipset, Intel’s G33, does not integrate a PATA controller itself, thanks to Intel’s desire for forced obsolescence—never mind the fact that just about all motherboards that use an ICH8 or ICH9 series southbridge use a discrete PATA controller as well, even Intel’s own motherboards). So I’ve changed it so that the ata_generic driver is used instead of pata_marvell.
I added the following to /etc/modprobe.d/marvell:
install pata_marvell modprobe ata_generic
blacklist pata_marvell
options ata_generic all_generic_ide=1
The first line is probably unnecessary as it’s overridden by the second, but I added it in just in case.
I tried burning a DVD-R—no hardlock this time. I can’t say for sure that I’ve fixed it, but so far, so good.
Ram Navami, or why I consider India to be uncivilized
On April 14, Hellholia had a major Hindu festival, Ram Navami (राम नवमी), the birth of the Hindu God Rama, an incarnation of Lord Vishnu. Of course, in usual Hindu tradition it was celebrated with “pomp”, which means that they made a constant racket from dawn until 1:30 AM the next day at the temple across the street from my apartment building. Mostly they were devotional songs played on very crappy loudspeakers as loud as they could be. This meant I couldn’t hear myself think. Top this off with firecrackers set off annoyingly at random. (And these aren’t the kind of fireworks that produce a spectacular show; their entire purpose is to be noisy.)
As if this wasn’t bad enough, drums woke me from a disturbed slumber around 4:20 AM. Soon (around 4:45 AM) the power went out as the drums got louder.
A few hours without power later, I decided to shower and go outside to pay my DSL and telephone bill. I noticed that the pharmacy that usually electronically processes my bill was closed, but that there was a big parade traversing my narrow street really slowly. Apparently they’d cut the power because the floats were tall enough to interfere with the power lines in the narrow street, and members of the parade were raising these power lines with wooden sticks to allow the floats to pass.
I went up to the roof, whipped out my basic camera phone and started taking pictures.
6:39 AM
That’s eastward from my apartment building, on the street below. Note the parade float, peasant dance and (annoying) drummers and the power transformer and distribution lines next to it. Note also the narrowness of the street.
Why the hell did they have to come through such a narrow street?
The parade was moving very slowly (about 10 yards every 10 minutes), had many floats and was very noisy. And every time a float moved, someone had to move the cables out of the way so they could move. (Not just these power cables, but telephone cables, that in this city at least, tend to be strung across streets from pole to window or roof. There seems to be no OSHA-like regulatory agency or any kind of fire codes to prevent companies from doing this. The DSL line I’m using to post this is similarly strung across from a neighboring building’s rooftop to mine.)
Note the many drummers.
This is the street towards the west.
Many more floats were incoming. Note how they have power (thanks to the generators they’re towing or have mounted in the rear), unlike me, directly because of them.
They’re working up a major din. In any civilized country, people would call the cops if someone made this much noise in a residential area, especially in the early morning hours. In India, policemen were in on it, directing traffic away so the parade could pass unhindered.
The floats had pundits (priests) offering artis to the idols. Many residents were going up with their own offerings in exchange for blessings.
6:40 AM
Even more. Moving annoyingly slowly.
6:41 AM
Goddamned drummers working up a din.
6:42 AM
Floats with idols, priests and bright lights.
7:09 AM
The noisiest drummers.
7:14 AM
Even more floats incoming. This parade started to feel interminable around this point. I was glad I was on the roof and not on a lower floor, where the circa 25°C temperature combined with restricted ventilation (thanks to the lack of mains power to run ceiling fans and air conditioners) were likely not only making the residents miserable, but the louder noise would’ve made it even more annoying. My landlord was on the ground floor watching the parade as it passed. His ears have probably been affected by the pervasive noise pollution, so perhaps the noise didn’t bother him as much as it did me.
7:17 AM
Most interminable. I think it was around this point that I started yelling over and over, “Leave now and never come back!” Unfortunately, I don’t think anyone heard me over the drums. ;_;
7:26 AM
A pair of cops (dressed in their dirty brown, or khaki, uniforms) pass through the parade, hats quite literally in hand.
7:39 AM
I’ve now been on the roof for over an hour, and it’s been three hours since the parade robbed me of mains power. (I can tell the power’s still out because the landlord rents an upper terrace to a local telecommunications operator who has built three transmission towers and has placed a generator to power them in case of power failure. The generator ran throughout.)
7:48 AM
The last one is leaving (well, actually, stopped at the intersection for five minutes), finally.
The parade left the street around 7:55 AM, though when I left the apartment again, they were still occupying the perpendicular street around 8:15 AM. I called the power company around 8:25 AM inquiring as to when I could expect the power to be restored now that the parade was gone. Their answer—“an hour”. I resigned myself to waiting another hour for mains power. Fortunately for me, the power was restored around 8:35 AM, or approximately four hours after the blackout commenced.
What a backward country, where residential power is cut for a religious parade, and disturbing noise is permitted in residential areas. I only got less than three hours’ worth of sleep between 1:30 AM, when the noise stopped, and 4:20 AM, when it started again.
Hopefully my application for immigration to the UK through the Points-based system is accepted and I can get out of here.
Misadventures with EFI
On the suggestion of a certain obnoxious Brit, I decided I would make use of the UEFI support of my motherboard to install Windows Vista x64 SP1 on a GPT drive. Long story short, Intel’s Desktop Boards have a rather buggy UEFI implementation.
- Some firmware versions don’t even support EFI boot off an optical drive. This includes the most recent version, which then cannot be downgraded again unless I do a recovery flash—otherwise the upgraded Management Engine firmware refuses to be downgraded again.
- Once it boots up, the Vista installer can see my SATA drives, but says that the firmware doesn’t support booting off them, so refuses to install to any of them. Sure enough, when I turned off Native mode for SATA (AHCI or IDE) in favor of Legacy mode, Vista’s installer was able to install to the drive. Apparently Intel’s AHCI and IDE mode SATA firmware for the onboard SATA controller doesn’t support UEFI.
- Now that it’s installed, I cannot boot off any other media, even if I unplug all devices except for a DVD-ROM drive, or all drives except a USB flash disk, or all drives except a floppy drive, etc. Even worse, I couldn’t do it even if I disabled UEFI Boot in the BIOS configuration—something very bizarre, since it was trying to boot only EFI stuff in non-EFI mode.
- If I downgrade the BIOS to one with faulty UEFI support (one that can’t boot off an EFI DVD-ROM), I get a continuous
Boot succeeded - Windows Boot Manager
Vista’s put something in my NVRAM!
- Sure enough, Googling for Vista EFI NVRAM "Windows Boot Manager" brought up a Microsoft TechNet article, Remove Duplicate Firmware Objects in BCD and NVRAM. Suspecting that I might be able to boot “legacy” stuff if I emptied it, I upgraded the firmware back to one where UEFI boot worked again, plugged all the drives in again and booted up Vista. There I ran
bcdedit /export b0rked.bcd
bcdedit /clean
and rebooted. Sure enough, I was able to boot Linux after that.
- The firmware apparently disobeys the boot order and has zero support for booting “legacy” devices if there are any boot entries in the NVRAM, which makes it rather useless to boot, for instance, rescue DVDs.
- Even more pressingly, I couldn’t boot off the Vista installation DVD despite it having an EFI-aware bootloader. Apparently El Torito boot images are legacy as well. I would’ve been in an instant world of hurt if the Vista installation managed to become unbootable itself, since a CMOS reset by removing the battery and shorting the electrodes reset all the BIOS settings but not the EFI NVRAM.
- Later, I changed the boot order to try to boot off the Vista installation. Sure enough, I couldn’t boot off it once its entry was removed from the NVRAM.
- The TechNet article suggests that the NVRAM’s contents should be rebuilt every boot after drives are enumerated. Intel’s firmware obviously isn’t doing that.
- Worse, Intel’s technical support doesn’t offer support for UEFI. This means if you get into trouble with UEFI, expect no help from Intel. I had to figure this stuff out all on my own. Intel’s support personnel said there were no known UEFI issues and that there had been no reports. I asked them to consider my adventures a report. Oh well, at least they’re aware of the issues I had now.
Verdict: Intel’s Desktop Boards’ UEFI support is far from prime time. Avoid.
Also, if you’re installing Windows Vista x64 SP1 on these boards and UEFI boot is enabled in the BIOS configuration, the DVD will default to attempting an EFI install. So if you’re planning to install it on an Intel Desktop Board, ensure that UEFI Boot is disabled in the BIOS configuration, or you will regret it.
That’s a misadventure I don’t care to repeat.
[Edit: It turns out I should've read the Technical Product Specification for the motherboard, because in this situation, pressing F10 gives me a temporary boot menu, which lets me choose the device to boot off. This lets me boot the CSM-based bootsectors as well as removable devices. It's still pretty far from ideal that I have to do that, though, but it does mean that it's recoverable even if Vista stops being able to boot, as actually happened once when it consistently failed to come out of hibernation and also didn't prevent resume on the subsequent boot—I had to boot Linux, mount the filesystem and remove hiberfil.sys.]
Microstar International (MSI) has launched a motherboard with UEFI support, the P35 Neo3-F. I think there’s yet to be a review of it testing the UEFI functionality. I wonder if it’s any better. Then again, the P35 Neo3-F’s marketing has touted the UEFI support; I doubt they would do that if their UEFI firmware was as embarrassingly buggy as Intel’s.
Oh well. In a year, maybe I’ll give it another shot.
