Problem solve Get help with specific problems with your technologies, process and projects.

Results of a VMware View 4.5, XenDesktop 5 POC: #Fail

An IT manager tests VDI products from Citrix and VMware, and after seven months of piloting the latest versions of XenDesktop and View, he finds that neither is enterprise-ready.

FROM THE ESSENTIAL GUIDE:

VDI pilot project guide

+ Show More

For the past seven months, my team has been evaluating VDI offerings in hopes of achieving the management benefits...

promised by desktop virtualization vendors. During that time, I learned that even the latest and greatest products from top desktop virtualization vendors have limitations that some organizations may not be able to overcome.

The company I work for has been a VMware customer for several years, and we have successfully virtualized about 95% of our data center server infrastructure. Since VMware is established at my organization, VMware's View product was a logical choice.

Even though VMware offers a great server virtualization product, a virtual desktop environment is completely different than a server environment, so I needed to evaluate an alternative. Since Citrix has a proven track record with XenApp and has invested considerable resources to develop its XenDesktop offering, it was the other obvious choice.

Choosing established vendors with solid track records was an important factor because moving from physical to virtual desktops is a costly, time-consuming undertaking, and the last thing we can afford to do is choose a vendor that is not established. Of course, well-established companies do discontinue unsuccessful products, and they do fail, but I am willing to bet on the established companies with roadmaps and investments dedicated to improving their virtual desktop offerings.

VMware and Citrix both sponsored technical resources for this proof of concept (POC), and Citrix even sent technical resources on site four times to assist in our POC. I was very impressed with Citrix, especially since we did not have an existing Citrix environment and no commitment to purchase. VMware was also very accommodating, and when our engineer had questions, its representatives were quick to respond.

During the pilot, we went through two releases from both vendors and were careful to compare the latest versions of both products fairly. The final pilot involved the latest releases, VMware View 4.5 and Citrix XenDesktop 5.

The POC virtual infrastructure
A large pilot environment wasn't necessary because my goal was to find out how the systems would perform on the wide area network (WAN). Virtual desktops introduce a massive amount of traffic.

Our WAN testing consisted of 10 zero clients, five for View and five for XenDesktop. We also tested thin clients. I was more interested in zero clients, however, because those devices require less management. I began our WAN testing on our smallest, most latent lines, which were 1.5 MB, 80 milliseconds (ms) one way, and moved to our largest, least latent lines -- 10 MB, 3ms one way.

The back-end hardware we used was new and identical for both environments. We didn't introduce solid-state disk because the pilot environment had only about 60 virtual desktops. The Raid 5 array was configured independently of our other environments and included 146 GB 15,000-rpm Fibre Channel disk drives.

PCoIP, HDX and the end-user experience
During my research, I read that PC-over-IP (PCoIP) took more bandwidth than ICA (now HDX), but that wasn't the case. If we tweaked the settings to match those of ICA, it actually took less bandwidth. Not a lot less, but I was surprised.

Of course, both environments can be manipulated to get different bandwidth numbers, but even with bandwidth changes, the resulting performance was not good on the 1.5 MB lines for either product.

The Citrix environment outperformed the VMware one on those lines from an end-user perspective. Although VMware View took slightly less bandwidth, PCoIP did not perform well when scrolling. XenDesktop did a better job when scrolling through different applications and the Web. But neither could support video on the 1.5 MB lines, so we quickly shut down video testing.

The Citrix clients showed a cleaner image on the monitor, while VMware clients looked blurry because of the different protocols behind PCoIP and HDX and how they render images. In fact, a couple of our test users said they got a headache looking at the screens running View.

After three full days of testing on our 1.5 MB lines, we concluded that virtual desktop infrastructure (VDI) would work only if the location had five people or less and none of them needed to do anything that involved Flash, HTML 5 or Silverlight.

On an average day, those locations use about 20% of their allotted bandwidth (one location had 30 users, and the other had 10). After introducing VDI, we used nearly 100% of that bandwidth with five machines doing random work such as surfing the Web and working on a Word document in both environments, so we wrapped up testing.

