A very strange thing happened yesterday. Gabe and I were working with a customer—a university—and we ended up recommending a VDI solution instead of a Terminal Server-based solution. Afterwards I was feeling, “Wow! I can’t believe I just did that!” But I really feel it makes sense. And in fact I think it might continue to make sense more and more, and now I’m wondering if VDI can start to come out of the niche and into the mainstream?
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Let’s start at the very beginning. Gabe and I worked with this university six months ago. They were not using any server-based computing or streaming or anything like that. It was a brand new environment. They had four scenarios (or “use cases”) they wanted to enable:
- There are 1200 lab workstations throughout campus. Users need to be able to walk up to any one of them and access any of 200 applications. The users also need access to their own data and profiles.
- They want to publish a remote desktop via server-based computing to people so that they can access the “lab workstation” from their dorm rooms or off campus.
- They want to publish individual applications (as opposed to a full desktop like in Scenario 2) to users on their own computers.
- Longer term, they want people to be able to run these applications locally on non-university-controlled workstations (i.e. student laptops), and they want this to work offline.
The initial plan
For Gabe and me, these four scenarios were perfect for a combination of traditional Terminal Server-based application delivery and application streaming.
We were thinking they could use something like SoftGrid to isolate and stream all (or most) of their applications. Then they could add some Terminal Server and a third-party application publishing tool to deliver individual applications. Our initial suggestions for each scenario above were:
- Use SoftGrid to stream the applications so they run locally on each lab workstation. Install the few non-SoftGrid-compatible applications natively on the workstations.
- Use Terminal Server, along with Citrix Presentation Server or one of the cheaper alternatives, to publish server-based computing desktops. A combination of SoftGrid and local installs would be used to get the applications onto these Terminal Servers, much like the lab workstations.
- The same Terminal Servers, running Citrix or whatever, can be used to deliver seamlessly published server-based applications to desktops and laptops.
- For the applications that can be sequenced with SoftGrid, they could also be streamed to Windows clients for local offline execution.
That was our recommendation and plan six months ago. Let’s look at how that worked out.
Six months later: the reality
Looking over our plan, you can see that most of it hinges on SoftGrid, and getting as many applications sequenced as possible. After six months, the university was only able to sequence about 100 of their 200 applications. What prevented them from sequencing all of their apps? Several things, including:
- Problems with interoperability. Lots of applications require IE or Office components, and those can’t work outside of their bubble.
- Problems with interdependencies with the local OS. Many applications required Java, the .NET Framework, or IE plug-ins to be installed locally on the host machine.
- If you virtualize IE to get it to work with the plug-ins, there are problems presenting that to the users since you can’t really remove their own local IE.
- Browser plug-ins are not designed to be managed centrally, so they’re not really updateable centrally. But if they’re virtualized the plug-ins, then that means that they’re managing them, and they can’t figure out a good way to do that.
At this point, the university has sort of given up on SoftGrid. They are happy with it for the 100 applications that they’ve successfully sequenced, but they don’t feel that it can be the solution for everything. And since SoftGrid was kind of the keystone of this whole plan, they called us to discuss the strategy.
We talked about a lot of stuff. We talked about some of the tactical issues around SoftGrid sequencing and some ways that they can address some of their challenges. But we also talked about everything that they could do from an architectural standpoint. We discussed VDI, Ardence, VMware ACE, Citrix Presentation Server, Citrix Desktop Server, Provision Networks Virtual Access Suite, the upcoming VMware OnDemand streaming, and hardware pricing.
Fundamentally, the university had two requirements:
- They want a solution that can support the four usage scenarios outlined above.
- They want the solution to be easier to manage than the manual way they do everything today.
As we talked through the various options, the university really latched on to the idea of VDI. Specifically, we talked about how Provision Networks Virtual Access Suite has a feature where you can seamlessly publish applications from individual VDI VMs. We talked about how Ardence could let all of their workstations—physical lab PCs, VDI VMs, and local VMs—boot from the same disk image.
An overview of the new plan
When we were done, the university had a very different solution set to support their four use cases:
- Lab workstations: Boot from a single Ardence image. That image will contain as many apps as possible via SoftGrid, with the rest as local installs.
- Published desktops: Use a VDI solution based on VMware VI3, using Provision Networks Virtual Access Suite as the connection broker and web interface. The VMs will boot from the same disk image as the lab workstations via Ardence.
- Published applications. Use the same VDI back-end as in Scenario 2, also including Provision Networks and Ardence. Provision will allow the university to publish individual applications via the web interface in a seamless server-based computing way, except the users will connect 1-to-1 to a VM running Windows XP instead of a Terminal Server.
- Offline use: Use VMware ACE, also booting from the same image that they use to create their Ardence image.
Details of the new plan
Now that we’ve highlighted the new plan, let’s take a more in-depth look at the elements that make up each usage scenario.
Lab Workstations: Ardence
This was the biggest “no brainer” part of the design. They have 1200 workstations around campus. They have a fast network connection, and all of these PCs are more-or-less the same. Right now they’re managing them using traditional imaging techniques. Moving to Ardence makes total sense since they can have one single instant image for all 1200 workstations. That Ardence image will contain as many apps via SoftGrid as it can (all pre-cached), and the rest will be locally installed.
Published Desktops: VDI and Provision Networks
Here’s where it gets weird for me. Traditionally I would be in total support of using Terminal Server here (most likely with Citrix Presentation Server). I’ve been convinced for years that VDI just doesn’t make sense for general SBC environments. My two main problems with VDI are:
- VDI means that you have to manage a separate disk image for each user. This means patching and fixing and all sorts of headaches.
- You can fit many more sessions on a Terminal Server than you can Windows XP VMs on a VMware server.
However in this case, I don’t think these two problems existed.
With regards to managing disk images, Ardence completely solves that. And the university intends to use the exact same Ardence image for their VDI environments as they’re using for their lab PCs, so really there is no additional management.
Regarding user density on servers, I did some research and have some interesting thoughts. For years, a “standard” USD$3,000 Terminal Server has had dual processors, 4GB RAM, and two 15k mirrored drives. Even as processor speeds have increased, the number of users has remained about the same. (Of course this varies widely, but it’s generally in the 50-75 sessions per server range.)
That same server, running VMware with Windows XP VMs, could probably run about 15 VMs. This means that you would need 3 or 4 times as many servers to support the same number of users, when comparing VDI to Terminal Server.
In the past few years though, server hardware has really changed with the introduction of multi-core processors. In fact, today’s USD$3,000 server has four cores (two dual-core), 4GB RAM, and mirrored 15k drives. But what’s interesting is that server still only supports 50-75 Terminal Server sessions, even though it has twice the processing power.
The reality is that 32-bit Terminal Server just doesn’t scale that well. This is not the case with x64 Terminal Server, but that requires a lot more memory to run the same 32-bit applications.
If yesterday’s dual-core $3,000 server can run 15 VMware VDI Windows XP instances, then today’s quad-core 8GB RAM can run 30. And for $6,000, you can buy an eight-core (two quad-cores), 16GB RAM, four 2.5” 15k SAS drives server which can run 50 simultaneous Windows XM VMs.
Even though this server is twice as expensive as what you’d use to support the same number of Terminal Server sessions, there’s one huge benefit: If you use it with Ardence, then it’s running the exact same disk images as your workstations. You don’t have to worry about Terminal Server application compatibility. You don’t have to worry about x64 compatibility. You just hook up your users and go.
Published Applications: Provision Networks from VDI Windows XP Virtual Machines
Seamless published applications is Citrix’s traditional strong point. And in a scenario like this, I have traditionally always recommended Terminal Server-based solutions extended with something like Citrix Presentation Server.
But in the case of this university, if they already have one single disk image for their lab PCs and their VDI published desktops; why not use this for published applications too?
Even though you’ll need a $6000 server to support 50 users instead of a $3000 server, the fact that you don’t have to built out a whole separate architecture and test all your applications on Terminal Server will save a ton of time and probably create a quick ROI on those more expensive servers.
We recommended Provision Networks in this case because this is not something Citrix can do. Presentation Server can only publish seamless applications from Terminal Servers. But Provision Networks can hook into their VDI broker and connect users via their web interface to seamless published applications, even if those applications are coming from backend Windows XP workstations running on VMware instead of applications running on a Terminal Server.
The final aspect of this solution is the offline use case. As I’ve written previously (here and here), Ardence does not work offline yet. However, VMware has (and has had for years) an offline solution called “ACE.” ACE is basically a VMware hypervisor, a disk image, and all the configuration details needed to run it packaged together into a centrally-managed environment. ACE even handles checking in and out licenses to ensure application compliance in non-connected use cases.
Due to the network requirements, the university figures that users will have to be onsite to receive the disk image to take it offline later, although they’re also thinking about distributing the images via DVD (or even eventually with VMware’s OnDemand streaming technology.)
Like I said, this whole concept seems strange to me. It seems strange to recommend a solution with no Presentation Server and no Terminal Server. But I think this is the right thing for this university. The proposed solution lets them manage a single disk image for their entire environment. They can use flex profiles and policies to control the user environment.
Why no Citrix? (Well, other than Ardence, which is now owned by Citrix.) The problem with Citrix in the server-based computing market is that their desktop server product is a completely separate product from Presentation Server. Even when Desktop Server version 2 comes out, it’s still a separate farm, a separate database, and additional licensing on top of the $500 per user or whatever Presentation Server costs these days.
Provision comes in with their single product at something like $100 per user which supports Terminal Server-based and VDI-based SBC models in the same product, and it also provides the seamless application publishing from Windows XP VMs which is perfect in this case and not even on Citrix’s roadmap. So Provision is a no-brainer.
As for using VDI instead of Terminal Server for the published desktops and applications, this means the university gets broad application compatibility and can use the same desktop images everywhere, and it only costs them USD $6,000 per 50 concurrent users instead of $3,000. Really that’s not too bad from a capital cost standpoint when compared to the fact that they have a much easier time managing the thing and they don’t have to figure out local solutions and more servers for non TS-compatible apps.
By the way, someone pointed out the fact that this VDI solution would require a $3,750 VMware VI3 Standard Edition license for each $6000 server. This is true. Then again, you don’t need a Windows Server license for each of these since you’re not running Windows Server. That Windows Server license would be $1000 if you have up to 4GB of RAM, but $4000 for Windows Server Enterprise Edition if you go above that. (Which is common and in fact more expensive than VMware anyway.)
As a final thought, when discussing this whole thing with Gabe last night, he pointed out this is most likely the exact reason Citrix bought XenSource. Maybe Citrix realized VDI could be a bigger threat to Terminal Server-based SBC sooner than we did? Maybe Citrix realized that hardware will scale up better with individual Windows workstation VMs, and that applications will be more compatible and more portable, and that Ardence will take care of the disk image problems.
If so, then bravo Citrix! Can we just please have Presentation Server and Desktop server integrated into a single farm in a single product? Can you integrate it with Ardence and XenSource? And can you make it cost less than $1200 per CCU? If not, well, whatever. This SoftGrid/Provision/VMware/Ardence solution looks pretty cool.