Thursday Jun 11, 2009

Jumping VDI

I've decided to change the title of this blog, because it seems obvious that some people find it offensive. For those who don't know, I have a strong affinity to basketball. Played it for a long time.

And there was this movie, "White men can't jump" , which I've seen and relates quite good to my affinity. So still liking basketball, but can not jump that high any more. People who know me, know about my knee stories ...

However VDI will jump, for sure ...

Stay tuned,


Building a VDI demo


We now have a demo guide that runs you through the setup of a single box VDI demo based on VirtualBox.

Feedback is welcome,


Sunday Jun 07, 2009

VDI 3 Patching

VDI 3 just released its first patch a week ago. So far, so good. But there came up a number of questions about how the whole patch strategy for the product including the various technologies. This works in the following way:

  • Patches for VDI core will be released as patches for the VDI 3 product, in the way we just did it for the first patch.
  • Patches for included Sun Ray technology will be released as the part of the Sun Ray product. In general it is recommended to run on the latest patch level, even though it might not be important to VDI 3. The most recent patch as been announced here.
  • Changes to VirtualBox will NOT be delivered as patches. If bug fixes are required, we will release a new minor version of VirtualBox qualified for VDI 3. In consequence requires a new version a re-install of VirtualBox on the virtualization host.
  • Changes to the storage platform. These are not driven or controlled by the VDI team. Therefore the VDI team needs to qualify a new firmware for the Unified Storage systems as well as updates to OpenSolaris. The VDI team will announce which future versions are supported or by when. So, be a bit careful in this area.



VDI 3 @ JavaOne - Summary

Here is a short summary of our VDI implementation for the JavaOne conference. How we did it, has been described on our wiki. During the show we've been gathering data, here are some highlights:

  • Setting up the VDI environment took about 2 days. This is the software install on all tiers, the network setup, storage setup and the cloning of roughly 10000 desktop images. Additional images would have been created on demand. The work has been done by 2 engineers of the VDI team.
  • Roughly 6000 desktops have actually been used by the participants during the whole week.
  • The majority of the users sticked to just one desktop.
  • Half of the users went for Windows 7, the other half for the Unixes OpenSolaris and Ubuntu.
  • The whole storage consumption for 6000 desktops in use was 2 TB. Remember each single desktop image had a size of 10 GB. (Windows 7 even more). Without the merits of ZFS this would have been 60TB.

FatBloke took some nice pictures showing people using VDI 3.


And by the way, it is a very new experience seeing people working on the same thin device all using different desktop OSs.


And this is the user experience that has been offered to the users:

  1. Choose your desktop
  2. Connecting to the desktop
  3. Working with your personal Windows 7 desktop

That's it around the show. Interesting experience for the VDI team and very good proof of our solution.


Monday Jun 01, 2009

VDI 3 @ JavaOne

Today I'm at the Community/JavaOne conference in San Francisco, Moscone Center.  A couple of thousand participants will be at the show. And as usual they get terminals to access their session schedule or browse the internet. The cool thing from a VDI perspective is, that this is all powered by Sun VDI.


There is an article on how we set it up: I think this is very impressive, running about 20000 virtual desktops with such a small equipment.


Special thanks to the tradeshow team, Vernon and Kevin, and to Thomas and Chris, to get this setup going in such a short time.

- Dirk

Friday May 29, 2009

Sun VDI 3 - Patch 1 Released


I'm sure this will be of interest for various people. We have just released a first patch for VDI 3. It includes a number of important enhancements, such as:

  • S10 U7 support
    This is quite significant as it allows you to build a demo/POC on a single box including VirtualBox and Storage. Some postings on how this can be done will follow.
  • VMware vSphere 4 support:
    VDI 3 runs against vCenter 4
  • Support of the latest Unified Storage firmware
  • Performance improvements in the UI
  • And many other things targeted for scalability and robustness

The x86 version is 141482-01.

The Sparc version is 141481-01.

Just one note: The documentation will reflect the changes sometime next week. So stay tuned for the update.

- Dirk

Thursday May 28, 2009

A new storage for VDI, the 7310 Unified Storage System

Sun has just announced a new storage system, the 7310. The big thing about it is: It provides basically the same functionality as the 7410 including High Availability through clustering, but at a lower entry price. This system is ideal to start small and grow later for dedicated VDI deployments.

It starts with 6 TB and can grow to 96TB in up to four storage extensions. It is perfectly made for hosting VM images through NFS or iSCSI with a big read/write caches in the middle. But of course it can also be used as a file server in a Windows environment. As said, ideal for VDI.


