Jumping VDI

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,

Dirk

« previous »

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 https://opends.dev.java.net/public/downloads_index.html 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 ;-)

-Dirk

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.

-Dirk

« previous | next »

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.

-Dirk

« previous | next »

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

Now we take a closer look at the core part of last months development efforts. According to the illustration below, the desktop broker (Sun VDI 3 software) is listed as one monolithic block which is installed on top of Solaris 10.

And this is done by intention. Sun VDI 3 software combines Sun Ray Software (SRSS/SRWC) and the previously known Virtual Desktop Connector (VDC). There is only one installation and configuration process, which configures the embedded Sun Ray Server Software (SRSS) exclusively for VDI usage. It handles similarly the setup of the underlying database configuration. In summary, the installation process is straightforward with barely any user interaction.

Sun VDI 3 software appears as one building block only handling third tier executed desktops. Execution platform is Solaris 10 U6 or above. Sun VDI 3 supports VMware and VirtualBox as virtualization hosts (desktop provider).

Besides the installation process we have been working on some other major components. First to mention is that we now use our own Sun VDI 3 data repository. This is a MySQL database that stores all the information that are managed by the desktop broker:

• Access information about the Desktop Providers (DP). A DP is a Virtual Center or a cluster of VirtualBox hosts and attached storages.
• AD/LDAP access information
• Pools and their embedded desktops
• Virtual machine configuration
• Association of users/groups/tokens to pools/desktops
• ...

An administrator can choose of three different node configurations, mainly driven by the way the database is used:

• Cluster DB setup:
  This is a multi-node setup with an embedded MySQL cluster. Designed for HA. Cluster configuration is handled by the setup tool. Basic database skills are required.
• Remote DB setup:
  This is also a multi-node setup. However the database (MySQL) is installed externally. Database configuration needs to be done by the administrator. Level of HA is controlled by the administrator. Advanced database skills are required.
• Evaluation setup:
  Single node installation made for evaluation purposes. Zero configuration mode. Not suitable for production.

The administration UI has been reworked to keep up with the new features. I don't dive here into the details, but really a fair set of new things have been incorporated.

Besides UI, we've put a lot of attention to the command line interface (CLI). It matches now with the admin UI feature set. It allows you e.g. to create desktop pools and other stuff directly from the CLI. This might be important if you want to combine Sun VDI 3 with some sort of automation or tools like the Identity Management suite.

That's it for today. The next article will have a closer look at the user management capabilities of Sun VDI 3.

-Dirk

« previous | next »

After introducing the general architecture I do the same exercise again, but with way more focus on the individual parts. Again, we look at the architecture diagram from right to left, with the initial focus on the client access.

Okay, the fact that Sun Ray units can connect to the Sun VDI stack is not brand new. This was also part of Sun VDI 2, if you did configure Sun Ray Server Software (SRSS) for the use with the Virtual Desktop Connector (VDC). The only difference is, that the remote protocol ALP is now built into the solution by default. Each Sun VDI 3 installation will have this ability out-of-the-box.

The really new part is, that Sun VDI 3 mimics also to be Terminal Services (RDP server) by exporting standard RDP to external RDP clients such as Windows Remote Connection or Sun Secure Global Desktop (SGD). Note, you could even redirect RDP traffic to an external Sun Ray Server.

This is done by implementing RDP redirection at the session broker level. Incoming RDP requests will be resolved by a lookup of the user's virtual desktop based on the given user ID as part of the initial RDP request. The lookup will find the user's last used desktop or his default desktop, will startup the desktop if necessary, and will redirect the RDP traffic to the virtual desktop.

How the redirection is done depends on two facts. If xVM VirtualBox is used as the hypervisor, by default the RDP traffic will be directed to the RDP server sitting on top of the VirtualBox host, that executes the user's desktop. The RDP server will render which ever desktop the user has access to, independent of the guest OS. But it is also possible to use the VM's built-in RDP server. This is useful if multimedia accelerations are important. For VMware ESX there is only the option to use the guest inbuilt RDP server. The remote access is limited to Windows XP or Windows Vista.

The approach of RDP redirection has various advantages:

1. Within a LAN environment there is no additional infrastructure needed to access a remote desktop. Each PC or even thin clients other than Sun Ray can access a virtual desktop, which could even be running a Linux or Solaris Guest OS.
2. SGD is completely decoupled from the Sun VDI architecture. This means SGD sees Sun VDI just as yet another Windows Terminal Server. This makes the configuration very simple and straightforward. And it also removes any product dependencies away.
3. RDP Redirection will work with RDP loadbalancers. This has the direct advantage of removing a single point of failure in the architecture. RDP traffic to multiple VDI nodes can be balanced.
4. RDP traffic doesn't put any load on the VDI node. It is completely handled by the third tier and makes sizing very predictable for the RDP client access case.

-Dirk

« previous | next »

When talking about Sun VDI 3, we talk about something completely new designed for better scalability and manageability, built on a complete Sun stack. Of course, customers will also be able to select VMware as their preferred virtualization layer. Below you find the architecture overview of the Sun VDI 3 product.

Generally speaking, the model hasn't changed since Sun VDI 2.0. But the components therein have. From right to left you see the three tiers involved. On the right hand side are the clients. These can be either clients that use the Sun Ray protocol ALP or, and this is new, RDP clients, such as the Windows Remote Connection or Sun Secure Global Desktop.

