Oracle VDI gets the Geek Week treatment...finally!

It's been a while since we had a "Sun Ray = the Best Way" war on, but our most tenured readers will remember the small but vocal group of supporters that Sun Ray terminals and Sun/Oracle VDI have.

It's been a while since we had a "Sun Ray = the Best Way" war on, but our most tenured readers will remember the small but vocal group of supporters that Sun Ray terminals and Sun/Oracle VDI have. The truth is, when it was a Sun solution, it only rarely made it to the top of our minds. There was little exposure on our part, and little marketing on Sun's part. Now that Oracle is running the show, we've seen changes on both fronts, and we finally reached out to Oracle to get a demonstration (and explanation), Geek Week style.

If you don't remember Geek Week, it's a time in March/April of 2010 when we profiled a single VDI solution each day, going from bare metal at 8:00 AM all the way to provisioning desktops and user experience testing, sometimes well into the night. We had a lot of fun, but we didn't get to Oracle VDI because we let the community decide which solutions we should test. For the original Geek Week, we had VMware, Citrix, Quest, Microsoft, and Virtual Bridges.

We tried to keep the Geek Week spirit alive during our day with Oracle, and we were able to preserve some of the aspects of it. We fell a bit short on the user experience testing because our Apposite WAN emulator didn't appear to get along with the ALP protocol that Sun Ray clients use, so we just did LAN testing. The rest of the day, though, went according to plan, and really helped us to understand the Oracle platform (I think. If I get it wrong, I'm sure the fanatics will let me know in the comments, which I encourage :). We had John Renko at our offices in San Francisco driving the demo for us, answering all of our crazy questions.

With regards to the videos, we tried to be brief with them this time around, and not show the configuration screens and all. We've limited it to two videos, with the whiteboard video coming in under twenty minutes, and the user experience video coming in under ten minutes.

To the whiteboard!

Before we started, we had John explain to us exactly what we would be setting up, along with a quick walkthrough of our demo environment. The best way to get this information is to watch the video. The first part is a walkthrough, and the whiteboard explanation starts 3:40.

Basically, the Oracle VDI solution entails these components:

  • Solaris - The OS on which the rest of this stuff runs. Installation was easy, and while it may not be Windows, it shouldn't be a showstopper. Installing software is installing software.
  • VDI Core - Handles administration, pool configuration, cloning, provisioning, Sun Ray Server, brokering, and so on. It runs as a service on the Solaris box, and there would typically be many of these for redundancy/scalability. Typical environments have one VDI Core per 500 sessions. In the video, John talks a bit about density, but keep in mind those numbers are in a vacuum.
  • MySQL database - used as the data store
  • Hypervisor - They use VirtualBox, of course. They also support Hyper-V and ESX, but you lose some of the Oracle-only features like vRDP, which we'll get into later.
  • Storage - In our case this was on the lab box as a volume formatted with the ZFS filesystem. Typically this would be running on an Oracle Unified Storage Appliance. ZFS is required, so you're locked to Oracle for the time being.
  • Sun Ray thin clients - Pretty much the same zero client we've been hearing about for years. They have new form factors, all in ones, and so on, but by and large it's the same old thing.
  • Oracle Virtual Desktop Client - OVDC is the software client for use on PCs, Macs, iPads, and so on.
  • ALP Protocol - This is the remote protocol that the Oracle system uses to communicate between the VDI Core (specifically the Sun Ray Server).

The connection workflow as described in the video, works like this:

  1. The client (Sun Ray or OVDC) makes a connection to the VDI Core via the ALP protocol.
  2. The VDI Core, which is aware of all the sessions and hosts, communicates with the hypervisor.
  3. The VDI Core then communicates with via the vRDP protocol to the hypervisor in the case of VirtualBox, or waits for the machine to boot and uses MS RDP to communicate with the VMs in the case of Hyper-V or ESX.
  4. The VDI Core translates that vRDP or MS RDP data into ALP and passes it down to the client. 


vRDP runs out of band, similar to SPICE, which enables you to watch machines boot. While it's based on RDP, it's not 100% RDP compliant. Still, there are things like the out-of-band hypervisor tie in, some graphics enhancements, and some multimedia redirection that they can do with vRDP and not RDP. Of course, you can also use MS RDP to connect to VMs running on VirtualBox, but that's a more traditional solution that relies on the Remote Desktop service in the VM. Oracle recently released a XenDesktop connector, as well, which uses MS RDP between the VDI core and the XenDesktop host, but not HDX.

Preparing and provisioning desktops

