Technology Tales

Creating a test web server using Ubuntu Server 13.04 and VirtualBox

Having seen Linux Format cover tools like Vagrant and Puppet that manage virtual machines, I have been attracted by the prospect of a virtual web server running on my own PC. Certainly, having the LAMP software stack in a VM means that the corresponding tools don't need to be added to a host system should its operating system need a fresh installation.

As intriguing as tools like Vagrant may be, I decided that I needed to learn a bit more about getting server instances set up in VirtualBox anyway. Thus, I went and downloaded the latest version of Ubuntu Server and gave that a go. One lesson that I learned was that Bridged Networking needs to be added to the VM before installation of the operating system, unless you fancy overcoming the challenge of getting Ubuntu Server to recognise an altered or additional network interface. In my case, I added an extra adapter for the Bridged Networking and left the original in place as NAT. The reason for having Bridged Networking set up is that it allows access to the virtual web server from the host once you know the IP address and that information can be obtained by executing the ifconfig command on the virtual machine.

With the networking sorted, the next step was to install the 64-bit edition of Ubuntu Server. Unlike its desktop counterpart, this is all driven by text menus but remains fairly intuitive and there is hardly anything there that you wouldn't see with another Linux distribution. A useful addition is the addition of a menu to select the types of server services that you'd like to see installed. From this, I chose the web server and SSH options, and I seem to remember that there was a database server option too. If there was an FTP server option, I would have chosen that too, but it was no ordeal to add Proftpd later on anyway.

All of this set was done through the VirtualBox GUI, just to keep life more straightforward. Even so, I only selected 12 MB of video memory and was tempted to cut the overall memory back from 512 MB but leaving things be for now. However, what I have begun to do is start and stop the virtual machine from the command line, since servers are headless operations anyway. With SSH enabled, there is little need to have the VirtualBox GUI going. The command for starting the server is below:

VBoxManage startvm "Ubuntu Server" --type=headless

There is a VBoxHeadless command for the same end too, but VBoxManage does what I need. The startvm option is what tells VBoxManage to start the server, and the virtual machine's name is enclosed in quotes. The --type=headless ensures that no window pops up. To stop the virtual web server cleanly, a command like the following is needed:

VBoxManage controlvm "Ubuntu Server" acpipowerbutton

Again, the VBoxManage command gets used and the acpipowerbutton option ensures that a clean shutdown is performed. Not doing so results in the server not fully starting up, according to my experiences thus far. Getting the virtual web server to start and stop with the host machine itself starting and stopping, but this looks more complex, so I plan to leave things a while before trying that experiment.

Moving a Windows 7 VM from VirtualBox to VMware Player

Seeing how well Windows 8 was running in a VMware Player virtual machine and that was without installing VMware Tools in the guest operating system, I was reminded about how sluggish my Windows 7 VirtualBox VM had become. Therefore, I decided to try a migration of the VM from VirtualBox to VMware. My hope was this: it would be as easy as exporting to an OVA file (File > Export Appliance... in VirtualBox) and importing that into VMware (File > Open a VM in Player). However, even selecting OVF compatibility was insufficient for achieving this, and the size of the virtual disks meant that the export took a while to run as well. The solution was to create a new VM in VirtualBox from the OVA file and use the newly created VMDK files with VMware. That worked successfully to give me a speedier, more responsive Windows 7 VM for my pains.

Access to host directories needed reinstatement using a combination of the VMware Shared Folders feature and updating drive mappings in Windows 7 itself to use what appeared to it as network drives in the Shared Folders directory on the \\vmware-host domain. For that to work, VMware Tools needed to be installed in the guest OS (go to Virtual Machine > Install VMware Tools to make available a virtual CD from which the installation can be done) as I discovered when trying the same thing with my Windows 8 VM, where I dare not instate VMware Tools due to their causing trouble when I last attempted it.

Moving virtual machine software brought about its side effects, though. Software like Windows 7 detects that it's on different hardware, so reactivation can be needed. While Windows 7 reactivation was a painless online affair, it wasn't the same for Photoshop CS5. That meant that I needed help from Adobe's technical support people top get past the number of PC's for which the software already had been activated. In hindsight, deactivation should have been done before the move, but that's a lesson that I know well now. Technical support sorted my predicament politely and efficiently while reinforcing the aforementioned learning point. Moving virtual machine platform is very like moving from one PC to the next, and it hadn't clicked with me quite how real those virtual machines can be when it comes to software licensing.

Apart from that and figuring out how to do it, the move went smoothly. An upgrade to the graphics driver on the host system and getting Windows 7 to recheck the capabilities of the virtual machine even gained me a fuller Aero experience than I had before then. Full screen operation is quite reasonable too (the CTRL + ALT + ENTER activates and deactivates it) and photo editing now feels less boxed in too.

