For many years now, Sun provides ISVs with on-line access to Solaris, MySQL, PostgreSQL, Java, Netbeans, compilers, and much more.  This service is named EZQual and is used to evaluate Sun software,  and port and test applications on the Sun platform. To satisfy the demand we must be able to host many ISVs on a single system so we decided from scratch that the service would be implemented using virtualization, just like a cloud. Also, to provide a better user experience we decided to offer a remote desktop feature that, in conjunction with the virtualiztion, really offers what is known as a virtual desktop.

So far virtualization has been based on Solaris containers. Amongst other advantages, containers are easily provisioned by cloning a first template container. This feature is useful when - like us - you provision a complete stack of applications on top of the OS: you don't have to reprovision the complete stack for each new container.

As per the remote desktop it is based on Sun Virtual Desktop Infrastructure (Sun VDI).

In the last months I extended the flexibility of the service to enable people within the company to create customized OS images - say one for JavaFX, another fo the Sun WebStack - and to be able to provision these images on EZQual. VirtualBox perfectly fits that need because anybody can download it on its laptop, create an OS virtual disk image (VDI), and install additional software as needed on the VDI. Eventually the VDI is transfered to the EZQual lab and used as a template to create VirtualBox vms.

The rest of this article is a how-to that explains how the VBox provisioning is automated in an existing cloud-like environment such as EZQual. I am using OpenSolaris as an example for showing how the guest OS configuration can be automated too. In addition the source code of this "VirtualBox factory" is available at Kenai.com

Creating a Template VDI

As already mentioned, the template VDI is created 'by hand' using the VBox GUI: a brand new VM is created with a fix size disk (a.k.a. vdi). A disk with a dynamic size can not be cloned.  Since I am using OpenSolaris as the guest OS the OS type is set to Solaris . The OpenSolaris 2009.06 install takes less than 2.5GB of disk space. I create a disk of 10GB to be comfortable with additional software. The vdi is named templateOSolaris.09.06.vdi and the VM templateOSolaris.09.06. The vdi is located in ~/.VirtualBox/HardDisks.

More has to be done to prepare the vdi for the final OpenSolaris configuration. This is cover in the Configuring the Guest OS paragraph.

Installing Additional Software on the VDI

Additional software is installed on the template VDI by running OpenSolaris in the VBox. The software is download through the OpenSolaris Package Manager. To have associated services automatically started when a VBox vm is booted, I enable these services with the Service Management Facility (smf). Here are the commands executed from the guest OpenSolaris for a handful of applications such as AMP, OpenOffice, Netbeans, Glassfish:

AMP:
# pkg install amp
# svcadm enable mysql:version_51
# svcadm enable apache22

OpenOffice:
# pkg install openoffice

Netbeans:
# pkg install netbeans-full

Glassfish:
# pkg install glassfishv2

Provisioning a VBox VM from a Template VDI

Now that I have a template vdi, I want to create my first vm vbox1. This is a two-step process: first the template vdi is cloned to create a new vdi, then a new vm is created that uses the new vdi.

Let's start by cloning the vdi. Note that cloning with a "cp" command or through a ZFS clone won't work. I need to used the clonehd command so that VBox can assign a unique identifier to the new vdi and register it in its repository:

# VBoxManage clonehd  ~/.VirtualBox/HardDisks/templateOSolaris.09.06.vdi \
~/VirtualBox/HardDisks/vbox1.vdi –remember

Now, the vm creation per see:

# VBoxManage createvm --name vbox1 --register

# VBoxManage modifyvm vbox1 --memory "1000MB" -vram "32MB"\
        --ostype "OpenSolaris" --acpi on --macaddress1 020000000031 \
        --nic1 bridged --bridgeadapter1 e1000g0 --hda vbox1.vdi

