VirtualBox

VirtualBox is the virtualization system used to run the GridSeed VMs in the SISSA/Democritos testbed.

VirtualBox can export VMs in the OVF format which can be read by VMware and Xen.

How to start a VirtualBox VM

VirtualBox VMs are started in "headless" mode by default, meaning that you will not have any way to access the VM console. It is instead convenient to start them with VRDP ("remote desktop") support, which allows console connections through the rdesktop-vrdp tool.

0. Configure VRDP support and TCP port:

  VBoxManage modifyvm a-vm-name --vrdp on --vrdpport XXXX

Note:

  • The port XXXX must be unique across all VMs running on the same host! If two VMs share the same VRDP port, the one started last will fail to open the remote desktop server: the VM will start, but you will not be able to connect.
  • You can use a range XXXX-YYYY instead of a single port: VirtualBox will use the first available port in the range, but the only way to retrieve the actual port used is the output of the VBoxManage showvminfo tool.

1. Start a VM with remote desktop support:

  VBoxManage startvm a-vm-name --type vrdp

2. Connect to the VM console:

  rdesktop-vrdp -KPz localhost:XXXX

where XXXX is the VRDP port configured in step 0. (Substitute localhost with the VM host name for non-local --i.e., network-- connections.)

If you do not know which port a specific VM is listening to, you can find out with:

  VBoxManage showvminfo the-vm-name

Browsing the output, you should find lines like:

Name:            ce-1
... several other lines ...
VRDP:            enabled (Address 0.0.0.0, Ports 3389, MultiConn: off, ReuseSingleConn: off, Authentication type: null)
VRDP port:       3389
... some more stuff below ...

which says that remote desktop for VM ce-1 can be found on TCP port 3389.

How to use a VMware VM into VirtualBox

The easiest way is likely to save the VM from VMware in OVF format, and then import it into VirtualBox (see below).

How to use an OVF VM in VirtualBox

VirtualBox can import and convert OVF appliances into its native format (XML + disk file).

First, run the VBoxManage import command in "dry-run" mode, to test the import and see a table of parameters which can be overridden:

  cd /directory/containing/ovf/and/vmdk/file
  VBoxManage import vm-file.ovf -n

Note:

  • import works by copying the VMDK disk file, so you will need twice the space occupied by a VM disk during the import phase.
  • you cannot override the location where the VMDK disk file will be copied: it will always end up in the default VirtualBox hard-disk storage (see below).

How to change VirtualBox's default VM and hard-disk location

By default, VirtualBox is configured to keep VM definition files and hard-disk data files into separate locations. The initial path for the VM definition storage is directory .VirtualBox/Machines in the users' home, and the hard-disk data is to be found in .VirtualBox/Harddisks

These locations can be changed with the commands VBoxManage setproperty machinefolder and VBoxManage setproperty hdfolder.

In particular, to have VirtualBox import store machine definitions and HDs under the same directory /vms, one can issue the commands:

  VBoxManage setproperty machinefolder /vms
  VBoxManage setproperty hdfolder /vms

Issues with VirtualBox

While initially deployed because VMware showed serious sinchronization issues, VirtualBox has unfortunately proven no better...

Here's a list of the issues encountered so far with VirtualBox:

  • Disk failure problems. It has already occurred in arc-ce and ce-1 that the VM becomes unresponsive because of disk problems. No traces of disk problems on the host computer could be found, and it appears that a restart of VirtualBox cures the problem (at least temporarily). The issue definitely needs more investigation, but it might well be a show stopper!
  • VMs easily go out of time synch. The VBox guest additions should be able to cure this, but infact they are not (just like VMware). Possible directions to investigate further:
    • try running VMs with a uniprocessor kernel (instead of the SMP one)
    • try using different ostype settings (currently we're using the "generic Linux" entry, but there are specific entries for "RedHat" and "Linux 2.6" which might be better).
    • as a last resort, run rdate master.grid.seed every minute...