We're skipping some of the more mundane sections from Geek Week, and part of that is the installation of all the components. The fact of the matter is that it's not that big of a deal, and you don't need any special knowledge to pull it off, regardless of the fact that it all runs on Solaris. The process, roughly, goes:

  1. Install Solaris
  2. Configure ZFS volume (if not already done)
  3. Install VDI Core
  4. Create/import desktops
  5. Prep desktops
  6. Provision desktops

The interesting bits there are the preparation of the desktops and the provisioning, but even those are straightforward. For our test, we had base Windows 7 VM's already created in VirtualBox, and importing them into the VDI core was no big deal. Preparing them amounts to making the normal tweaks, and running their FastPrep, which is like all the other <adjective>Prep tools out there. It prepares the machine for cloning much faster than SysPrep because it leaves out the SID replacement. It also installs the tools package, joins it to the domain, and makes it available to the VDI core for pool configurations when it's done.

Oracle VDI supports three types of pools:

  • Dynamic Pools (non-persistent, everything is wiped at logoff)
  • Growing Pool (non-persistent OS, but with linked clones so user state persists)
  • Manual Pool (persistent, personal VMs)

In terms of guest OS support, Oracle VDI supports Windows from Windows 7 back to 2000, although you can install pretty much anything in VirtualBox and have it work. I've seen demos with Windows 3.1 and DOS. Linux, Solaris, name it, it all works. It can also broker connections to Terminal Servers (RDSH). The reason for this is the integration between the ALP, the VDI Core, vRDP, and VirtualBox. There's essentially an extra layer in between, and that layer gives much more flexibility than what we're used to seeing with the more typical desktop virtualization solutions. 

This is the same diagram as above, just here so you don't have to scroll.

There are some limitations that this brings in, of course. Translating from native protocols to something else negates any enhancements built into the native protocol. In a way, this is sort of like how HTML5 clients use a gateway service to interact with the host via RDP (or whatever protocol the host uses), then re-encodes that into a text stream for the browser to decode and render. In this case we're not changing the data to text, but we are re-encoding it.

The reason for this architecture has nothing to do with VDI, though. ALP, or Appliance Link Protocol, has been around since the late 1990's as the protocol used by Sun Ray terminals. In fact, when you boot up a Sun Ray, the logon screen that you eventually see is actually being sent via ALP from the Sun Ray Server. In our case, the VDI Core was fulfilling the role of the Sun Ray Server, but Sun Rays are a thin client solution unto themselves. In fact, the Sun Ray Server has a built in RDP client so that it can connect terminals (via ALP) to RDP sessions running on Windows boxes...all without Oracle VDI or VirtualBox.

It seems to me that the VDI portion is more or less done because they can do it, and is more or less an amalgam of all the different things that Sun/Oracle could already do. They had the thin clients, they had the hypervisor, the hardware, the storage, and the base OS. The real power, apparently, is in the Sun Rays.

The devices themselves are fairly unremarkable (it's the management that really shines). They're a zero client, and I'll acknowledge that they are the first of the breed. Oddly enough, though, they still run a firmware. We know this because it was one of the first things we saw on the day Oracle came to visit. So, just because something is zero doesn't mean it doesn't have firmware, it just doesn't have any intelligence besides, "seek server...find what server says."

What warrants a deeper look someday, though, is the Sun Ray Server component, and about how to use these devices. We saw a few gee whiz features that, unfortunately, didn't make for very good video (although we tried). Being able to group terminals and provision single or multiple desktops to them as if they were one box, for instance, is pretty neat, although probably not used en masse (this is called a Multi-Headed Group, which you can read more about in the Sun Ray Server Admin Guide). I really want to like Sun Rays, and the nerd in me is behind them, although I'm not sure, based on the user experience testing, that I can completely get behind the whole ALP + translated-other-protocol thing yet.

The User Experience

Admittedly, this test is incomplete. We were only able to test the LAN scenario because we didn't trust the way our Apposite box was performing. We believe it has something to do with the way ALP and the Apposite handle Path MTU Discovery, but were unable to come up with a solution that would allow us to reliably test the WAN scenarios. This is another thing that we'll revisit when the next version of Oracle VDI comes out, perhaps on site at Oracle using their Shunra.

We did, however, get a good LAN test, and the best way to get a feel for ALP aside from using it is to watch the video.

I will say that experience looks fine most of the time, but it doesn't "feel" as nice as some of the other protocols out there. I think this is because the system handles acceleration is pretty complex with two protocols in the mix. Any acceleration native to the connection between the Sun Ray Server (or VDI Core) and the virtual desktop has to be translated or passed through to the client. This results in a lot of behind the scenes work going on, and culminates in that not-quite-normal feel on the user side.

To look at how Oracle handles acceleration, there's a few terms to know ahead of time:

  • RCA - Rapidly Changing Area - The system detects RCAs at the hypervisor with vRDP, where it can automatically transcode those areas of the screen to MJPEG.
  • Sun Ray Windows Connector - This is basically the built-in RDP Client that the Sun Ray Server uses to talk in MS RDP to Windows. The Windows Connector can identify RDP 6 bitmap acceleration and convert that to MJPEG, which is then sent to the client as an RCA.
  • MS RDP - Microsoft RDP, which we talked about earlier
  • vRDP- Oracle's RDP implementation at the hypervisor level. As discussed before, this is based on MS RDP, but is something like RDP 6.1 compliant, not RDP 7. I could be off a version there.

This is complex stuff, so I hope I get it right. You should check the comments and look for Craig Bender's notes to make sure I didn't completely screw this up :)

