Wednesday Apr 06, 2011

Errors when importing OVF appliances

This is another quick note to self which others may also benefit from....

There was a bug in the Export OVF code of VirtualBox 3.2.8 (and earlier) with vm's that have multiple hard disks. The bug was that each hard disk was given the same unique ID (UUID). Although the export seemed to work correctly, the resultant ovf looked something like this:

...
      <StorageController name="SATA Controller" type="AHCI" PortCount="2" useHostIOCache="false" IDE0MasterEmulationPort="0" IDE0SlaveEmulationPort="1" IDE1MasterEmulationPort="2" IDE1SlaveEmulationPort="3">
          <AttachedDevice type="HardDisk" port="0" device="0">
            <Image uuid="{eb5b9e44-321f-4cc7-84c3-781fd9d5a661}"/>
          </AttachedDevice>
          <AttachedDevice type="HardDisk" port="1" device="0">
            <Image uuid="{eb5b9e44-321f-4cc7-84c3-781fd9d5a661}"/>
          </AttachedDevice>
      </StorageController> 
...

and so when you came to import the appliance, the import failed because there are 2 disks with the same UUID.

The right solution is that the creator of the vm should upgrade to 3.2.12 or later and re-export again. But a hacky solution involves hand editing the ovf file:

  1. remove the section between:
  2. <vbox:Machine ....>
    ....
    </vbox:Machine>
    
  3. remove/rename the .mf manifest file (because the digital signature will be wrong now we've changed the .ovf file)
  4. try importing again. 

HTH 

- FB 

Tuesday Feb 09, 2010

Migrating from VMware to VirtualBox (Part 1): Oracle Enterprise Linux

There are a growing number of people asking the question: how do you move a VMware virtual machine to VirtualBox. So it is about time the Fat Bloke rolled up his sleeves and showed us how. (BTW you can click on screenshots below to magnify)

People typically want to do this because they have spent time installing a guest OS together with a software stack and they don't really want to go thru all this again. But moving a vm from one virtualization platform to another is analogous in the real world to unplugging a hard drive(s) from one computer and plugging it into a different manufacturer's computer. You may find that the guest operating system gets upset when it boots up and sees virtual hardware which is different than it was expecting. Different guest operating systems react differently to this situation (Linux is typically more accommodating than Windows in this respect).  In fact some guest operating systems get so upset, they may BSOD (Blue Screen of Death) on you.

Secondly, some of the software that you have installed above the OS, such as VMware Tools, may also be relying on specific virtual hardware.

So the Fat Bloke's First Rule of VM Migration is: Don't, if you can help it. If you can create a new vm from scratch on the new virtualization platform, you probably should. That way the guest OS installs the right drivers for your particular virtual hardware, and you are not left with orphaned software which needs a specific virtualization layer.

That said, there are still going to be people looking to avoid a complete reinstallation and willing to live dangerously, so let's discuss what is possible. Note that because different guests behave so differently we're going to focus on one guest OS in this blog: Oracle Enterprise Linux, and we'll move it from VMware Workstation 7 to VirtualBox 3.1. Here is our start state, the vm running in VMware Workstation 7 on Windows 7:

Starting Position

Step 1 - Preparing to Migrate 

It's a good idea to take a copy of the vm that we're trying to migrate just in case you make a mess of things. With VMware Workstation you can clone a vm to do this or copy the machine in some other way such as copying files.

Clone

To prepare for migration we're going to remove virtualization platform-specific components:

  1. Remove VMware tools
  2. Reset the Display and Input device  configuration
  3. Remove incompatible devices 

The Fat Bloke's Second Rule of VM Migration is that it is easier to unpick platform-specific software on the native virtualization platform. So let's start up the vm under VMware to prepare for migration

Removing VMware Tools 

This is easy enough: 

vmware-uninstall-tools.pl

and you should see something like this:

uninstall tools

Resetting the Display Device and Input Devices

When Oracle Linux was first installed the display was set as a VMware display adaptor and input devices as a VMware keyboard and mouse. By the time we're finished this won't be the case, so let's prepare for that by moving aside the the OEL X.org conf file like this:

mv /etc/X11/xorg.conf /etc/X11/xorg.conf.vmware

This file will get recreated later when we run on the VirtualBox platform.

Now let's shutdown the guest. 

Shutdown

Remove Incompatible Devices

The VMware soundcard device is different from the one that VirtualBox exposes so let's remove this device from the vm configuration in the VMware Settings dialog:

Remove Soundcard

Step 2 - Exporting the Virtual Machine

A Virtual Machine consists of :

  • configuration information (in VMware a .vmx file)
  • virtual hard drive(s) which the guest is installed on. (in VMware, typically .vmdk files)

An emerging standard for encapsulating this information to allow vm's to be transported more easily is the OVF or Open Virtualization Format. So in theory you should be able to Export this vm from VMware Workstation and Import into VirtualBox. Sadly, the VMware conversion wizard (File...Import or Export...) doesn't support Oracle Enterprise Linux as a guest:

can't export

But there is a command line ovftool that can be downloaded from VMware's site.

So in a Windows command.exe window you can run:

cd C:\\Users\\fatbloke\\Documents\\Virtual Machines\\Clone of Oracle Enterprise Linux 
"\\Program Files\\VMware\\VMware OVF Tool"\\ovftool.exe "Clone of Oracle Enterprise Linux.vmx" OEL.ovf 

And eventually you end up with 3 files:

  1. OEL.ovf - configuration information
  2. OEL-disk1 - compressed disk format file
  3. OEL.mf -  digital signatures (SHA1) of the other files.

 We can now move these to the destination system for import by VirtualBox.

Step 3 - Importing into VirtualBox 

You can import an ovf file into VirtualBox from the graphical user interface or the command-line.

Import OVF

Importing this takes a while as the compressed disk is converted to a usable format, but your should end up with a new entry in your vm list in VirtualBox like this:

Imported vm

 Now the moment of truth, Start it up...and we should see Oracle Enterprise Linux boot up under VirtualBox

OEL under VirtualBox

 Step 4 - Install the VirtualBox Guest Additions

 Finally don't forget to install the VirtualBox Guest Additions which is the mirror image operation to removing the VMware Tools.

Install Guest Additions

Once you have mounted the Guest Additions iso image you can run install them from the mounted directory using the command:

sh VBoxLinuxAdditions-x86.run 

 Like this:

Install GA

And after a restart of the guest you are all set to go.

Migration is complete! 

Epilogue (Advanced users only)

There is an alternative to step 2 and 3 above for people who know what they are doing.

After performing Step 1 you could simply take the VMware disk image (.vmdk)  and plug this into a manually configured VirtualBox vm. This effectively relies on the user to create an appropriately similar vm instead of relying on the ovf export and import (Steps 2 and 3 above) process. Note that the default disk controller used by VMware is an LSI SCSI controller, so when manually creating a VirtualBox vm you need to configure it appropriately. 

Add SCSI Controller

You still need Step 4 for optimal performance and ease of use. And don't forget the tip about Speeding up Linux Guests too.

Good Luck!

- FB 

About

Fat Bloke

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today