Friday Apr 24, 2009

Sun VDI 3 - Sizing


A lot of people have raised pretty quickly the question of how the sizing looks for VDI 3. The engineering team hasn't been able to complete this information by the release date, end of March. However, in the meantime we have been busy getting the information together. The goal of this sizing guide was to get statements around question: 'How much gear do I need in order to serve a 1000 desktops?'

We've put the initial information on the VDI Wiki, summarize under the Deployment Guide.

Have fun,


Wednesday Mar 25, 2009

Sun VDI 3 - How it all came together

There are tons of news around Sun VDI 3 since yesterday's launch. This is great. I typically tend to focus on hard technical facts in my blog, but I guess there is so much material out there that you have to digest, that I can shift my focus a bit.

VDI 3 was really hard work that started last year around the VDI 2 launch. At that time, the concept wasn't really that clear. However, in early spring 2008 we all of a sudden had couple of new technologies in the Sun portfolio, that were and are really interesting from a VDI perspective. The first one to mention is VirtualBox, that joined the Sun family in February 2008. Originally seen as a pure desktop hypervisor, VirtualBox had already many features being very interesting for VDI at that time. This is on the one hand the built-in RDP server, allowing to render every VirtualBox supported virtual machine to a thin client such as Sun Ray or to nearly any RDP client.

In addition VirtualBox had already a ready-to-go iSCSI initiator built-in. This storage protocol was a perfect start for the mission of developing a solution that reduces storages costs dramatically and being efficient and fast at the same time. Storage costs being the number one issue, we heard from our customers. This combined with the ZFS filesystem on top of OpenSolaris has been an excellent teaming. ZFS providing the management including snapshots and sparse cloning combined with iSCSI access through VirtualBox was a pretty impressive combination. And this all supported with the latest OpenSolaris 2008.11 release.

But another coincidence helped to even accelerate this combination. Using OpenSolaris 2008.11 as a storage backend is great, but the new storage appliances, the Sun Unified Storage 7000 systems, is even better. These systems provide a far better manageability and high availability story with an interesting price tag. From the storage perspective, things really worked out in the right direction. Excellent timing.

I've started talking about acquisitions and technologies. The next one to mention is MySQL. This acquisition happened also at the beginning of 2008. And again a perfect timing. Why? Well, each VDI solution in the market relies on at least one database or even more. The database is used to store the relationships between users and VMs, in case of vCenter they store all the configuration for the VMs and the hypervisors. So a pretty central technology that must be fast, reliable, scalable, high available ... The bigger your deployment gets, the more important is the underlying database. And for a supported solution VDI customers need to buy or own database licenses for the various databases in use. Which is kind of a hidden cost factor.

With Sun owning now a proven, widely used database product, MySQL, we had the perfect engine for VDI. We have chosen the MySQL cluster as the built-in database engine, which is fast, reliable, scalable and designed for high-availability. All built into the Sun VDI stack at no extra costs including support. That has been a big advantage and again a perfect timing!

So looking at the assets above the job to build a new VDI product might appear very easy and straightforward: 'The VDI engineering just had to assemble a solution out of existing, cool and strong technologies, with a lot of unique characteristics.' Well, not really. This was actually very hard work to build a real solution out of core technologies, requiring a lot of time, spare time, motivation and of course a lot of talent.

We started this effort from the engineering side in this Brazilian restaurant in Hamburg together with the VirtualBox team. And yesterday we closed the circle by celebrating the launch at the same restaurant. It was bit bizarre though yesterday, as the restaurant owners had a film team around to create a new advertisement video for their restaurant. Hard economic times require these sort of things, I guess. When this video appears online, you might have a chance to see the Hamburg part of the VDI engineering team. The Dublin VDI team had been at the same time following more Irish traditions, meaning having a pint in the pub after a good dinner.

- Dirk   

Thursday Mar 19, 2009

Sun Rays in Hospitals

Mobility is a very important criteria for an IT solution in a hospital. That Sun Rays are a very good choice for hospitals demonstrates this video published by one of our longtime partners. It gives you a very good impression of a real life use case.

This video is in German, but even if you don't speak this nice language, the illustration of the use case is still quite impressive.


Wednesday Feb 11, 2009

Sun VDI 3 -What is it about - VMware Virtual Infrastructure

This is the last article of the 'What is about series'. It covers how VDI 3 connects against VMware VI3. Bottomline is we connect in the same way as we did with VDI 2. So, the diagram is not much different compared to the previous release.