While I was disappointed in the results from the initial tests, I hoped to get better results at the 10 MB location, and the initial results appeared promising.

But once again, scrolling in the VMware View environment was not as good as in the Citrix environment, and XenDesktop 5 was more responsive than VMware View 4.5. VMware, however, did a better job with the video content we tested.

With video testing at the 10 MB location, we did not redirect any video traffic; it was rendered on the server, and both products used large amounts of bandwidth when playing video. On average, when playing a video from CNN.com, we saw 5 MB to 7 MB used in both environments (not full-screen). When testing the same video on a thick client, average bandwidth was 900 KB.

At that point, I was convinced that a zero-client architecture was impossible if we wanted to do any video over the WAN, unless we were willing to do some major upgrades to our WAN links.

I also decided to discontinue testing View because we weren't getting the results we were looking for.

Thin clients vs. thick clients
Our testing outside of video was at least as good, if not better than, the experience on the current "thick client" architecture. Without the introduction of video, each device used an average of 400 KB while working in the VDI environment. So, we began testing thin clients and thick clients with client software to take advantage of redirect technology.

Although I was discouraged that we could not use zero clients, I was looking forward to what Citrix's HDX technology could do for video redirection. We made the necessary changes to the system to force redirection, but the performance and bandwidth usage didn't improve.

With thin clients, round-trip latency increased from 6 to 8ms to 30 to 40ms. What we didn't realize was that redirection will work only if round-trip latency is 30ms or less, and we were now exceeding that latency threshold.

We could deploy Citrix VDI to end users who don't use video, but I'm concerned that they may need to use it in the future as video training and Web conferencing use grow. So after seven months of testing, we determined that neither VMware nor Citrix VDI products could satisfy the needs of our organization.

Today, it seems the only benefit that virtual desktops offer is data centralization. But I will continue to monitor VMware and Citrix's VDI products, and when they have made enough progress, I'll revisit those offerings because I still believe the technology will be applicable in the future. 

ABOUT THE AUTHOR:
Jeff Moore is an IT Manager in financial services with nine years of experience in research, development and infrastructure planning.

This was last published in January 2011

PRO+

Content

Find more PRO+ content and other member only offers, here.

Essential Guide

VDI pilot project guide

Join the conversation

18 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

So you blew off a perfectly viable solution just because you didnt know you can set the redirection latency treshold using a XenDesktop policy to something a little higher than 30ms without causing any problems..

We crank it up to 250ms sometimes with no issue at all.

I think you are one that #FAIL-ed in this particular test, and not the product.
Cancel
Peter35267 I can appreciate your comment and yes my team was aware of the ability to change the latency threshhold. Citrix did not feel that changing the latency threshhold would solve our issues. On our 1.5 MB line tests we saw latency upwards of 400ms. I should have noted the ability to change the threshhold although people need to understand the issue exists.
Cancel
Good to see some real world figures and experiences Jeff, thanks for that.

Now if only sales people would stop calling me every 30 minutes trying to sell me VDI...
Cancel
I'm guessing you weren't using xendesktop branch repeaters with your testing on your wan... and your article title is not appropriate, it didn't just flat out fail, it failed on your wan and possibly because you didn't have it configured correctly
Cancel
The accepted solution is to run your apps on xenapp. with no Apps on xendesktop. Your asking for trouble thinking a vdi can pull the weight of a Physical workstation.
Cancel
David14507 We did test the branch repeater (that was one of the reasons I stopped testing View) from Citrix at our 10Mb locations and it did not benefit us (latency was to low). We had a Citrix engineer on-site working with us on the repeater. We did not test the repeaters in the 1.5Mb links because at best Citrix said we could double our user count (that was not enough). As far as the title, I am not in control of that and I agree with you. I plan on revisiting VDI following the next software release (about 6 months).
Cancel
Jeff, please refer to the following blog post (and inline link to a comprehensive white paper on the topic). user experience is critical in the world of desktop virtualization. The fact that you saw 400ms of latency on a link is a clear indication that the link was getting saturated. The TCP protocol without WAN optimization (like Branch Repeater) performs horribly under high utilization and packet loss. WAN optimization is not a silver bullet for all network scenarios, but you were apparently measuring a lot of noise.
Cancel
Should have included the link :) http://community.citrix.com/pages/viewpage.action?pageId=126452163
Cancel
First of all ICA is not HDX.
Second, don't compare with Xenapp because you wil have the same results there.
Third, if you want thin client use Windows embedded or WYSE Xenith (at least HDX ready).
Fourth, use repeaters.
Fifth, use Xenclient by low bandwith to have offline VDI.
Sixth, use policy's for bandwith management.
Seventh etc. etc.

