Installation of VirtualBox OSE 3.1.x on Ubuntu 10.04 (Lucid)

Posted by JD 05/23/2010 at 11:12

Installation of VirtualBox OSE (Open Source Edition) using the Ubuntu repositories should be easy. For me, there were a few issues that I figure other people may run into. I was able to solve them.

Installation

I used Synaptic to install the virtualbox packages. Version 3.1.6 was installed. To be certain everything would work, I rebooted the system. Previously, I had been playing with QEMU and KVM. Those packages were remove, the system rebooted, and verified they were not being loaded as kernel modules before attempting anything related to VirtualBox. If you are mixing virtualization on the same physical hardware, be careful. Most will not let you have more than a single hypervisor installed at a time.

Extra Required Configuration

After the reboot, everything seemed just fine, so I typed
virtualbox &
into a shell as my normal, unprivileged userid. A few seconds later, the VirtualBox GUI was displayed and everything seemed fine. I’ve been using vbox on Windows hosts for a few years, so I was a little surprised that it was really this easy on Ubuntu. Clearly, I was pre-maturely happy.

After screwing around with NS_ERROR_FAILURE -38 and Runtime error access denied, while trying to set some global preferences, searching a little confirmed it was an access error. Since my account owned the directory and all files where the settings were placed and the directories where all the VMs will be placed (not the default location), it didn’t make any sense. A little more searching determined that a new group was needed, vboxusers. My system didn’t get that group during the package installation. Boo. I add it. You don’t need to logout and login like everyone says, you just need to type
newgrp vboxusers
to make it your primary group. Done. Run vbox again … more errors. A little more searching said that /dev/vboxdrv permissions need to be root.vboxusers and 660.
sudo chown root.vboxusers /dev/vboxdrv
sudo chmod 660 /dev/vboxdrv
Fine. Done. Run vbox again … more errors. Seems the first time I ran virtualbox, some directories were made, but because the vboxusers group didn’t exist, these directories didn’t get the group permissions.
chgrp -R vboxusers ~/.VirtualBox
and
chgrp -R vboxusers /raid/VMs/.VirtualBox
Good enough? Nope. There were different errors this next time.
rm -rf ~/.VirtualBox
and run vbox again. FINALLY, no errors and my settings are retained between runs.

WinXP Home Installation

I don’t want to bore you with too many details other than to say that I gave the VM 1GB of RAM, 128MB of video RAM, and a 10GB disk. I specifically checked Passthru for the DVD device, thinking that would be helpful. During installation, I booted from a real DVD (legal and everything!). During the setup, it demanded my Win95 CD to prove my “WinXP Upgrade” was legal. It took about 20 attempts to get the Win95 CD to pass whatever tests the installer wanted. Then after swapping back to the WinXP DVD, I’m on attempt 30 and still trying to get it to read the CDROM that setup booted from. I’ll probably have to create an ISO of both the WinXP and Win95 installation CDs to avoid these problems. Fun. Good thing that Microsoft decided DRM was good, huh?

Second attempt. I changed the DVD device settings to remove Passthru. That seemed to help. The installation finished.

It appears that since I didn’t pre-configure a bridge network on the host, that no networking was installed. Inside the client, the ethernet driver is listed as “unknown”, but I specifically selected an Intel PRO/1000 MT. Ah, I remember now. That card was pre-WinXP and a driver download from Intel is required. Time to pick a different NIC in the VM settings. I must say, this new VM is FAST. I gave it dual CPUs in this Core i5 machine.

I also selected the IDE disk controller due to legacy reasons. WinXP pre-SP1 doesn’t understand SATA controllers which are faster. We’ll come back and swap the disk and network controllers after the installation to get more performance.

After hours of SP2, SP3, Patches, and using ninite to install my base 10 apps, I pulled Hulu Desktop down and installed it inside the VM. It is running in HQ mode and the video and audio is perfect.

WinXP Pro Migration

I’ve been running a WinXP-Professional under VirtualBox on a Win7 x64 host for about 8 months and for a year under Vista x64 before that. That physical host was a laptop and died about 3 months ago leaving me with a problem. Where do I run the existing virtualbox VMs? For some time, I attempted to migrate them to VMDK and IMG and QCOW formats so I could use them under KVM or Xen or ESXi. The issue for Windows migrations was that the underlying virtualized hardware had changed so much to require reregistration, which I wanted to avoid. Further, only the VMDK migration would even boot. I know I could have simply reinstalled the OS and re-configured it have the programs I wanted. I’d rather not spend 3 weeks doing that. Linux doesn’t require a re-install to move physical platforms.

According to the VirtualBox user documents, it is possible to live migrate entire machines between hosts. It requires a SAN, which I don’t have in my “lab” yet. So we won’t be doing that.

VirtualBox Export / Import

  1. 1st VM hardware: My old VirtualBox host was a laptop with a C2D T8100 and 4GB of RAM. When that broke. Activation required, but it was a fresh install.
  2. 2nd VM hardware: I moved a the VMs to a desktop Win7 x32 host with an E6600 and 2GB of RAM. The performance has always been unsatisfactory on that box due to the RAM limitation. I know that RAM is cheap and if I hadn’t already attempted three times to upgrade the RAM, then I’d try again. There’s an issue with the motherboard BIOS settings preventing RAM upgrades. No Activation needed.
  3. 3rd VM hardware: I’ve been running a new Ubuntu 10.04 Server x64 with a Core i5 and 8GB of RAM. Previously it had Xen, then KVM, and now VirtualBox OSE 3.1.x on it. This is where the WinXP migration will live for the foreseeable future. The hope is that no activation will be required, since we’re still on VirtualBox.

Steps:

  1. On Win7 box, start vbox, select the VM to be moved, File→Export and wait. It took about 3 hours to export a 20GB WinXP-Pro VM.
  2. On Ubuntu Srv (while you’re waiting), Install VirtualBox
  3. When the Export completes, copy, move, or take the 3 files to the Ubuntu Srv. 2 of the files were tiny, but the oddly named file had a long {XXXXXxxxx-x-x-x-x-x-x-x-x-x}.vmdk name. Put these files in a temporary location.
  4. Start VirtualBox, File → Import and point to the .ovf file. Let ’er go. At the start, it claimed 8 hours would be needed. The estimated time quickly reduced to 22 minutes. While it was importing, the .vmdk file was copied into the normal .VirtualBox/HardDisk and .VirtualBox/Machine) directories. The 22 min time to complete was a good estimate.
  5. Check the Settings for the imported VM, update the RAM (since I have much more now), fix the video RAM amount, and all the other settings look fine. The only setting that I didn’t change was the number of CPUs. This is because when I originally built the machine (installed from the WinXP DVD), VirtualBox only supported 1 CPU. It turns out that MS-Windows doesn’t really like it when you change the number of vCPUs. A different group of DLLs for the HAL layer is required that are usually only checked during OS installation.

Now it is time to start the imported VM and see how it goes.

For my WinXP-Pro, the system booted and the performance was fine. However, Windows saw that some of the virtualized hardware had changed, so the goal of not having to re-activate was NOT achieved. Since that failed and I intend to get another Win7 laptop at some point, I’ll migrate the few programs (Quicken, Taxes, … that’s it) that run on that VM over to the new WinXP-Home VM created above. That will leave the old WinXP-Pro VM ready for use on the new laptop without any hassles.

I’m not certain what caused the need to re-activate. The main suspect is that the Win7 host is 32-bit and the Ubuntu host is 64-bit, but changing from Windows to Linux host could also be a cause.

Trackbacks

Use the following link to trackback from your own site:
https://blog.jdpfu.com/trackbacks?article_id=658