Sun VDI 3 - What is it about - xVM VirtualBox
By MrDGrobler on Feb 09, 2009
In my next couple of articles around Sun VDI 3 I want to focus on the back-ends, so VirtualBox including its storage access and finally on the additional features for the VMware backend. Looking first at VirtualBox we see a clean and simple architecture:
The VirtualBox host is completely stateless. All state is captured and stored by the Sun VDI 3 Broker . This includes the access information to the VirtualBox hosts, the storage hosts, the configuration of the virtual desktops, the access information to the virtual disks ....
VirtualBox hosts are managed in clusters. A cluster spreads the load for a given number of virtual desktops between the embedded VirtualBox hosts. The Sun VDI 3 Broker or multiple instances thereof take care of the load-balancing, which includes starting the virtual desktops on the most appropriate host as well as creating the next virtual desktop on the storage with the best capacity.
When you start the system the first time, there are no virtual desktops, of course. The administrator prepares a virtual machine with the well known VirtualBox user interface on his laptop e.g. Thereafter he imports the virtual machine through the administration UI. This virtual machine can then be used as a template to clone various instances thereof. And as we are using ZFS as the storage management interface, cloning will be more or less instantaneously. But more on this aspect in the next article.
VirtualBox supports a ton of different desktops as a guest. We can't do that for VDI as the test matrix would simply be way too big. Initially we focus on Windows (Vista, XP and W2K), a Linux flavor (Ubuntu 8.10) and OpenSolaris 2008.11. More details around the guest support for EA2 in the Release Notes. Note that the list might be extended for the final release.
As mentioned in previous articles we use the RDP server of VirtualBox by default to do the remote access to the desktop. This has couple of benefits such as the more PC like experience for the end user or that you can access even non-Windows guests with an external RDP client. But in some cases you might want to use the Windows RDP server that is built into Windows XP or Vista. For example if you want to use the multimedia enhancements specifically developed for Sun Ray. This is possible, it just requires a different networking (bridge instead of NAT) and a setting to use the Windows internal RDP server. Of course you can't use this configuration with W2K, Linux or OpenSolaris.
The same limitation applies to the Windows in-built system preparation tooling (sysprep). This is highly useful when you are cloning desktops in order to create for each instance (clone) a unique identity. For OpenSolaris or Linux there is no such capability. In consequence there will be restrictions in the automation process, as clones might require a manual post configuration step.
That's it for now. In the next article I'll take a closer look at the storage side of things.