Planning Deployment of Virtual Desktops

[etieseler]

I have a few items I would like to get input on. First off, is VDI now VMWare View?

Next, I am in the planning stages of replacing many of our desktops and I want to virtualize a fair amount of them. I am looking at Thin Clients and I want hardware accelerated PCoIP support. What have you used and how has your experience been with them? Some of them I will need to have a credit card reader attached to it, via USB. Is this something supported on a Virtual Desktop? How about CDROM support? If someone wanted to put in a CD to listen to, how have you gone about supporting that?

What kind of vDesktop have you made? Do you use 2vCPUs or single CPU VMs? How have they been performing? Have you put your Virtual Desktops in the same vSphere cluster as your servers? Or do you have separate ESX hosts for just desktops? I know I should use Resource Pools to keep the desktops from stealing all the resources form the servers.

I know that Desktops have an entirely different kind of load than servers, I know they create a lot more disk activity, but is it enough that I should have a separate cluster?

I can see anywhere from 9 to about 20 desktops I could virtualize, they are basic workstations using Word and Outlook, some Citrix clients, and a few other applications, but nothing to intensive, no CAD or software developers compiliing code. One may be using Photoshop.

9 of them would be over a WAN. I am contemplating placing ESX hosts at each of the WAN sites to host the desktops in those locations, and replicating them back to our main site.

Just looking for experiences of others, any tips or tricks anyone uses, gotcha's or issues anyone has had. And hardware support for USB items, such as the credit card reader I mentioned. And support for attaching CDROM devices.

For the moderators, not sure if this question should be in 'Enterprise Planning & Managing'...

Please, discuss.

-Ed.

[eeg3]

First off, is VDI now VMWare View? Yep.

What have you used and how has your experience been with them? We've been pleased with Wyse's thin clients, particularly their SLES-based units (no hardware PCoIP in these, though). We've also tried HP's thin clients. Wyse is a little pricier, but overall better. The Wyse P20 is a hardware-based PCoIP thin client and I have heard nothing but good things about them.

How about CDROM support? There is no local CD drive support with PCoIP yet. We have to use external drives.

What kind of vDesktop have you made? Do you use 2vCPUs or single CPU VMs? How have they been performing? We start with 1 vCPU and 1GB of RAM, and bump it up if it can be proven it is needed.

Have you put your Virtual Desktops in the same vSphere cluster as your servers? Or do you have separate ESX hosts for just desktops? Nope, we have a separate vCenter/Cluster setup for View. This was primarily driven by the fact 4.1 doesn't work with View, but it is also good practice in general. VMware recommends separating, as well.

I know that Desktops have an entirely different kind of load than servers, I know they create a lot more disk activity, but is it enough that I should have a separate cluster? Storage is THE #1 bottleneck with Virtual Desktops when you scale out. Plan your IOPS needs very carefully; you may start small then everyone wants a virtual desktop. Lots of tools out there to help you get a good assessment; check out Liquidware Labs' products.

I'd recommend you try out some of Wyse's thin clients. You can get a demo unit and return it if you don't like it. Virtual desktops can be a big undertaking if you want to do it well, good luck!

[mittim12]

1: VDI stands for virtual desktop infrastructure which can be used to describe any desktop that is hosted virtually. This could describe Xen, Hyper-V, or VMware environments. VMware View is a connection broker that faciliates connections to these desktops.

2: Haven't done a lot with thin clients but here is a compatbility guide. http://www.vmware.com/resources/compatibility/pdf/vi_view_guide.pdf

3: USB redirection is supported. Get demo models and test before you buy.

4: Every workstation load is different but we use 1 CPU and 1 GB of memory for WIndows XP.

5: We utilize the same vCenter but have seperate physical hardware for servers and desktops. I would not mix desktops and servers on physical hardware or backend storage.

6: Your storage backend will be the most important piece to this puzzle. If you don't scale properly you will have poor user experience and that will derail a VDI project in a heartbeat. We use th liquidware labs product mentioned above and it works great. It be used for assessment and for user monitoring after the fact. From past experiences I would tell you to carefully plan your AV deployment for VDI machines, maybe even take into account the new vShield endpoint product. I would also play close attention to profiles and printing.

This site has a lot of great info.. http://www.vmware.com/resources/compatibility/pdf/vi_view_guide.pdf

If you found this or any other post helpful please consider the use of the Helpful/Correct buttons to award points

Twitter: http://twitter.com/mittim12

[etieseler]

Thank you both for the helpful info. Good point about AV as well mittim12, all those VMs running a product that can bring physical hardware to a crawl, I can only imagine what would it would do to the CPU and Disks when its consolidated... almost worse than having an actual virus.

I'll check out liquidware. Both of you mentioned it for assesment, I'm sure I'll find out when I go research it, but it will give me a good assesment of IO load so I can size my datastore appropriatly?

I can't award too many more points, but any further discussion/input by anyone would be helpful. Not only for myself, but others in the planning phase of a VMware View implementation.

-Ed

[mittim12]

View 4.5 has been released so you can also look at the vShield endpoint to offload some of the virus scanning.

If you found this or any other post helpful please consider the use of the Helpful/Correct buttons to award points

Twitter: http://twitter.com/mittim12