Sun VDI 3 - What is it about - Open Storage Access

Centralized storage is a key component in the VDI world, if not the key component. If you think of the virtualization host being the CPU and memory for executing a virtual desktop, the centralized storage is the hard disk. Very simple metaphor. However, simple metaphor, but really tough requirements implied:

  • A PC hard disk is cheap:
    Today's PCs come with a TB of space on the hard-disk. And this costs around a hundred euros. If you compare this with a TB in a SAN or a NAS, the price is very different. Fortunately a TB is typically not needed for the average enterprise PC.
  • A PC hard disk serves a single user:
    A PC is usually a single user environment, meaning a user is running a single OS and a number of applications. Disk I/O is not an issue. If you have a central storage serving hundreds of virtual disks, disk I/O becomes a major concern. Just imagine hundred of users running each their own virtual disk with random read and write access. This can easily cause a major crisis for the central storage. And here factors like I/O, throughput, locking semantics of filesystems have to be taken into account. Requirements, very, very different compared to what's needed for a single PC's hard disk.
  • A PC hard disk can crash:
    Same applies to a virtual hard-disk running on a central storage. And this can be caused through a HW failure on a central storage, a guest OS failure (blue screen of death), a network problem and so on. In other words, redundancy is key in the virtual world, complexity is higher.

So what have we done for Sun VDI 3 to address the storage requirements:


In the illustration above you see to connections to the storage: ZFS and iSCSI. These are the core elements of the concept:

ZFS - The filesystem is leveraged as it provides the essential filesystem capabilities required for Sun VDI 3:

  • Snapshots to keep a safe state of a virtual machine disk. A lot of virtualization solutions today rebuild these capabilities on top, as part of the virtualization layer. ZFS provides this in-built fully transparent to the virtualization layer.
  • Cloning to replicate virtual machine disks. A very typical requirement in the VDI world is, that specific user groups should have the same qualified desktop. Cloning is one answer. Cloning with ZFS is even a better answer as it replicates virtual disks instantly without consuming any disk space - well just a few kilobytes. Deploying hundreds of desktops becomes a task that can be done in minutes or a few hours rather than a couple of days or weeks. A tremendous advantage.

iSCSI - The protocol for remote block I/O:

  • VirtualBox has an inbuilt iSCSI implementation that acts as iSCSI initiator. Actually it does way more. It treats an connected iSCSI target as if it was a hard disk. That means all block I/O is directly communicated between the VirtualBox and the central storage. No translation, just raw traffic for the best possible performance.
  • All information about a virtual machine and a virtual disk are stored in the Sun VDI 3 datastore. This implies that the VirtualBox host is fully stateless. Only at the moment when a VM is started, VirtualBox is informed about the VM configuration and where the virtual disk resides.

The illustration above details the core concepts. As stated the VirtualBox host is stateless. The Sun VDI 3 broker has all the knowledge about the location and structure of the storage. The administrator configures for a group of VirtualBox hosts (VirtualBox Desktop Provider) a number of so called storage pools (ZFS), or in the language of the Sun Storage 7000 systems storage projects. Each pool can host many virtual disks. Each virtual disk is a volume (ZFS) or share (Sun Storage 7000 systems ). That's it about the terminology.

It becomes interesting if you look at how we envision to create the virtual disks. So we assume that most of the hosted desktops are very similar. Typically they are based on one Golden Image created and maintained by the administrator. In Sun VDI 3 we call those Golden Images templates. The administrator will import a Golden Image into Sun VDI 3 becoming a template. Idea is now to replicate the template as often as needed for all users. But instead of creating full copies for each desktop instance, we use the advantages of ZFS. Sun VDI 3 will create a snapshot of the template. And from this snapshot each new virtual disk is a clone, consuming initially almost zero physical storage. Only when the user actually accesses this volume, the differences will be stored into the volume and the volume grows.

Let's pause here for a second. Implications of this approach are such as creating a new clone is done within milliseconds, making the whole deployment much faster. It also allows the administrator to overcommit a storage pool, creating many more disk instances than physically possible.

After the virtual disks are created, the virtual desktops (virtual disk plus VM configuration) can be assigned to a user. Now, when the user starts accessing his virtual desktop, the following happens. First Sun VDI 3 selects the VirtualBox host which should execute the virtual desktop. Afterwards Sun VDI 3 sends over the VM configuration parameters as well as the location of the virtual disk to the VirtualBox host. The location is specified as an iSCSI target being served on a Open Storage server or Open Storage cluster. Thereafter VirtualBox boots directly the VM from the iSCSI target. Updates and write operations are sent to the iSCSI target, which is a sparse image of the original disk. Depending on the bandwidth and the caching capabilities of the storage host, this will be a very fast booting of the virtual desktop.