Installing VMware Player 4.04 on Linux Mint 13

Curiosity about the Release Preview of Windows 8 saw me running into bother when trying to see what it's like in a VirtualBox VM. While doing some investigations on the web, I saw VMware Player being suggested as an alternative. Before discovering VirtualBox, I did have a licence for VMware Workstation and was interested in seeing what Player would have to offer. The, it was limited to running virtual machines that were created using Workstation. Now, it can create and manage them itself and without any need to pay for the tool either. Registration on VMware's website is a must for downloading it, though, but that's no monetary cost.

Once I had downloaded Player from the website, I needed to install it on my machine. There are Linux and Windows versions; it was the former that I needed, and there are 32-bit and 64-bit variants, so you need to know what your system is running. With the file downloaded, you need to set it as executable and the following command should do the trick once you are in the right directory:

chmod +x VMware-Player-4.0.4-744019.i386.bundle

Then, it needs execution as a superuser. With sudo access for my user account, it was a matter of issuing the following command and working through the installation screens to instate the Player software on the system:

sudo ./VMware-Player-4.0.4-744019.i386.bundle

Those screens proved easy for me to follow, so life would have been good if that were all that was needed to get Player working on my PC. Having Linux Mint 13 means that the kernel is of the 3,2 stock and that means using a patch to finish off the Player installation because the required VMware kernel modules seem to silently fail to compile during the installation process. This only manifests itself when you attempt to start VMware Player afterwards to find a module installation screen appear. That wouldn't be an issue of itself were it not for the compilation failure of the vmnet module and subsequent inability to start VMware services on the machine. There is a prompt to peer into the log file for the operation, and that is a little uninformative for the non-specialist.

Rummaging around the web brought me to the requisite patch, and it works for Player 4.0.3 and Workstation 8.0.2 by default. Doing some tweaking allowed me to make it work for Player 4.04 too. My first step was to extract the contents of the tarball to /tmp where I could edit patch-modules_3.2.0.sh. Line 8 was changed to the following:

plreqver=4.0.4

With the amendment saved, it was time to execute the shell script as a superuser, having made it executable beforehand. This can be accomplished using the following command:

chmod +x patch-modules_3.2.0.sh && sudo ./patch-modules_3.2.0.sh

With that completed successfully, VMware Player ran as it should. An installation of Windows 8 into a new VM ran very smoothly, and I was impressed with the performance and responsiveness of the operating system within a Player VM. There are a few caveats, though. First, it doesn't run at all well with VMware Tools, so it's best to leave them uninstalled since it doesn't seem to need them either; it was possible to set the resolution to the same as my screen and use the CTRL+ALT+ENTER shortcut to drop in and out of full screen mode anyway. Second, the unattended Windows installation wasn't the way forward for setting up the VM, but it was no big deal to have that experiment thwarted. The feature remains an interesting one, though.

With Windows 8 running so well in Player, I was reminded of the sluggish nature of my Windows 7 VM and an issue with a Fedora 17 one too. The result was that I migrated the Windows 7 VM from VirtualBox to VMware, and all is so much more responsive. Getting it there took not a little tinkering, so that's a story for another entry. Based on my experiences so far, I reckon that VMware Player will remain useful to me for a little while yet. Resolving the installation difficulty was worth that extra effort.

Uninstalling VirtualBox Guest Additions on a Linux Guest OS

Within the last few days, I updated my Linux Mint Debian Edition virtual machine installation to Update 4. Between not following the instructions so closely and problems with the update server, a re-installation preceded the update itself. When all was done, no desktop environment appeared, and issuing the startx command revealed that it was one of the VirtualBox drivers that was the cause of the problem. With my being unable to see any files on the VirtualBox virtual CD, something else needed doing and the executing following command (replacing [VboxAddonsFolder] with VBoxGuestAdditions-4.1.12 in my case, but it is different for each VirtualBox version) resolved the situation:

/opt/[VboxAddonsFolder]/uninstall.sh

When it was complete, a scrambled desktop began to appear, so a reboot was to set things to rights. Then, I could set to looking at what Update 4 had brought to Linux Mint Debian Edition.

Getting Gnome Shell going for Fedora 16 running in VirtualBox

There are a number of complaints out there about how hard it is to get GNOME Shell running for a Fedora 16 installation in a VirtualBox virtual machine. As with earlier versions of Fedora, preparation remains a matter of having make, gcc and kernel-devel (kernel headers, in other words). While I have got away with just those, adding dkms (dynamic kernel module support) to the list might be no bad idea either. To get all of those instated, it is a matter of running the following command as root or using sudo:

yum -y install make gcc kernel-devel dkms

The -y switch ensures that any Y/N prompts that usually appear are suppressed and that the installation is completed. Just leave it out if you are inclined to get second thoughts. Another item that has been needed with a previous release of Fedora is libgomp, but I haven't had to add this for Fedora 16 if I recall correctly.

Once those are in place, it is time to install the VirtualBox Guest Additions.  Going to Devices > Install Guest Additions... mounts a virtual CD that can be used for the installation of the various drivers that are needed. To do the installation, first go to where the installer is located using the following command:

cd /media/VBOXADDITIONS_4.1.6_74713/

Note that this location will change according to the release and build numbers of VirtualBox, yet the process essentially will be the same aside from this. Once in there, issue the following command as root or using sudo:

./VBoxLinuxAdditions.run

Hopefully, this will complete without errors now with the precursor software that has been added beforehand. However, there is one more thing that needs doing, or you will get the GNOME 3 fallback desktop instead. It pertains to SELinux, an old adversary of mine that got in the way when I was setting up a web server on a machine running Fedora. It doesn't recognise the new VirtualBox drivers as it should, so the following command needs executing as root or using sudo:

restorecon -R -v /opt

Doing this restores the SELinux contexts for the /opt directories within which the VirtualBox software directories are found. The -R switch tells it to act recursively and -v makes it verbose. When it has done its work, hopefully successfully, it is time to reboot the virtual machine, and you should have a GNOME Shell desktop interface when you log in.

A spot of roughness with VirtualBox 3.02 on Ubuntu

Among the various things that I needed to do on Saturday, I got to look at why VirtualBox Windows guests could not shut down and the processes killed. Though it wasn't clear at the outset, my suspicions began to centre on the sound hardware emulation and how it interacted with the host's sound capabilities. A look at the VirtualBox log sent me that way after a spot of experimentation with reinstalling Windows 7 and adding the Guest Additions along with removal and reinstatement of the same for a Windows XP guest that makes my like easier. It also seems that the same problem blighted the start-up of Linux guests too. Either removing virtual sound hardware or using the null sound driver seems to allow things to run smoothly. That may not sound ideal, yet it doesn't bother me, with the host providing all that I need. Also, it's a moot point whether I have come across a bug in VirtualBox or whether using Ubuntu on a hardware configuration on which it wasn't originally installed is the cause, but I have found a way forward that suits me. Saying that, if I find that the issue disappears in a future, that would be even better.

/sbin/mount.vboxsf: mounting failed with the error: Protocol error

These days, my virtualisation needs are being well served by VirtualBox 2.2. Though it may be the closed source variant, I have no complaints about it. Along with a number of Windows VM's, I also have one running Ubuntu 9.04 and, for the first time, I seem to have VirtualBox's Guest Additions playing with a Linux guest as they should. Even the Shared Folders functionality is working.

However, I did get one problem when I tried out the last feature for the first time. The procedure is to issue a command like the following in a terminal session after creating the requisite directory in the file system and adding a host directory as a shared folder:

sudo mount -t vboxsf Music /mnt/host_music/

Above, Music is the name of the folder in the VirtualBox manager and /mnt/host_music in the directory in the guest file system. However, this returned the message at the head of this post at that first attempt:

/sbin/mount.vboxsf: mounting failed with the error: Protocol error

The solution thankfully turns out to be an easy one: reinstalling the Guest Additions, which certainly did the trick for me. The cause would appear to have been an update to Ubuntu, and 9.04 is understandably in a state of flux at the moment (I suspect kernel upgrades because of my previous experiences). Regardless of this, it is good to know that it's a problem with a simple fix, and I am seeing the niceties of a larger virtual screen system together with automatic grabbing and releasing of the mouse cursor too. While there may be a chance to explore the availability of these sorts of features to other Linux guests, I have other things that I should be doing and there's sunshine outside to be enjoyed.

A performance improvement?

Having just upgraded to VirtualBox 2.1.4, I noticed something surprising: a performance improvement. However, I didn't notice this with a Windows 2000 guest, but a Windows XP one now ran freely when it felt like it was immersed in treacle before. Since I had some photos to process for the hillwalking blog, that was a welcome boost and will be well-used if it continues. What's more, a Windows 7 VM that I have doesn't run so sluggish now either. These observations do point towards 2.1.2 being a sluggard on my Ubuntu box, though Windows hogs like Norton 360 didn't help matters either. Whatever the truth was, things now feel much better and any enhancement to system speed has to be a good thing.

Running Windows 7 within VirtualBox