However, under the hood we've changed quite a lot with the main goal of improving the performance and the scalability of the whole system. Here's an extract of the changes:

  • We've replaced the agent on the vCenter with a pure remote communication. This simplifies deployment and the update process.
  • We don't move any VMs or folders around. All information is kept in our datastore. This has a lot of positive performance implications.
  • Multiple vCenter server can be connected. No problem with the 2000 VM limitation, except that you need multiple instances of vC, of course.
  • No pool limitations anymore. No static folder anymore. Much more flexibility with the new pooling concept.
  • No identifier-mapping between VM and user. This relationship is stored in our datastore and just depends on internal object IDs. Implication is, that you can rename machines as you like without breaking an assignment.
  • Better and fine-grained resource control. For each pool you can define which computing resources and storage you want to use.

That's roughly it. Next articles will probably touch a bit more the system setup.

Cheers for now,


« previous »

Why does Sun VDI 3 mandate a user directory?

Hi folks,

This is a very common question we get these days for the VDI 3. Simple answer to that is, desktops are made for users. And the user data is kept in 99% of the deployments in user directories. So that's the simple reason.

Next question is then:

I want to do a Proof-of-Concept. Where should I get a user directory quickly?

There is a really simple answer to it. Use OpenDS. The open source LDAP server, derived from Sun's Directory server. All built in java. There has been just a new release been done beginning of this month. Perfect for a POC. There are just a few steps to get the install done:

  1. Go to the download page and launch the quickstep install.
    This launches a java webstart installation, very simple and straightforward
  2. Provide the install path
  3. Provide the Root User password
  4. Select standalone server
  5. Specify the domain
  6. Import automatically generated sample data
  7. Done.

After a few minutes the install is complete. Any administration task can be done through the console <install path>/OpenDS/bin/control-panel. Thereafter you simply point a VDI 3 instance to the server, where OpenDS is running with (LDAP, anonymous access) and you are done for the POC. At least in regard to the User Directory ;-)


Monday Feb 09, 2009

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 »

Sun VDI 3 - What is it about - xVM VirtualBox

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.


« previous | next »

Sun VDI 3 - What is it about - Directory Integration

Name a customer who is not using a directory service. There are barely any. In the Sun VDI 2 world there hasn't really been an integration with the directory world. Simple identifier have been used, that happen to match with an user ID in a directory. Things changed with Sun VDI 3:

A directory is now a key element of the Sun VDI story. Basically, without a directory binding it is not possible to assign a user to a desktop. And here we focus primarily on Active Directory being dominant in the Windows world. In addition we support Sun's LDAP directory. Other directories might need some manual intervention and are not covered out of the box or we simply don't know at this point.


Main purpose for the binding to the directory is to identify the entities that should get access to a desktop in one way or the other. Entities are users and user groups. Sun VDI 3 has a predefined understanding of what a user and a user group is. This understanding is identical to the one implemented in Secure Global Desktop (SGD). Besides the fixed definition of a user or a user group we have a custom query mechanism for LDAP similar to the one found in SGD.

Next to entities from the directory we have also included tokens into the list of managed objects. Tokens are the IDs of a smartcard or the ID of a Sun Ray Desktop Unit (DTU). You may ask, why is this included into a VDI solution. Sun Ray Server Software provides this feature as well.

Quick answer to that question is, Sun VDI 3 targets to be a self-contained solution that can be used by various clients, where one - a prominent one, of course - is the Sun Ray. Managing in this context the relationship between a smartcard, a user and a desktop is a core functionality that should be in one place and not spread around various places.

Effectively this gives an administrator a number of choices:

  • Assignment of a user to an individual desktop
  • Assignment of a user to a pool
  • Assignment of a user group or custom query to a desktop or pool
  • Assignment of a token to a user - so when you stick in your card, the desktop(s) of a user are presented to the user.
  • Assignment of a token to a desktop or a pool - this allows to have different smartcards for a desktop or to assign a DTU to a desktop, which is then more or less acting like a real PC.
Another nice thing about having this all in one place is the fact, that it should be fairly easy to combine an Identity Management solution with management of virtual desktops. You can easily imagine that on-boarding of people can imply the assignment of a smartcard to a user and a user to a desktop. The reverse applies to the off-boarding. And in-between identity management can provide all means of user self service, like requesting a restart of a stuck VM, asking for an additional VM etc ... This in combination with the management of application access is a very strong value proposition. If you have more interest on how an Identity management integration looks like, please contact Paul Walker from the Sun Identity Management group.
Well, that's it in on the directory integration. At least on the surface ;-) Give it a try with the current public Early Access Program and let me know what you think about.
Cheers, Dirk
« previous | next »

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