The --nic1 and --bridgeadapter1 options set the network configuration of vbox1. By default vms acquire their IP-addresses and access the network through the VBox hypervisor that acts both as a NAT proxy and as a dhcp server. The integration with the existing infrastructure requires vms to be connected to the lab local network. The good news is that the VirtualBox hypervisor supports a bridged networking mode. In this mode the guest OS uses a device driver on the host to access the physical network adapter - in my case e1000g0. When a guest is using this mode, it looks as if it were physically connected to the physical interface using a network cable.

To finalize the network setting, I also provide the vm with a specific mac-address by using the --macaddress1 option. Mac addresses are used to uniquely identify the vms and provide them with their IP addresses through dhcp (we are not using the dhcp server from the hypervisor anymore but the one from the local network). Bare in mind that any vm created from the template vdi has the same hostname as the template, so the hostname can not be used to identify the vms. In fact I need to modify it for a newly created vm - this is covered in the next paragraph.

Configuring the Guest OS: OpenSolaris

The new vm is uniquely identified by its mac-address and set up to acquire its IP address through dhcp, but I still need to modify its hostname and root password. I could think about modifying some OpenSolaris configuration files on the vdi from the host, but I have no way to mount the vdi file-system to reach out to these files. The only way I can finalize the OpenSolaris configuration is by connecting to it through ssh.

That brings some additional constraints on the template vdi:

1) ssh must be enabled, so when creating the template vdi run the following command from OpenSolaris

# svcadm enable ssh

2) To modify the hostname and the root password, I need to connect to OpenSolaris with a user that has root privileges. The first thing that comes to mind is to use the root account itself. But OpenSolaris increases security to the next level and it is simply impossible to connect through ssh as root because there is no more root user per se. So when creating the template vdi I also create a user account dedicated to the factory and I provide it with the root profile:

# useradd -g staff -d /export/home/vboxroot -m -s /bin/bash vboxroot
# passwd vboxroot ...
# usermod -P "Primary Administrator" vboxroot

I can now connect to the OpenSolaris guest with a privileged user. The last step consists in automating the setting of the hostname and root password. Without going into to much detail (again, the code is available at Kenai.com) I achieve this by executing some shell scripts through ssh in the OpenSolaris guest. What is of interest here is the way these scripts are made available into the OpenSolaris guest. I put the scripts in a host directory and I add this directory to the vm using the sharefolder command of the VBox:

# VBoxManage sharedfolder add vbox1 --name "shared"  --hostpath "/shared"

Then within the OpenSolaris guest I mount the shared host-directory under a local /shared directory:

 # mount -F vboxfs shared /shared

After executing the scripts I just umount /shared at the OpenSolaris level, and at the host level I remove the shared directory from the VBox vm:

# umount /shared

# VBoxManage sharedfolder remove vbox1 --name "shared"

Starting the VBox VM on a Headless Server

I am almost done. I just need to start vbox1.  The vm runs on a server with no display and is accessed from the network so I start it using the headless mode. Doing this also reduces the RAM footprint of the VM from 609 to 574MB:

# VBoxHeadless --startvm vbox1 --vrdp=off

Final Touch: Exporting the VM Desktop on the Remote Client

EZQual provides access to the vm not only through but also through a virtual desktop. In the second case, the user first connects to a Sun Virtual Desktop Infrastructure (Sun VDI) portal and can then start a graphical session, just like if she was running Solaris on her desktop.

To achieve this with OpenSolaris running in VBox, I must provide Sun VDI with a command to start the desktop session. For OpenSolaris the command is "/etc/X11/gdm/Xsession /usr/bin/gnome-session".

Note that in theory this command also works if I reach to the vm and execute with "ssh -X", but I did not test this yet. I'll put a comment if/when I found the time to try it.

In Conclusion

VirtualBox is well known as a virtualization software on the desktop. In combination with the Sun VDI, it becomes the perfect tool to virtualize the desktop on the server. Considering that VirtualBox can host many OS brands from Linux to Windows7, this combination could very well be used as a migration path by companies that are facing an OS refresh in the coming year.

Looking for more information? Leave a comment or join the project at Kenai.com.