Multimedia and Flash Acceleration

In general, if you choose to use vRDP as your protocol for any virtual desktop (this is between the virtual desktop and the Sun Ray Server, because the client > Sun Ray Server is always ALP) and an RCA is detected by the hypervisor, this motion is converted to a Motion JPEG and is sent directly to the client (not translated by the Sun Ray Server or VDI Core). The Sun Ray client has a MJPEG decoder built into it, which makes this more efficient than trying to remote the moving areas. On the user side, it's noticeable, but not awful.

If you choose to use MS RDP on Windows XP/2003 (so, RDP v5.2), Flash is handled by a feature called SunFlash when the Flash element is accessed in IE. If it's accessed through anything else, it will simply be remoted like anything else. For VC-1 (Windows Media's codec), H.264, and MPEG2 videos played in Windows Media Player, the video data is redirected to the client where it is decoded locally. The client can be a Sun Ray or the OVDC software client.

If you choose to use MS RDP on Windows 7/2008 R2 (so, RDP 7), it leverages Microsoft's RCA-like solution (which they call "enhanced bitmap acceleration." You can read more here) to know what to accelerate. Essentially, if the Sun Ray Server sees RDP accelerating video, it grabs it, converts it to MJPEG, and sends it to the client.

I asked why the fancy codec detection didn't exist in Windows 7/2008 R2, and the answer was "When's the last time you used WMP?" Touché. They said this acceleration was written before Flash was the dominant video delivery method. Oracle is also aware that this means that the experience isn't optimal, which you can see in the video, and that while they can't say what's coming, it's safe to assume something is coming :)


The protocol transcoding, while complex and a bit awkward feeling right now, is still adequate for business use today. I'm hopeful that there will be some marked improvements in the future when it comes to acceleration because the competition is getting incredibly stiff. RemoteFX, HDX, PCoIP, EOP, etc... feel a bit further ahead of the pack when you're actually using them. As this technology segment grows, we have a lower threshold of pain when it comes to the user experience. Based on the many conversations I've had with Oracle in the past few weeks, I think they get that, so I'm optimistic about future changes and simplifications.

Admittedly, I didn't get to see it in a WAN scenario, but Oracle seems to be pretty proud of the way it performs. When we get a chance to do it, we'll be sure to add to the user experience video shot here. I really want to get a look the Sun Ray Server next time we connect, even more than the Oracle VDI pieces, I think. 

It would be interesting to see a comparison of the backend technology that makes up Oracle VDI, so if anyone reading this feels like doing that, let me know what you come up with (or have come up with, if you've done it already). I'd be curious to compare storage performance and hypervisor performance with others. Of course, I'd also love to see Benny Tritsch and Shawn Bass add this to their already amazing session called "VDI Remoting Protocols Turned Inside Out," which, if you haven't seen it, is awesome (and you can watch it right now!)

Oracle wanted to show pre-release code, which we wouldn't have been able to talk about, so we decided to show what is available today. We'll be catching up with Oracle again when they release the next version, so if you have any questions or things you'd like to see, let us know in the comments. We'll also plan on doing a more hands-on review to go into some more options.

If you want to take a look yourself, you can probably stand up a test environment in a day or so with no Solaris knowledge whatsoever. If you happen to have Windows 7 VMs in VirtualBox already, you can get it set up even faster. If you're already an Oracle customer, you can download version 3.3.2 today by visiting and downloading the appropriate patch. If you're not a customer, you can download version 3.3.0 by visiting

For more information and to follow Oracle VDI and Sun Ray solutions, follow @ORCL_Virtualize on twitter and check out their Virtualization and ThinkThin blogs. 

Dig Deeper on Virtual Desktop Thin Clients



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: