Setting up XenDesktop
If you simply want to learn more about our experience using virtual desktops with NVIDIA GRID, we recommend skipping ahead to the next section since this section is all about the setup of XenDesktop and configuring it to work with NVIDIA GRID. If you are interested in what happens "behind the scenes", however, read on!
To setup our virtual desktop, we chose Citrix XenDeskop to stream the virtual desktop and used Citrix XenServer as our base VM hypervisor. After installing XenServer onto our physical server, we followed the Configuring GRID on XenServer guide to install the NVIDIA Virtual GPU Manager for the GRID cards. If you are actually going to be doing this yourself, we recommend checking to make sure there is not a newer version of the guide available as we came across multiple versions with slightly different instructions depending on the driver version.
Once the NVIDIA Virtual GPU Manager was installed, we then followed the XenDesktop Reviewers Guide to install and configure XenDesktop. This involved first creating two virtual machines running Windows Server 2008 R2 SP1. One was simply an Active Directory/DNS controller, while the other ran SQL and the Desktop Delivery Controller (XenDesktop) which has to be installed on a separate server from the domain controller. If you already have a domain controller, then you only need the one additional server running XenDesktop.
With the servers created and updated, we then made a couple of new virtual machines running Windows 7 with the NVIDIA GRID card assigned as a vGPU. We chose Windows 7 over Windows 8.1 because at the time of this article the Virtual Delivery Agent (which "streams" the desktop) was not yet compatible with Windows 8.1. Once the virtual machines were updated and configured how we wanted, we then installed the Virtual Delivery Agent onto the virtual machines. The Delivery Agent can be configured to either make the VM work as a master image for other virtual machines or you can keep the VM as it is and enable remote PC access.
With the host virtual machine created, updated, and configured, we went back to the XenDesktop server and - still following the guide - created a Machine Catalog (a list of the virtual machines you want to group together) and a Delivery Group for that catalog which defines which users can connect to the virtual machines. If you chose to make your host virtual machine a master image, then you can also configure how many virtual machines you want to be created from that image (which determines how many users can connect at one time) as well as how many vCPUs and memory each virtual machine created from that image get.
With all this setup done, we were finally able to connect to the virtual desktops through the Citrix Receiver software that was installed on our client PC (which was working as a thin client). This connection process looks like this:
If you are a remote user, you first have to access the local network through an access gateway. After that (or if you are a local user), you login to the web interface which is hosted by the XenDesktop server by using your domain username and password. The XenDesktop controller then checks to see which virtual desktops you have access to and displays them in your browser. Then, you simply pick the virtual desktop you want and the XenDesktop server connects you to the appropriate virtual desktop.
XenDesktop for Applications and Everyday Use
For all of our testing, we used a Intel NUC D34010WYB which includes a low-end Core i3-4010U 1.7GHz CPU as our client device. We added a 4GB RAM module, a 250GB mSATA SSD and installed Windows 8.1 Pro as our client OS. The Intel NUC is very small (with our enclosure it is only about 4" x 4" x 1.5") and doesn't have much in the way of CPU or graphical power but it is perfect for streaming a virtual desktop. In fact, compared to many thin clients you can purchase, you could argue that the NUC is overkill for this application.
Overall, with the Intel NUC connected to the virtual desktop using XenDesktop we were able to run applications, browse the web, and even watching movies without any real problems. XenDesktop has a default streaming speed of 30 FPS, which may seem low but most movies (including streaming services like YouTube and Netflix) play videos at 24-30 FPS so the 30 FPS limit is actually not a factor. Even for applications the 30 FPS limit was not nearly as noticeable as we expected.
To gain a first-hand impression of XenDeskop, I used a virtual desktop as my main working desktop for a couple of days. Surprisingly, the performance was so good that there were numerous times I completely forgot that I was not using a normal local PC. A typical workday during this time included lots of web browsing with Google Chrome, some light Photoshop work, and some medium AutoDesk inventor work. We are not going to get too much into performance numbers since the performance you will see will depend entirely on how much power you assign the virtual desktop, but compared to the very basic PC that was used as a thin client the virtual desktop certainly had a huge performance advantage in applications like AutoDesk Inventor.
With the viewer running either in fullscreen or with the viewer window focused, we had absolutely no problems with the Windows key or any keyboard hotkey combinations like Win-E or Ctrl-C. We used HDMI to output audio through the monitor and that also worked perfectly. In fact, we were even able to plug in USB devices like a thumbdrive and USB game controller and it would show up in the virtual desktop just like you would expect it to on a local computer.
Most of the employee computers here at Puget Systems use more than one monitor (some of our employees even use four or five monitors on their computer!) so one thing we were interested in was how well you could run your local desktop on one monitor and a virtual desktop on a second monitor. Really, there isn't much to say; it worked great. We simply made the viewer fullscreen and it really felt like the virtual desktop was a part of our local desktop. You can't drag a window or file from one desktop to the other, but we did find that we were able to copy and paste text from one desktop to the other.
The only real issue we came across was that sometimes the mouse cursor would not render properly in applications. This never happened with any of the default Windows cursors, but some program-specific ones would render a black box around the cursor. Interestingly, we were unable to capture this behavior with screenshots so we had to take a picture of the screen with a camera. This is a relatively small problem but it was a little distracting when it happened.
Overall, we were very impressed with how well XenDesktop worked for applications and everyday tasks. There are still all the disadvantages we discussed earlier, but if you are looking into desktop virtualization and you can deal with those disadvantages then we highly recommend checking out either XenDesktop or VMWare Horizon View.
XenDesktop for Gaming
First, let's be clear: until recently, NVIDIA GRID and XenDesktop/VMWare Horizon View was not really being designed or marketed for gaming. While it is improving quickly, if game streaming is your primary concern then virtual desktops might not be the best choice right now if you don't have a large number of users. But in the situations where you want or need to use a VDI like XenDesktop then there are a number of things you should be aware of.
When using XenDesktop with NVIDIA GRID cards, the biggest problems we found were not related to performance (our GRID K2 workstation card actually performed pretty well considering the drivers are not optimized for gaming) but rather the fact that fullscreen mode and mouse capturing is simply not supported. The fullscreen issue is actually on purpose with XenDesktop (and VMware Horizon as well) to prevent a user from being unable to access their local desktop, but means that you have to run a game in windowed or fullscreen windowed mode. While this can be easily worked around for most games, the mouse capturing issue is a bit more of a problem and results in some really strange behavior in games like first and third person shooters that use mouse capturing.
We tried Borderlands 2, Just Cause 2, Battlefield 4, and Team Fortress 2 and found that the lack of mouse capturing really messes with the mouse sensitivity. A tiny move of the mouse would result in your character spinning around in multiple circles. Even with the mouse sensitivity turned down to the lowest level possibly, the games were still unplayable. However, we did find that using a USB controller like an Xbox 360 controller worked perfectly. So if you prefer controllers over a mouse/keyboard than FPS games should actually work fine.
Other games that don't require that kind of mouse capture worked surprisingly well with a keyboard and mouse. Racing and arcade games like DiRT Showdown and Super Street Fighter IV that only use a keyboard ran pretty much perfectly. MOBA and strategy games like DOTA 2 and StarCraft 2 were also very playable although sometimes the mouse cursor would be the default Windows cursor rather than the game's custom cursor. The biggest issue with these games is that since you have to run games in windowed or fullscreen windowed mode you can sometimes accidentally click the mouse outside of the gaming window.
From a playability standpoint, the 30 FPS streaming limit was certainly noticeable but whether it is a huge problem is going to depend on the user. Some users have no problem with 30 FPS while others really prefer to have something closer to 60 FPS or even higher. Even with the stream running at only 30 FPS, we saw a bit of display lag when we tried to play games at 1920x1080 and ended up having to turn the resolution down to 1366x768. 1080p worked great for browsing the web and running most applications, but games simply have so much activity on the screen that it caused just a bit too much lag for us to be able to game comfortably.
One thing that caught us a bit by surprise was how little input lag there was once we set the resolution to 720p. It was certainly still there, but was honestly not as bad as we thought it was going to be considering that we were playing a game remotely over the network.
Overall, playing games on a virtual desktop was not as great as we hoped, but also not as bad as we feared. Game streaming isn't something we would quite recommend doing just yet outside of the most casual of games, but we have no doubt that it is going to greatly improve in the future. No matter how much better it gets though, input lag (even a tiny amount) is probably what is going to be the biggest hurdle for this technology. It was actually not very bad over a local network but we can't see this being used for any sort of competitive gaming in the near future. However, if you just want to be able to play games that are playable at 30 FPS and don't require very much in the way of twitch responses then virtual desktops with NVIDIA GRID would likely work great.