Sunday Jun 07, 2009

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.


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.


Saturday Sep 13, 2008

xVm launch

We had a launch of the new products of xVM, including Sun VDI. Steve Wilson and Rich Green did a real good job in showing how VDI works and the benefits of it in the xVM webcast.  Remember the demo was driven in California, but it was running on my small demo server in Hamburg Germany.

And you can get this stuff now. Sold under the Sun VDI 2.0 license.

- Dirk 

Wednesday Feb 27, 2008

Sun Microsystems and VMware Announce OEM Agreement ...

Did you see this announcement? Finally we have a proper relationship with VMware.  


Friday Feb 22, 2008

Understanding the Virtual Desktop Lifecycle - Part 2

Today I'd like to expand on the idea of automatic deployment of a virtual desktop as introduced in the previous article. The good thing about a virtual desktop or a virtual machine in general is the fact, that the virtual machine is just comprised just by a bunch files, that can be copied relatively simple. And this is the basis for the automated deployment: Copying files and making them unique in the network. This is of course a bit too simplistic, so let's see how the process really works. First of all look at some ingredients of the virtual desktop lifecycle:


A template is a virtual machine that is configured in a way, that it can be replicated or in virtualization words, cloned. A template is nothing else than a golden image or golden master, terms that are used in the traditional PC deployment. This template needs to contain all the applications and settings you want your users to use. The only specific pieces to desktop virtualization are, that tools like the VMware tools need to be installed on top. And typically a set of tools for the connection broker as well. For the Sun Virtual Desktop Connector (VDC) these are the VDC tools. And then you need to prepare the virtual desktop template, that it can serve the Remote Desktop Protocol (RDP). This includes enabling the terminal services, opening the firewall for RDP and finally making sure that users have permissions to connect remotely to instances cloned from the template.

System Preparation (sysprep)

System preparation is the task you have to initiate after a template has been cloned. Main purpose is to create a unique instance of Windows that can be identified in the network. This includes the name of the instance, the registration in the Windows domain, network parameters as well as applying licenses and the activation of the Windows instance. And a whole bunch of other things. You can find lot's of articles on sysprep. Here is one that provides a bit more detail on what sysprep is, specific to Windows Vista though. You find similar documents on Windows XP as well.

Roaming Profiles

Creating a virtual desktop automatically and giving users access to it somewhat implies that the administrator does not necessarily know, which instance of the virtual desktop is assigned to a certain users. In other words a user will get access to a desktop in the data center, that is not personalized for him at all. But that's not what users usually expect. They need to be familiar with their desktop. The Windows way of addressing such a requirement is called 'Roaming Profiles'. Roaming Profiles is a mechanism to store user preferences for the desktop and applications as well as user documents in a network folder. At the moment a user logs into a desktop, his roaming profile residing on the network is copied to the local machine, in our case the virtual desktop. When the user logs out, his profile is written back to the network location. This is a common mechanism, which has the drawback of slowing down logins and logouts when a lot of data need to be copied or the network storage access is slow. 'Folder Redirection' is another mechanism to improve the situation, by redirecting some folders, like the 'My Documents' to network locations. This mechanism avoids that data is copied back and forth between the virtual desktop and the network folder. The users data is simply fetched from the network location, when needed. This reduces typically the login time. There are plenty of articles out explaining this mechanisms, here is one for more detail.      

The Lifecycle (Produce - Prepare - Recycle - Retire)

After talking about the prerequisites let's have a look on how the virtual desktop lifecycle works, in general. Fundamental to the idea is the desire to create a number of virtual desktops that are configured in the same way. These desktops should provide desktop sessions to users, that are completely isolated from other user desktop sessions. Which is the big difference if you compare this concept with Windows Terminal Services (WTS), where desktop sessions are not isolated from each other.

The container for these virtual desktops is called a pool. The pool is populated through a single virtual desktop template. The figure below illustrates the whole process:



The process begins with the cloning of new virtual desktops based on the template that has previously been created by the administrator.  Cloning means that a copy of the whole virtual desktop is created which includes the virtual disk as well. Usually the clone consumes the same amount of disk storage as the template. Note: There are already storage systems out with a copy-on-write technology. Only differences are stored, which makes the cloning process instantaneous.

After the cloning process is complete, the instance of the virtual desktop is 'syspreped', meaning it is getting its own network identity and other settings different from the template. This production task of cloning and 'syspreping' can definitely take several minutes, depending on the size of the template, performance of the network and the storage as well due to the time it takes to prepare a system, which can involve several system reboots. Once the system preparation is complete, the virtual desktop is made available to users. This whole production process is also summarized under the term virtual desktop factory.


When a user connects through a Sun Ray or a web browser and there is no Windows RDP existing for that user, the connection broker is contacted. If the connection broker finds out, that a virtual desktop has already been reserved for that user, a new RDP connection is opened. If no reservation has been done or a previous reservation timed out, a new available virtual desktop is requested from the pool.

