I’ve recently been involved in a deeper look at the world of virtual desktops (aka VDI) and what options suit different users groups. There are a few different ways to look at the whole desktop virtualisation and most of them depend on what software your business uses and how your users access it.
With the different types of virtualisation around these days it can be a little confusing about what fits where and how they interact. I’ll run through a quick overview of them here and the products that I’ve been testing with. (Be warned this is a bit of a ramble.)
There’s a few different ways to get your apps into whatever virtual or real desktops your business uses. The apps are key though, they’re what your users need to view and manipulate the business information. Simplifying access to the information is the important thing.
- Install the apps into the OS like you normally do for a typical client on normal HW. This lets your support teams stick with their current processes but things get hard when different apps don’t play nicely together. Licensing also becomes an issue for some apps when you deploy a virtual desktop to 500 people even though only half of them use the software. Most vendors will want you to pay for 500 licenses.
- Use a server based remote app virtualisation like Citrix XenApp. The software then runs on a remote server and allows many more users to access it at once. Users just see their own apps even though may of them are connecting to the same server.
You can still have other apps installed on that server and deployed in the same way, but sometimes they still won’t play nicely on the server. You do now have more control over who can access those apps and they work really well over slow connections as only screen draws, sound and interactions go across the network.
- Separate the apps from the OS by using software virtualisation. In most cases this means that the app is installed into a virtual “container” that keeps all the files and settings (including registry settings) separated from other apps and the OS. Products like Microsoft App-V and Symantec Workstation Virtualization fit into this option. Be careful here and keep it simple, layers upon layers of virtual apps become fragile.
- Published Desktops are along the same lines as the Published App option above where the desktop UI of the server that would normally provide the apps, is shared instead. XenApp (and its predecessors) can do this and provide a good experience for plenty of users. The Server 2008 R2 desktop (if you’re running XenApp 6+) can be configured to look a lot more like Windows 7 and users have access to any apps installed on the server (the ones you allow anyway). And because we’re mentioning apps, they can be installed any of the ways listed above – and that’s the important point.
- Virtual Desktops are a much more heavy-weight version of making desktops available. It’s not sharing the same virtual machine like above, instead everyone gets their own. Think of it like one person using a VMware or Hyper-V virtual machine that’s dedicated to them. Again, apps can be deployed through any if the methods above, but now we see much lower user:hardware density. We may also have to contend with user profiles more now. There’s also the option to persist the user changes through a reboot and mix with those that don’t (unsurprisingly called non-persistent). This can help with task workers having their config reset to an approved state at reboot, while allowing a developer to keep their own config just like a regular machine.
Comparisons Between Published and Virtual Desktops
Just to clarify, I call any user dedicated virtual OS a “Virtual Desktop” (VD), and the shared desktop with many users on a server, the “Published Desktop” (PD). They both have their pros and cons but I think that the Published Desktop is becoming a challenger to its own cousin.
With the help of software virtualisation you can now load almost any app onto a PD server and make it available for selected users. For other users the app does not appear and is even missing from the file system. This also helps with licensing as if other users can’t even see the app installed, they can’t use it and licensing shouldn’t be impacted (obviously confirm this in the case of your own apps).
Resources are much more shared in a PD compared to a VD which then allows more users per hardware resource. This is obviously part of the appeal for the VD solution, as users can rely on resources being available – even though they are all running on the same piece of hardware. For the same resources its likely 3-5x more Published Desktops can be used compared with Virtual Desktops.
If you want full VD for users you also need to think about storage and where you might want to store any differencing data for persistent desktops. i.e. all those little changes that the OS or user makes that then need to be inserted again when the persistent desktop restarts. Speed is important for any VD storage, so much so that the typical recommendation for your master VD image(s) is SSD drives. Not a big deal but it does give an idea that you need to go the extra mile for VD.
So if you have a bunch of users doing much the same thing (i.e. task workers) then PD is the easy choice and VD for the “power users” that have special considerations.
But why do you need all those VD when you’re virtualising your apps? Assuming you’re not overloading your PD servers then the user experience should be similar. You’re apps can be the same (with many more of them either locally installed, virtualised or published), your user profiles are going to save config information, and you’re not storing anything locally as data sits on remote storage.
Virtual Desktops still have their place – if you absolutely need a particular OS with allocated resources per user and dedicated desktops to avoid overlap with other users, they’re your option. But by the time you take into account all the pieces of that puzzle and add up the costs, you’re close to a laptop cost per user. Your users still need an end-point to connect from so . . .
Yes, Virtual Desktop is powerful, but it’s got a higher hardware cost and has a management overhead similar to your existing hardware client infrastructure. Published Desktop options likely fit in with some app virtualisation you have already and it’s a case of tweaking and expanding that design. Your app virtualisation can still work across your hardware clients and if you use App-V or SWV then you can share those benefits too. As you get more apps virtualised and user profiles streamlined then your options open up further when you really minimise the need for per user desktops. At the end of the day how many of your users would be able to tell the difference?