In the middle you find the Sun VDI building block, which is the desktop broker with embedded Sun Ray Server Software plus the Sun Ray Windows Connector. Altogether they build the session broker that connects users and their client devices with the virtualization tier running the user's desktops. The management of desktops for users incorporates access to a user directory such as Active Directory or LDAP.

And finally you find the virtualization tier on the left hand side. Either VMware Virtual Infrastructure or Sun xVM VirtualBox are the engines for the user desktops. The architecture around VMware Infrastructure access hasn't change significantly. For VirtualBox we came up with a completely different design leveraging Sun's core storage assets based on ZFS. ZFS is the interface to do the storage management meaning managing the virtual disks, while iSCSI is the access protocol to virtual disks. The visualization is handled through RDP. For the VirtualBox backend we use the inbuilt RDP server, that allows us to display any hosted desktop, including Linux or Solaris.

Further blog entries will detail the architecture and the used technologies. Differences in comparison to the Sun VDI 2.0 architecture will also be highlighted.

- Dirk

« previous | next »

We've just released the fix for the patch regression on the Sparc platform: 127559-04. If you have installed version 3 of the patch, please install version 4 on top. If you are still using an earlier version, skip version 3 on Sparc and install directly version 4.

Sorry for the inconvenience we have caused.

-Dirk

We had a partner event in Munich Monday to Wednesday. It was about exploring the new capabilities of the upcoming Sun VDI 3 release. In summary, this was a great hands-on event starting like this:

After HW preparation the real work started driven and entertained by Carsten, Thomas and Thomas and Rolf-Per:

  

And then followed with an outlook on what's coming next (audience had loads of questions for me;-)).

Take-away, there is nothing better than a hands-on for VDI to experience how it works and how the different technologies are combined to a real solution.

That was fun.    

- Dirk

PS. Next partner event in Munich is planned for April 21st - 24th. Please contact Thomas Spandoeck for further details.

Hi,

A quick interruption in my run through of Sun VDI 3. The US Army has already a lot of experience in deploying VDI in connection with Sun Ray. Read more about their 4-digit VDI deployment here.

-Dirk

Well, talking about the highlights, can be a short story or quite a long story. But this of course depends on the level of detail. My plan is to stay high-level for now and then dive into the architecture later and explain the Sun VDI 3 step by step.

So what is new with the upcoming release:

Sun VDI 3 = SRSS + SRWC + VDC

In comparison to the last release SUN VDI 3 is now a single product built out of Sun Ray Server software, the Sun Ray Windows Connector and the VDI Broker. The whole installation and configuration process is streamlined and drastically simplified.

A new hypervisor: xVM VirtualBox

The new release introduces xVM VirtualBox as an alternative hypervisor for VDI. VirtualBox allows to run Windows desktop as well as Linux or Solaris desktops, all under a VDI type deployment accessed through RDP and ALP remote protocols.

Linked Cloning: Sun VDI 3 plus Unified Storage.

Sun VDI 3 utilizes directly the capabilities of the ZFS file system. This includes linked clones and the related storage saving. Specifically the direct support of the recently released Sun Storage 7000 Unified Storage Systems makes this a very interesting combination.

Extended client support

Besides Sun Ray clients it is also possible to access virtual desktops directly through Windows RDP clients. This increases the deployment options dramatically and also simplifies deployment scenarios including Secure Global Desktop.

And of course there is the Active Directory integration, Sun Ray token management, increased scalability for the VMware Virtual Infrastructure, multiple desktops per user, an embedded MySQL cluster and many other things. I will detail this in subsequent postings.

-Dirk

« previous | next »

Hi again,

Sun VDI 3 has been driven by a few release objectives and this is not only about the feature set. It is also about integration. The top 3 objectives have been:

Integration
This actually covers a few topics. On the one hand we focussed on better integration with directory service in general and also with the integration or related topics such as token administration, which is important if you intend to use the Sun Ray as your client device. But integration covers also the aspect of making the whole installation and configuration experience much more straightforward in comparison to VDI 2.

Scalability
This covers a couple, such as how many desktops can be hosted by one group of VDI hosts. It also includes improvements around how quickly a desktop can be cloned, started and accessed by the user.

Choice
The VMware VI is broadly adopted these days and gets also more footprint in the VDI space. However, if customers want better storage utilization, access to desktops other than Windows or simply a VDI platform that is self-contained and simple to deploy, there is a need for an alternative. This need has been addressed with Sun VDI 3.

The next article will summarize the highlights of the upcoming VDI 3 release.

-Dirk

« previous | next»

Hello,

As you probably already know, we have released Sun VDI 3 EA2 last week. You can find the download on the VDI download page, please scroll to the bottom. The related documentation can be found on our Sun VDI wiki. And then there is our newly created forum, the Sun VDI forum. Please use this as another technical resource and feedback channel.

In the next couple of days I plan to circulate a series of blog entries that intend to give an technical overview on SUN VDI 3. These entries should complement the documentation on the Sun VDI wiki.

More to come soon ...

- Dirk

Hi,

We have a problem with our VDC patch release 3. The sparc binaries - 127559-03 - do not work, these are the wrong binaries. Please hold off with the patch installation on Sparc until further notice. We will deliver an update within the next days.

Sorry for the inconvenience,
Dirk