Not sharing you meaning. We are using it and it performs perfect. Golden rule is sizing and metering!

One thing is completely true. VDI is EXPENSIVE!!!

One more thing. NXTOP is a very nice product but you can't compare it with this.

As for view. No experience with that.
Cancel
True and Not True. I agree with your findings and I also agree with some of the comments posted. It is possible to get it right. VDI is highly workable on a LAN (if you have the right infrastructure in your premises). Everything will work the way you planned it. However, when you move to the WAN side, there are many other factors that can affect performance such as the type of users you have, application requirements, bandwidth, latency and optimization hardware, application delivery methods, video delivery, additional manpower to manage the new solution, new hardware, redundancies, etc. At this point in time, VDI doesn't come cheap at all and the benefits may not be realized as fast as we initially think would be possible. However, with more and more tablets and faster smartphones, we are undoubtedly moving towards VDI and this trend seems unstoppable right now.
Cancel
Should Zero Clients Go Back to the drawing board?

In general, I was disappointed by the analysis which placed the need for a zero client first, rather than obtaining a client suited for workload, in this case, video, in some cases.

Also, if the author considered the protocols (some of which are designed to be heavier on the client side), then comparing Citrix and Microsoft would have been a better test. The more advanced protocols are designed with future mobile computing in mind, and not the limited capabilities of the so called zero desktop client vendors.

In the base, using video and real time scrolling of market data feeds over X Windows over TCP/IP and the Internet, there were good and bad clients.
We saw SUN tout "no disk" workstations which failed for trading systems in the 80's and 90's because it failed to take into operating system needs to perform swapping, etc. So what worked was not "diskless" workstations, but dataless workstations that had sufficient memory, video processing and swap disk (preferrably two small disks back then) and any vendor's workstation -- DEC's, SUN's, IBM's, etc worked better for the user experence and the workload (8-12 realtime market applications at a time).

Given the trends of the amount of RAM and processing in tablet and other mobile devices, perhaps the author should consider very capable processors and lots of RAM, etc. I've experienced exceptions iPad video performance over 2MB links looking for alternatives to zero clients. Wyse makes zero clients that don't really support PCoIP, but their best client may be the PocketCloud iPad application.

I am curious about the PCoIP VMware View settings on the bandwidth, etc to get better performance, but they might not be necessary with a 'thinner' client tailored for the processing power and local graphics rendering these protocols demand.
Cancel
This doesn't sound right. Your saying that a 1Mbps video stream to a FAT Client, Took 5 to 7 Mbps of Bandwidth to display on a Zero Client? Thats a lot of VD display overhead (83.3% ..or 5 of 6 Mbps. I think more specifics of your test methods are in order
Cancel
Lucia39280 In our testing since we were not redirecting with HDX, the traffic for a single zero or thin client measured between 5 to 7 Mb consistently. We did daily testing over a one month period in a single location with a 10 Mb link and that finding never changed. Unfortunately the article can only be so long so it is difficult to share all of the details, that is why I am responding to these great comments as I have time. As a manager I found it extremely difficult to find this kind of information. We utilize NetQos as a monitoring solution and that is what we used for this testing. If we were able to redirect using HDX I assume we would have seen similar numbers to that of the thick client experience (700-900Kb)
Cancel
Larry57038 The ideal situation for me was to have an environment built that eased management and centralized our data (I felt zero clients were the easiest to manage). We tested thin clients (Windows Embedded, Linux) from Wyse and HP, we tested FAT clients with Citrix and VMware software, and we tested zero clients (Wyse Xenith for Citrix and Wyse P20\10Zig for VMware). The zero clients from these vendors are not truly zero but all that is required is a firmware update. That as far as I am concerned is much easier to manage then a thin client that requires updating for the OS and client software i.e. virus scanner. For my purpose data centralization was the most critical piece of this testing so a thin or FAT client option was always on the table. When we utilized the Citrix and VMware software on a FAT client the performance was better (low jitter/better audio) but the bandwidth did not change because we could not take advantage of redirection (yes we could have changed the latency threshold but that was not recommended by Citrix). When we tested the solutions on the LAN all clients including the zero clients worked perfectly in regards to image quality and usability, we even got our teller printers to work on them with a USB to serial adapter. So in response to your first question, I believe the Zero client is a good solution for a LAN deployment but they need some improvements in order to work on a WAN with limited bandwidth where video is needed.
Cancel
Larry57038 One other quick thing, we did test with RDP for VMWare but we did not get the results we wanted in comparison to ICA.
Cancel
A square peg into a round hole;

