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 watch 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.
Virtual Desktop running Autodesk Inventor as it looks when the viewer is fullscreen. The only thing that makes you realize this isn’t your local desktop is a small drop-down toolbar at the top of the screen. 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 at Puget Systems use more than one monitor (some even use four or five) 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.
On dual monitors you can almost seamless integrate a virtual desktop with your local desktop. On the left is our local desktop, on the right is a virtual desktop running Maya 2015 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. It’s 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.
