We're heading down the VDI route and have started looking at VMWare View and Citrix XenDesktop. We will store all VMs on ESX 3.5
My main question though is what is the experience comparing VMWare View to XenDesktop. I'm having trouble understanding the concept of how desktops would be "streamed" to the ESX hosts with XenDesktop compared to VMWare Views simple VMs on an ESX host model.
Also, how does performance compare between the two. I've heard from somebody that XenDesktop's way of streaming the OS down offloads some of the processor utilisation away from the ESX host onto the Provisioning Server. Is this correct? If so, how does this scale? We are thinking of 600 desktops. I don't want to be saving money on ESX Servers to be spending them on multiple Provisioning Servers.
As we are already using VMWare ESX, does it make more sense to use VMWare View as it would be a closer fit or does Citrix XenDesktop potentially have advantages such as potentially less CPU usage, ICA protocol performance.
Would be very interested to hear your experiences and find out how you chose your desktop broker?
Well apart for the fact that to utilise Provisioning server with XenDesktop you acutally need XenServer so the provisioning option is not really available with ESX. I have found View very easy to install, configure and manage, from bare metal to delivery of 4 nodes less than a day. you have two consoles, vCenter and View Administrator.
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
Contributing author for the upcoming book "VMware Virtual Infrastructure Security: Securing ESX and the Virtual Environment”.
Thanks for the info Tom.
I can't seem to find any information that in order to use Provisioning Server you need XenServer as well.
In the Citrix XenDesktop Evaluator’s Guide which I've been using to get an idea of what would be required I see under Guidelines for Using VMware Infrastructure 3 that you need a DDC and a PvS but no mention of XenServer.
I agree with the commenter above in that the learning and management of View is much easier than XD. I'm wrapping up a live test of both solutions currently and our users, who have used both View and XD for a few weeks each, say that using View is much more responsive than XD. The biggest surprise was that the XD VMs were using about 2-3x MORE RAM than the the View clients and people were reporting better performance on View. I'm not sure exactly as to why, but I think it's because of how XD streams the image to the VMs. (As a side note, our users have a boat load of apps open at all times and 3 monitors.)
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.
I'm still trying to get my head around why there would be any difference performance wise between VMs running through either system.
Surely the VM whether connected through VMWare View or XenDesktop is still running its processes on the ESX host and so CPU / Memory performance should be the same.
Also confusingly some people are saying that VMWare View used less resources and others say XD less...bizzarre.
Also, in terms of the streaming for XD, is this just the OS disk files (VMDKs) being read from the provisioning server master image so in effect the /O is being streamed but this should not change where the CPu / Memory is coming from ie. the ESX hosts.
Also, we are getting very high comparitive costs between XD and View. View is coming out at double the cost per client compared to XD Advanced Edition which means it will have to be XD for now unless something changes.
I wish someone would do a definitive comparison of the two technologies so we can be enlightened.
While XD and View do the same thing at the end of the whole process, the ways that they go about doing it are very different. In the setup we tested, XD had their golden image stream off a server. That server also had a folder per VM for write caching any changes on a seperate disk that the VM needed to make from the golden image. The physical machines would boot into a stripped version of XP with the Citrix client installed and ICA to an available VM. That VM would PXE boot to the server with the golden image. The VM actually only had a 1MB virtual disk so it could boot (evidently a thing with VMware where it needs to see a vdisk). So there's numerous points where bottlenecks could occur. Network from the physical PCs connecting to the server, Disk I/O from all the caching, disk space (we hit and issue where we filled the disk one day and everyone stopped working), etc.
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.
We have chosen to use XenDesktop. This is partially driven by the premise that all resources will be virtual (servers, desktops, apps, etc.) and Citrix has provided the most robust consolidated tool set to do this.
There is a learning curve for most who enter the Citrix world. There is a bit more complexity in the configuration as some has stated, but we are reaping the benefits.
First, many or our workforce demand access to their workspaces from anywhere at anytime. ICA is a much better protocol to deliver a rich user experience with as little as 256K of bandiwdth. In fact, I have run my XenDekstop from my HTC Mogul to perform troubleshooting and systems administration. Our tests with RDP accross the WAN left man users frustrated and our network team realling from having to order "more".
Second, the secret to great XenDesktop performance is local caching. While XenDesktop does stream the desktop and cache the changes, the management of this cache is very important. In our testing, we have discovered that each XenDesktop VM is given a 2GB local drive. This drive is where the cache is written to. We bump this drive up to 4GB for heavy users. Performance has been stellar with this configuration.
What sold us on XenDesktop though was the systems mangement component. One system to patch, install software, configure, backup, etc. Virtually no threat from desktop viruses as they are wiped out when the user logs off. Absolute configuration management. Reduced storage requirements.
So now, with the Citrix environment fully on tap, I can custom configure to any client request in about 5 minutes. Need desktops, done. Need software, done. Need a modification for your entire group, done.
You dont need Xenserver for Provisioning Server, Provisioning Server is its own component, it typically would be run on a server or maybe as a VM, or made highly available by having it run on a Server in HA with a vm. Provisioing server in conjunction with the Desktop Delivery controller (the broker) provide the desktops to users via their ICA client. Providioning server provides the disk image to the Virtual Machine that will run happily on a VMWare or XENServer host. You can provision many desktops with a single virtual disk streamed via the provisioning server (probably from your SAN infrastructure) in a Pooled configuration, or a single disk to a single Assigned host. The 1 to many is pretty cool as you may only have one single disk image for many many users. In a citrix world you would then stream APPS to the desktop and have a profile manager sitting on top, the disk is effectively read only so can't be destroyed by the user, if they stuff it up, they reboot and everything is as it was.
Yes and no, for true integration you need Provisioning server, XenSever and XenDesktop. you can use them in isolation but the maximum benifit is by useing all together
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
Contributing author for the upcoming book "[VMware vSphere and Virtual Infrastructure Security: Securing ESX and the Virtual Environment|http://my.safaribooksonline.com/9780136083214]”. Currently available on roughcuts
Just my two cents on the subject since I am currently evaluating XenDesktop and View 3.
I am leaning towards View 3 for a couple of reasons. Some of the reasons are actually based on products that are not even available yet from VMware. This is because a company with a vision for the future is something we admire. XenDesktop seems to be doing catch up. However I am not bashing Ctirix. They have done a good job coming up to speed with XenDesktop. This is just my impression of both offerings. Compare for yourself to make your own conclusions.
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!
rKelly, I dont want to sound too offensive.. but what you are saying is absolutley not true.
I have multiple customers, around 20, all of them are (well the majority) ESX customers, and all of them have chosen Citrix XenDesktop for the stability, speed, flexibility, cost, smartcard pass-through authentication ,features, TCO/ROI etc...who said that Citrix and Microsoft released unstable fixes? Wasn't it VMware that released a hotfixed that shutdown almost every ESX server in the world?
I am not saying that you are lying, but you are obvious not that skilled with XenDesktop, therefore it is quite bad that you give out recommendations without any facts.
For the rest of you guys, you don't need XenServer to run Citrix Provisioning Server.
Furthermore the tool, called XenDesktop Wizard is excellent to use for administrators to create desktops.
I would use, and use in most cases the XenDesktop broker as well! It has outformed View numerous of times, in different test scenarios. Furthermore, XenServer (if used) can handle the load better than vCenter, as vCenter manages around 700-800 VDI before getting overloaded...however XenServer doesnt have all the features as ESX has.. so.. there is a review to be done in this part as well.
My intention was not to recommend or endorse any company or product.
These are just my opinions and observations based what I have tested. As I stated in the beginning of my post "Download the trial versions of both products and see for yourself"
To be honest, we chose VMWare for the cost. Presently we are having a few issues that have made us reconsider our choice.
One issue you need to closely look at is in regards to using remote virtual desktops, if that is your intended use, and the interaction with the OS of the clients who will be connecting in. Page 18 of the View Manager Administration guide is a must see if you want to use remote clients through the view portal. Information I wish I had during our evaluation.
Just my .02
One of my vendors was giving me a lot of pressure to validate XD for my environment. I am PoCing View 3.1 right now. I'm not looking at XD for the following reasons:
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....
You can't upgrade firmware on a Blackberry via VMware View and Product Management @ VMware said its not until late 2010 that such a feature will exist. Their not even inclined to provide a workaround for this issue. They actually suggested I try a competeitiors product because it might actually work.
I was very pleased to see everybody had many thoughtful responses. Here’s the reason why I picked VMware View over Xen desktops:
We are already a VMware esx shop, so one vendor, ease of vendor management.
Much smaller learning curve for administrator – It literal takes under a day to set up VMware view 3.1.1 infrastructure.
VM runs smoother with very little memory – I only use about 384 MB ram for reach XP pro SP3 VM, and they run perfectly fine.
Well, some requirements are older than others.
My customers just went to see Taraditchi.. software based .....high performance stuff.. It took around 2min before everything just froze......the sh*t doesn't even work yet...
But as I can see it, you dont have any particular requirements.
Well, I agree that Taraditchi is new, but as you know when vmware develop something, it is usually very robust - all of their software are very reliable. So, I am very confident that the software implementation of the Taraditchi will be great.