Technology Tales

Migrating a virtual machine from VirtualBox to VMware Player on Linux

The progress of Windows 10 is something that I have been watching. Early signs have been promising, and the most recent live event certainly contained its share of excitement. The subsequent build that was released was another step in the journey, though the new Start Menu appears more of a work in progress than it did in previous builds. Keeping up with these advances sometimes steps ahead of VirtualBox support for them, and I discovered that again in the last few days. VMware Player seems unaffected, so I thought that I'd try a migration of the VirtualBox VM with Windows 10 onto there. In the past, I did something similar with a 32-bit instance of Windows 7 that subsequently got upgraded all the way up to 8.1, but that may not have been as slick as the latest effort, so I thought that I would share it here.

The first step was to export the virtual machine as an OVF appliance, and I used File > Export Appliance... only to make a foolish choice regarding the version of OVF. The one that I picked was 2.0 only to subsequently discover that 1.0 was the better option. The equivalent command line would look like the following (there are two dashes before the ovf10 option below):

VboxManage export [name of VM] -o [name of file].ova --ovf10

VMware has a tool for extracting virtual machines from OVF files that will generate a set of files that will work with Player and other similar products of theirs. It goes under the unsurprising name of OVF Tool and usefully works from a command line session. When I first tried it with an OVF 2.0 files, I got the following error, and it stopped doing anything as a result:

Line 2: Incorrect namespace http://schemas.dmtf.org/ovf/envelope/2 found.

The only solution was to create a version 1.0 file and use a command like the following:

ovftool --lax [name of file].ova [directory location of VM files]/[name of file].vmx

The --lax option is needed to ensure successful execution, even with an OVF 1.0 file as the input. Once I had done this on my Ubuntu GNOME system, the virtual machine could be opened up on VMware Player and I could use the latest build of Windows 10 at full screen, something that was not possible with VirtualBox. This may be how I survey the various builds of the operating that appear before its final edition is launched later this year.

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.

Removing VMware Player from Linux Mint Debian Edition

A whole slew of updates has appeared for my Linux Mint Debian Edition PC. However, to instate them, I needed to remove VMware Player and this is the command to do so:

sudo vmware-installer -u vmware-player

It worked in my case, and my system updates are in progress as I write this. The same command should work for other Linux distros where VMware Player was installed using the *.bundle installer. VMware Player remains in place on my main PC though, so I am not ditching it just yet, even if I have to be careful when running it on Linux Mint 13 so as not to freeze the system on myself.

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.

Watch where you store your virtual machines when using VMware on Linux

My experience is with Ubuntu on this one, but I have found that you need to be careful as regards the file system used by the drive where you keep your virtual machines. If it is NTFS, VMware can fail to start a VM because it cannot create a virtual memory file while it presents as physical memory to a guest operating system. Use ext2 or ext3 and there should be no problem, even if that means formatting a drive to fulfil the need. That's what I did and all was well thereafter.

Turning the world on its head: running VMware on Ubuntu

When Windows XP was my base operating system, I used VMware Workstation to peer into the worlds of Windows 2000, Solaris and various flavours of Linux, including Ubuntu. Now that I am using Ubuntu instead of what became a very flaky XP instance, VMware is still with me, which I am using it to keep a foot in the Windows universe. In fact, I have Windows 2000 and Windows XP virtual machines available to me that should supply my Windows needs.

An evaluation version of Workstation 6 is what I am using to power them and I must admit that I am likely to purchase a licence before the evaluation period expires. Installation turned out to be a relatively simple affair, starting with my downloading a compressed tarball from the VMware website. The next steps were to decompress the tarball (Ubuntu has an excellent tool, replete with a GUI, for this) and run vmware-install.pl. I didn't change any of the defaults and everything was set up without a bother.

In use, a few things have come to light. The first is that virtual machines must be stored on drives formatted with EXt3 or some other native Linux file system rather than on NTFS. Do the latter, and you get memory errors when you try starting a virtual machine; I know that I did and that every attempt resulted in failure. After a spot of backing up files, I converted one of my SATA drives from NTFS to Ext3. For sake of safety, I also mounted it as my home directory; the instructions on Ubuntu Unleashed turned out to be invaluable for this. I moved my Windows 2000 VM over and it worked perfectly.

Next on the list was a series of peculiar errors that cam to light when I was attempting to install Windows XP in a VM created for it. VMware was complaining about a CPU not being to run fast enough; 2 MHz was being stated for an Athlon 64 3000+ chip running at 1,58 GHz! Clearly, something was getting confused. Also, my XP installation came to a halt with a BSOD stating that a driver had gone into a loop, with Framebuf fingered as the suspect. I was seeing two symptoms of the same problem and its remedy was unclear. A message on a web forum put the idea of rebooting Ubuntu into my head, and that resolved the problem. For now, I'll be keeping an eye on it, though.

Otherwise, everything seems to be going well with this approach, and that's an encouraging sign. It looks as if my current Linux-based set up is one with which I am going to stay. This week has been an interesting one already, and I have no doubt that I'll continue to learn more as time goes on.

From real to virtual…

In a previous entry, I mused over a move from Windows to Linux, a suggestion being that Fedora Core Linux would be my base operating system with Windows installed in a Xen virtual machine. That, of course, led me to wonder how I would swap my current situation about: Linux in VM, Windows as host. Meantime, I discovered something that makes the whole process a little easier: VMware Convertor.

The Starter version can be downloaded free of charge, while the Enterprise edition comes with VirtualCenter Management Server for corporate use. What it does is to make a virtual version of a real computer, a process that takes drive imaging much, much further. I have given it a whirl and the conversion seems to go well; the only thing left is for me to fire it up in VMware Workstation - I believe that Player and Server will also run the VM that is created and, like Convertor Starter, they also can be downloaded free of charge; Workstation does everything for me, so I haven't looked beyond it, even though it did cost me money all those moons ago - and get through licence activation issues without leaving me with no authorised Windows installation.