There has been a LOT of activity on the VMware blog since someone took the initiative to ask the VMware community which is the best VDI solution on ESX, View or XenDesktop. I have been fascinated with this discussion! The opinions are coming in from every direction and I thought it was time to put in my own 2 cents, from a my perspective as Citrix employee. I figured the the easiest way to respond was to separate the facts from conjecture.  

Conjecture 1: You can only use Provisioning Server with XenServer.  
Fact 1: Provisioning Server is totally independent of Hypervisor. In fact, it is also independent of Storage type/manufacturer and doesn’t even care what operating system is being delivered to the Virtual Machine (or endpoint or server). 

Conjecture 2: XenDesktop is more complex to install and manage than VMware View.

Fact 2: Make sure you are comparing apples to apples when it comes to the install experience. They are more similar than the folklore seems to represent. XenDesktop is a complete package including hypervisor, single image provisioning, app virtualization, user profile management, delivery controller, etc. However, XenDesktop is totally modular so you only install what you need. If you want to create a little proof of concept just showing user experience – usually the first step for customers – then you could set up View and XenDesktop with the Desktop Delivery Controller very easily in a short amount of time. But if you plan to scale this environment to say a couple hundred users or more, sooner or later you will need the advantages of single image management, application delivery, profile management etc. Obviously it will take more time to implement these features of the product. It will take about the same amount of time to purchase and/or build out an equivalent View environment based on our experiences in our labs. When you look at all the components of View, you find 5+ different install points (see red arrows below) and the same number of management consoles with a lot fewer features overall.

   Fact Con

Conjecture 3: XenDesktop Virtual Desktop uses more RAM than View-based Virtual Desktop

Fact 3: Desktop VMs on ESX will use the same amount RAM whether delivered by XenDesktop or View. When a desktop is configured on a VM, it is assigned a certain amount of RAM. This would be the same whether you are accessing desktop from XD or View. Given the same OS, applications, and users, the RAM usage on the ESX VM will be exactly the same. OS Streaming may actually reduce RAM footprint but, at worst, it would not impact RAM usage. 

Conjecture 4: XenDesktop is more expensive than VMware View.

Fact 4: When it comes to pricing, remember you have to compare APPLES to APPLES and meet the needs of an enterprise deployment. I won’t break out the spreadsheet right now but if you add in the price of the ESX licenses and 3rd party products to make View an equivalent solution with app delivery, profile management, etc., perceived price differences in fact will reverse in our favor quite dramatically. And as always, you get real WAN usability and low LAN bandwidth utilization with XenDesktop - not something you can easily go out and buy as an add-on for View. 

I saw some other comments that were essentially comparing XenServer with ESX. Since the discussion was related to ESX, I won’t get into the hypervisor wars (not this time anyway!) Let’s be real frank about this: Many of our installs are on ESX and they work great! Some of the guys that posted to this subject can back me up on this. But we’ve also seen a stunning change in some of the market research – the number of cases where XenServer is being considered for desktops has grown significantly in the last few months, and the number of “ESX only” shops is declining fast. 

Lastly, while I differ with most of what one VMware Community member, Rkelly, posted re View vs. XenDesktop, I have to say I agree with his final point for the IT team in any VMware shop:  “Download the trial versions of both products and see for yourself” .

If you would like to see the discussion in its entirety (including my response), here it is:;jsessionid=AEA74E768250EACA071B6476BB003137?start=0&tstart=0