Now compare this to XD the same 4 node deployment was over a week of shoehorning etc, bear in mind this is on Teir one hardware. Also to get similar functionality you will be presented with I think 6 different management consoles. you also have the added benifit of Offline Desktops (albeit experimental) with view that is not available with XD.

True ICA is a better remote protocol that RDP, but form my opinion the pain points are too great for the product.

If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points

Tom Howarth VCP / vExpert
VMware Communities User Moderator
Blog: www.planetvm.net
Contributing author for the upcoming book "VMware Virtual Infrastructure Security: Securing ESX and the Virtual Environment”.

Anyway, the memory and user experience are pushing us over to View. XD seems to be a bit more polished, and have more... granular features (i.e. rebooting VMs at a specified time every nite, needing to use Splitview for effective multimonitor support which is much better in the CIA client), but there's not much that I've come across that I couldn't work around with a little effort.

With View, we took a group of the same physical PCs that were connected with XD, and installed the view client. The PC will RDP directly to the VM, so already you're cutting out one part of the process with View. Instead of streaming the information from a server, View makes you create what they call the Parent VM (same concept as the Golden image with Citrix. In fact, I just copied the Golden image VM and used that for my View Parent VM). That parent VM is then copied by View manager when you create one of your groups. (Note: I'm describing using linked clone VMs) The actual View VMs run off of that copy, and have what they refer to as a delta disk in the VM that caches all the changes. There's an option for having a more "static" repository for user information that doesn't refresh as often as the changes to the OS do, but we didn't test that as we currently don't have a need for it. So with view I can see the need for very fast storage. We're lucky, we have a FC disk array with pretty speedy disks, but if you're using slower storage, I can see I/O being a bottleneck there. Also, while the Memory is lower per VM on View, we do see a slightly higher average CPU utilization. We were able to get new servers for our ESX cluster last year, so we have oodles of CPU cycles available, but that could also be another bottleneck for View. We still have our old ESX servers in another cluster and tried both the XD and View VMs on those servers and users reported a noticable performance decrease, but not enough where the system was unusable, just a bit slower overall.

We tried to look for performance related problems with XD, but we couldn't see anything that cause our issues. We tried having the server run as a VM and as a physical server with fast disks. We have GB network and lower network utilization, and capacity for the network on the server never hit over 50% (Max recorded average 20-30% cant recall exactly).

Keep in mind, this was our setup in how we needed it to work for our users. Each environment has different variables that may change testing outcomes. Type of storage, type of servers, disk speeds, memory available, SAN type and performance, LAN speed and utilization etc etc etc. The only real way to tell what's going to be good for your organization may be to download the trials and run them and see what fits. Just reading the difference between View and XD, we were leaning towards XD. After the trial, we're going with View. Don't always trust marketing materials or information.

Finally as for price, again, I can only tell you what we've gotten back and XD has come in more expensive than View and that includes purchasing Splitview as well.

Basically the biggest reason is that most companies are a VMWare shop. So it makes sense to only have to call one vendor for end to end support.

Also cost. View costs less per desktop compared to XenDesktop i.e licensing, more VM's per physical host, linked clones for storage savings etc. TCO is very important because desktop costs are already very low.

Stability. View has less componenets and VMware historically does great QA on the products that they release. Microsoft and Citrix, not so well.

Big reason, VMware views linked clone technology. SAN storage is not cheap, PC hard drives are. You need to be able to sell this to senior management. When you tell them the hard drive storage is going to be 4 times as much they will laugh at you.

XenDesktop has similar but not exactly the same technology. Their's does not keep the running state of the VM when it is rebooted. The windows OS is reset. This plays havok on legacy and custom applications. They do have a profile tool but who wants to mess with all that. Again more cost and overhead.

Complete isolation of the running VM whether it be on the server, off-line or on the upcoming CVP platform. Basically a universal platform for servers and desktops. We don't want to worry about driver or hardware conflicts in the future. Xen uses pass through to directly talk to hardware, this is something we don't like.

Big reason from a customers persepective. We have all tried Citrix before for thin clients and customers are very reluctant to go down this route again. VMware is something fresh and new and they like what they have seen from the server hosting side of things.

As others have mentioned, XenDesktop is very hard to setup and configure. Also the XenDesktop agent that is installed in the virtual desktop VM is very resource intensive and busy. You have to increase the amount of RAM in the VM just to make it usable. This really throughs out a lot of cost savings. This was not the case with the VMware view agent. The View agent was almost idle.

Display protocol performance wise Vmware view was slightly better. I was surprised because I thought ICA was supposed to be better then RDP. Note, VMware view uses RDP with some enhancements.

On View the video and sound were better and smoother.

Flash was the same on both, this may be better on view since 3.1 release.

The view desktop launched much faster and logged right in. The Xendesktop lagged to even open and then took a while to login to windows. This would be annoying for users and probabaly create a lot of calls.

Hope this helps!

1) I'm a VMware shop 1 throat to strangle.

2) Just because XD works with ESX backends now doesn't mean they will in the future.

Is View perfect? Not at all. I even have a potential show stopper open with VMware product management right now. Depending on what their answer is it may scrap my entire project. I believe XD will have the same issue but I can't say for certain.

USB Redirection is actually a major requirement for me. I (and 11000 of my peers) have a device that View doesn't work with (And so do 25 million other people)

I hope this gets resolved....