With all the fanfare that surrounded the public beta release of Windows 7, I suppose that the opportunity to give it a whirl was too good to miss. Admittedly, Microsoft bodged the roll-out by underestimating the level of interest and corralling everyone into a 24-hour time slot, with one exacerbating the other. In the event, they did eventually get their act together and even removed the 2.5 million licence limit. Thus, I suppose that they really needed to get 7 right after the unloved offering that was Vista, so they probably worked out that the more testers that they get, the better. After, it might be observed that the cynical view that the era of making people pay to "test" your products might be behind us and that users just want things to work well if not entirely faultlessly these days.

After several abortive raids, I eventually managed to snag myself a licence and started downloading the behemoth using the supplied download manager. I foresaw it taking a long time and so stuck with the 32-bit variant so as not to leave open the possibility of that part of the process using up any more of my time. As it happened, the download did take quite a few hours to complete, but this part of the process was without any incident or fuss.

Once the DVD image was downloaded, it was onto the familiar process of building myself a VirtualBox VM as a sandbox to explore the forthcoming incarnation of Windows. After setting up the ISO file as a virtual DVD, installation itself was an uneventful process, yet subsequent activities weren't without their blemishes. The biggest hurdle to be overcome was to get the virtual network adapter set up and recognised by Windows 7. The trick is to update the driver using the VirtualBox virtual CD as the source because Windows 7 will not recognise it using its own driver repository. Installing the other VirtualBox tools is a matter of going to Compatibility page in the Properties for the relevant executable, the one with x86 in the file name in my case, and setting XP as the Windows version (though Vista apparently works just as well, I played safe and depended on my own experience). While I was at it, I allowed the file to run under the administrator account, too. Right-clicking on executable files will bring you to the compatibility troubleshooter that achieves much the same ends but by a different route. With the Tools installed, all was workable rather than completely satisfactory. Shared folders have not worked for, but that might need a new version of the VirtualBox software or getting to know any changes to networking that come with Windows 7. I plan to stick with using USB drives for file transfer for the moment. Though stretching the screen to fit the VirtualBox window was another thing that would not happen, that's a much more minor irritation.

With those matters out of the way, I added security software from the list offered by Windows with AVG, Norton and Kaspersky being the options on offer. I initially chose the last of these but changed my mind after seeing the screen becoming so corrupted as to make it unusable. That set me to rebuilding the VM and choosing Norton 360 after the second Windows installation had finished. That is working much better, and I plan to continue my tinkering beyond this. I have noticed the inclusion of PowerShell and an IDE for the same, so that could be something that beckons. All in all, there is a certain solidity about Windows 7, though I am not so convinced of the claim of speedy startups at this stage. Time will tell and, being a beta release, it's bound to be full of debugging code that will not make it into the final version that is unleashed on the wider public.

Getting VirtualBox 2.02 working on Ubuntu 8.04

Having run VirtualBox OSE (1.5.6) for a while now, I succumbed to the idea of grabbing the latest version from the VirtualBox website and putting it on my main Linux box. The idea of having 64-bit support proved irresistible, and I did get OpenSolaris to start, even if its installation on a VMware VM meant that it stalled along the way.

To accomplish this, I needed to rid my system of all traces of the old version before 2.02 would install, with a system reboot being needed before the process of installation fully completed. Then, I fired up a Windows XP virtual machine, only for it to completely freeze. The hint as to the cause came when I opened up the VM's settings for the following message to greet me:

Could not load the Host USB Proxy Service (VERR_FILE_NOT_FOUND). The service might be not installed on the host computer.

While it didn't stop things in their tracks when it came to accessing and changing those settings, it was a vital hint for working out what was happening. It now seems that a problem with USB port support was the cause. The fact that issuing the following command got things going for me appeared to confirm the prognosis.

sudo  mount -t usbfs /sys/bus/usb /proc/bus/usb/

Of course, not wanting to have to issue the same command over and over again, I was after a more permanent solution. That involved adding the following lines to /etc/fstab:

#usbfs

none /proc/bus/usb usbfs devgid=46,devmode=664 0 0

A reboot later, that change apparently was enough to settle the matter, and I am now able to run VM's as before. Seamless application mode is going well (the host key - right Ctrl by default - + L key combination is sufficient to toggle the setting on and off), even if it has a few quirks. Two that I have spotted include the usual Ubuntu screen furniture disappearing when maximised windows are displayed, and the Windows taskbar appearing when two or more applications are running. That last one may be just as well because individual applications don't get an Ubuntu taskbar icon each, which is perhaps an idea for a future enhancement. Updating Guest Additions in a VM's doesn't seem to change the behaviour, but any imperfections are curiosities rather than complaints given how well things run anyway, unless you decide to confound matters by closing and minimising windows, but resolving that is just a toggle away. It's all looking good so far...