Technology Tales

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.

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.

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...

Things that I like about VirtualBox OSE

Now that VirtualBox 2.0 is out with its 64-bit operating system support among other things, the version included in Ubuntu 8.04, OSE 1.56, is looking that bit older. Nevertheless, there remains a lot to like about the version that I have been using.

For one thing, its Shared Folders functionality doesn't trip up Photoshop Elements like VMware does. VMware so hobbled Photoshop's ability to save back to the Linux file system that it had me looking at the WINE route; I also got to use GIMP for a while. VirtualBox brought me back into the Photoshop fold, and I seem to like the results that I can get with Elements better than those from GIMP.

Another nicety is the way that guest OS desktops can be resized to fit in a maximised VM window. For this to work, you need VirtualBox Guest Additions in place in the virtual machine, but it works very well when all is in place; my experience is with Windows XP. Full screen is on tap too once you use the Host+F combination; the right hand control key is usually the Host key by default. If there is any criticism at all, it might be that seamless application windows are not available in OSE 1.5.6.

Linux kernel changes can upset things, but drivers don't take too long to appear, and you can always take matters into your own hands anyway. It's a far cry from the blithe indifference of VMware and the need to resort to vmware-any-any patching to get things under way again.

All in all, VirtualBox OSE treats me very well. Guest operating systems may seem sluggish at times, but it's never enough to annoy or seriously impede usage. It'll be interesting to see if a newer version of VirtualBox makes it into Ubuntu 8.10.

Getting VirtualBox working on Ubuntu after a kernel upgrade

In previous posts, I have talked about getting VMware Workstation back on its feet again after a kernel upgrade. It also seems that VirtualBox is prone to the same sort of affliction. However, while VMware Workstation fails to start at all, VirtualBox at least starts itself even if it cannot get a virtual machine going and generates errors instead.

My usual course of action is to fire up Synaptic and install the drivers for the relevant kernel. Looking for virtualbox-ose-modules-[kernel version and type] and installing that usually resolves the problem. For example, at the time of writing, the latest file available for my system would be virtualbox-ose-modules-2.6.24-19-generic.  If you are a command line fan, the command for this would be:

sudo apt-get install virtualbox-ose-modules-2.6.24-19-generic

The next thing to do would be to issue the command to start the vboxdrv service, and you'd be all set:

sudo /etc/init.d/vboxdrv start

There is one point of weakness (an Achilles heel, if you like) with all of this: the relevant modules need to be available in the first place and I hit a glitch after updating the kernel to 2.6.24-20 when they weren't; I do wonder why Canonical fail to keep both in step with one another and why the new kernel modules don't come through the updates automatically either. However, there is a way around this too. That means installing virtualbox-ose-source via either Synaptic or the command line:

sudo apt-get install virtualbox-ose-source

The subsequent steps involve issuing more commands to perform a reinstallation from the source code:

sudo m-a prepare

sudo m-a auto-install virtualbox-ose

Once these are complete, the next is to start the vbox drv as described earlier and to add yourself to the vboxusers group if you're still having trouble:

sudo adduser [your username] vboxusers

The source code installation option certainly got me up and running again, and I'll be keeping it on hand for use should the situation raise its head once more.

Disk corruption can be virtual too

It's the sort of sight that causes you to fear the worst, an unchanging black screen with a flashing cursor. That was what started to greet me recently when I tried to fire up a Windows XP guest in VMware Workstation. The cause was the corruption of a virtual disk, an ominous thing that affected a supplemental virtual hard drive that I had added to the virtual machine rather than its main one. Though there might have been some data on there, it was nothing that I didn't have elsewhere anyway. Removing the broken disk from the XP VM returned the situation to fuller health, and I simply tried creating a new one again. So far, this seems to be working fine, yet I'll be keeping a watchful eye on things.

So far, I have no idea why the corruption happened, but the broken disk files were created without a VMDK extension, which might indicate that something was amiss with the process that created them. While it would be better if VMware highlighted the state of its virtual disks, it was when I tried opening the trashed disk with VirtualBox that a warning was given and VMware did the same when I tried it with that afterwards (opening VMware virtual disks with VirtualBox is possible, but you need to ensure that no attempt at importation is made, or you could end up with a breakage). While I may have discovered the fault in a roundabout manner, it's better to know what's gone wrong than not to know at all.