If you want the latest and greatest solutions to work from Citrix, including the MMR or Nitro HDX , there are a couple of essentialls that you need. #1 Processor/GPU on your Thin Client, #2 Latest Client from Citrix, #3 Configured and fine tuned to ensure minimum management of your physical clients so you can concentrate on the Virtual Desktops

#1 HDX detects the power of the client device and utilises as much of the free processor as possible, you were using a C7 1GHz Xenith, even on a LAN this device does not support Flash redirection, #2 explains why

#2 Redirection is exactly that, it means that Flash, multimedia etc are not rendered on the server, but on the Thin Client, if you use a Zero Client you might as well be trying to render video in outerspace, there is no native Adobe Flash, no native HDX client, no .Net 2 or other key building blocks that are essential for the HDX client to render/play/display the Flash, Video or session locally. Citrix deisgn and develop their client predomenantly on Windows based OS' and take advantage of the key building blocks that are natively there. Further more with their support for RemoteFX and session redirection comming soon, is it a good idea to lock yourself into a Zero Client that, in my opinion will always struggle to support these features as well as a Windows based OS.

#3 So you need a Windows based OS and a powerful processor and GPU (for the future developments of Citrix) on your Thin Client. But just because its Windows, doesn't mean you need to load it with an AV and patch updates. I would configure it to "Appliance" mode so it replaces the explorer shell with a locked down, autostarting, navigationless, full screen browser pointing to your virtual desktop and with all other access to the host OS removed. You now have a Thin Client device that is essentially just a Window into your Virtual desktop. Because your data is in the data centre and the only thing that your Thin Client is doing is rendering and displaying your session, flash and content do you need virus protection on the device? Really?

Updating the Win Thin Clients, shouldn't be too difficult, or regular if you choose a Thin Client with a good management tool options. 10ZiG Technology's WES 09 and WES 7 devices have their auto updates disabled and a enhanced write filter (EWF) so there once the device is configure, it stays the same until you want to update it, same fast fresh boot every time.

10ZiG have also just released a Thin Client with a Nano Processor and VX800 GPU that supports both of these solutions better than any Thin Client that I have ever seen, 3D rendering included.

Cancel
James57534 All great points, what about the cost considerations between the Zero Clients and the Thin Clients? The Xenith is very reasonably priced and in my research were between $100 and $200 less expensive than alternative Thin Clients. I still believe the Zero Client offers a viable alternative (not ideal but viable) on the LAN. That being said, when we revisit VDI in six months I am doubtful that we will be testing with Zero Clients. Another question weighing on me would be the extent to which HDX will redirect other multimedia platforms like HTML 5 and Silverlight in the future.
Cancel
did you consider utilising any WAN acceleration technology?
Cancel

-ADS BY GOOGLE

SearchEnterpriseDesktop

SearchServerVirtualization

SearchCloudComputing

SearchVMware

Close