But before the requested virtual desktop can be handed out to the user, the connection broker needs to ensure that the virtual desktop is fully accessible. This includes starting the virtual desktop, e.g. if it is suspended or stopped for resource optimization purposes. It also needs to ensure that all the services of the virtual desktop are up and running, especially the terminal services need to be up and running on the virtual desktop. Once all checks have been successfully passed, the virtual desktop is handed over to the user. Thereafter the user can login to the desktop, his roaming profile might be synchronized and finally the user can begin his work.


Typically, as long as the user is actively using his virtual desktop, he owns it. But the administrator has the possibility to define, what should happen, when a user hasn't used his reserved virtual desktop for a defined period of time. This might be triggered through a logout of the desktop or just through leaving the virtual desktop idle with a subsequent standby of the virtual desktop. Both events can start a timer, which possibly triggers a recycle or a retire action.

Recycling means that the virtual desktop is returned to the list of available virtual desktops. And here the administrator can choose between a cleanup of the virtual desktop or just a handover as is to the list of available desktops. A cleanup is desirable if idle desktops are returned, where the previous user might still be logged in. The cleanup can actually be implemented through snapshot and revert technology. This happens in a way that a snapshot is taken of virtual desktops before they leave the factory. Thereafter a revert is initiated as part of the recycling process, which cleans up all modifications done by the previous user.

In other situations it might be sufficient to leave the desktop as is and return it immediately to the list of available virtual desktops. This is useful when the Windows desktop is configured for a kiosk mode operation and/or when the recycle process is only triggered by a logout of the user. In both cases there is no session state to revert, but the virtual desktop might still contain some data of the previous user that is neglectable.


The remaining action as part of the virtual desktop lifecycle is the action to retire a desktop. And there are two scenarios that can trigger the retirement of a desktop. The first one is that the administrator has configured virtual desktops for one time usage. After the first usage virtual desktops are not recycled but immediately destroyed. This is very similar compared to recycling with snapshots. However there are performance consideration that make the immediate retirement desirable. The VMware platform for example does not allow life migration of VMs with snapshots. It also takes noticeably longer to startup or resume a VM based on a snapshot.  Another reason might be that the template of the pool is refreshed quite often and there is the desire to present always up-to-date copies of the template to the users.

Another reason to retire a virtual desktop is that instances simply expire after a certain amount of time. This mechanism can be used again when templates are regularly updated. In this case users also need to work with clones of the latest version of the template.

I'd like to wrap up at this point. You have hopefully now a better picture of how the virtual desktop lifecycle works, in general. In my next article I will focus on how this is implemented with the Sun Virtual Desktop Connector 1.0. And well, let me know if there's something unclear or you have suggestions to improve. Your feedback is welcome.


Wednesday Feb 13, 2008

Meet us at VMworld Europe 2008

VMworld Europe 2008 is coming up and Sun has a booth presenting Sun VDI. If you are around and are interested in some more detailed information on how Sun VDI works in general and the Sun VDI Connector specifically, ask me, I'll be there too.

Monday Feb 11, 2008

Understanding the Virtual Desktop Lifecycle - Part 1

Today I start a serious of blog entries describing one of the key drivers for a Virtual Desktop Infrastructure (VDI), the ability to automate the dynamic provisioning of desktops. The concept and ideas behind are explained using the semantics of the Sun Virtual Desktop Connector 1.0.[Read More]

Friday Jan 18, 2008

Grenoble was nice

I have been for 2 days in Grenoble this week, participating at the Identity/Desktop event. That was really good. Lot of interested folks around, a bit more than a hundred I guess. And there was a considerable interest in VDI, also not too bad as this was my topic to cover. I got a lot of tough questions around the architecture, what is possible and what not. And finally people are pretty eager to see the final release of the Virtual Desktop Connector. I promise, we are working hard on it.  

Many thanks to Dominique for organizing this great event.


Monday Dec 10, 2007

Hi there

What has this blog to do with Sun? Well, I work for Sun. That's already a good start. And then I like stereotypes. 'White men can't jump' is a good one. So I like basketball, a lot, I also like sports in general. Both are indeed a big problem when you work in engineering like I do.

Hardly anybody cares about sports. Just an example: Last year we had the soccer (football) ((fussball)) world championships in Germany. Part of the Sun Ray engineering (my group) is located in Hamburg, so am I. Guess what, people in my team didn't know when the German team had been playing, haven't been interested in watching a single match and just loved to stay in front of their Sun Ray and continue coding or do any other useful stuff that is not sport.

If you like sports, you might understand how difficult it is coming into the office after watching a great match the previous night, and you want to share your opinion with your colleagues and ... nothing.

Only comments like, "Oh I missed this one" or "Really, no I had to fix this interesting bug" or just nothing, not even feeling sorry for you.

So maybe this blog could also be titled as "Engineers Hate Sports". As said, I like stereotypes. Bringing this a bit closer to my work, another stereotype is "Sun can't do software". I like this one, because I'm in software and it keeps me motivated each and everyday, to prove it wrong.

What you can expect from me, a bit on my work around Desktop Virtualization, around Sun Ray, Secure Global Desktop, a bit on sports, and stereotypes. And just on a side note, the last 2 MVPs in the NBA are white men. So there is hope even if you can not jump.


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


« December 2016