The 7000 series (Amber Road) provides the ideal components for this kind of deployment. On top of ZFS it offers a very smart management interface that makes storage administration very simple. And underneath it offers capabilities such as clustering or caching that help to build a very reliable, fast and cost effective solution. Besides Amber Road Sun VDI 3 lists OS2008.11 as a supported storage platform.

With this approach storage becomes way cheaper and affordable. And besides price it offers advantages in terms of desktop deployment time and capacity planning. This is more than just cool. It's a very different and efficient approach to VDI.


« previous | next »


Great! thanks for all of these informations about SUN VDI.

I'm happy to see that now we can "officially" choose between vmware and virtualbox.

I have one question about this.
I'd like to build a VDI for 30 clients.
I already have SRSS (2 servers in a FOG for about 120 clients)
30 of these 120 clients have to access to their virtual machines.

I dont find any infos for constructing and dimensionning well the server(s) ? (how much memory per machine, processor, disque space).

Do you have some tips?
Thanks in advance

Posted by Johan THOMAS on February 11, 2009 at 01:47 AM CET #

just forget to say that i'm trying to build the VDI with virtualbox and this is with it that i'd like to have some tips for the server.

Posted by Johan THOMAS on February 11, 2009 at 01:55 AM CET #

Hi Johan,
For VDI 3 we don't have the official material yet. By the end of the quarter we should have some more decent material than just the few house numbers out there.


Posted by guest on February 11, 2009 at 04:45 AM CET #

So how much of this functionality does one lose if they're using ESX for the VMs? All of it, I presume. Any idea how long a VM takes to spin up on ESX as opposed to VirtualBox using this solution?

Also, are you able to roll VMs back once the user logs out? We have many workstations where we wouldn't actually want changes to persist if that were possible.



Posted by Ceri Davies on February 11, 2009 at 01:27 PM CET #

Also, how does the VDI Core actually communicate with the OS2008.11 host to tell it to take a snapshot?

Posted by Ceri Davies on February 11, 2009 at 02:10 PM CET #

Hi Ceri,

With ESX it is not possible to get the advantages of ZFS. There is a conceptual difference.

With ZFS we treat a virtual disk as a LUN or share in terms of Amber Road. This LUN can be snapshotted and cloned in a very simple manner.

With ESX and VMFS it behaves different. A LUN is used to host many VMs. This means from ZFS point of view you can snapshot of course the LUN and clone it, but then you have just the same VMs as before, in term of configuration, MAC address .... So this doesn't work.

To your second point, yes you get the functionality of resetting a VM once the user logs off. We call this recycling and you can choose between deleting a clone and create a new clone. Or revert to the previous state of the VM before it has been used.


Posted by Dirk Grobler on February 12, 2009 at 01:34 AM CET #


And to your question:
'Also, how does the VDI Core actually communicate with the OS2008.11 host to tell it to take a snapshot?'

This is a very simple approach. The broker uses SSH to connect to OpenSolaris. Inside opensolaris the broker executes native ZFS commands to list ZFS pools, create new volumes, snapshot, clone ...

Not too complicated. And we have the same approach with Amber Road, except that we use the CLI of Amber Road, instead of native ZFS calls.


Posted by Dirk Grobler on February 12, 2009 at 01:40 AM CET #


Do you have a strategy for patch management? We love the idea of using ZFS and Amber Road.


Posted by Tom Locklin on February 12, 2009 at 06:01 AM CET #

Can VirtualBox make use of ZFS filesystem located directly on the box it's running on? (as opposed to using a separate OS2008.11 or AmberRoad box)

Posted by hxy on February 13, 2009 at 09:53 AM CET #


For the moment not. S10 U6 has ZFS, of course. But the iSCSI implementation is a bit flaky.
Once S10U7 is out, it will work on the same box.


Posted by Dirk Grobler on February 13, 2009 at 02:38 PM CET #


For patch management there are a few options:
You do the traditional patch management as you do it with your PCs today.

You use pooling. At the moment when you assign a new template to a pool, all VMs based on a old template will be removed if not used.

c. A mix of both

- Dirk

Posted by Dirk Grobler on February 13, 2009 at 02:43 PM CET #

We're just starting to look for VDI solutions for a small group of users, and our Sun sales rep could not get any info on VDI3.
Is there an estimated release date for it?

Posted by hxy on February 17, 2009 at 02:14 AM CET #

Hi hxy,

We target end of March for the final release.


Posted by Dirk Grobler on February 17, 2009 at 07:18 AM CET #

Post a Comment:
  • HTML Syntax: NOT allowed

This one is about VDI, Sun Ray, SGD and sports, in particular basketball, and any combination of it. And of course other interesting stuff.


« July 2016