Posts Tagged XenDesktop
I’m not big on “end of year” posts or predictions and lacking any other ideas, thought I’d write down some random thoughts about technology going through my head as this year draws to an end.
All Flash Array Dominance
I’m not buying the hype surrounding all flash array’s (AFA). Certainly there are legitimate use cases and they’ll be deployed more in the near future than they have in the past but the coming dominance of all flash array’s, I think, has been greatly exaggerated. It’s clear that the main problem these array’s are trying to solve is the extreme performance demands of some applications and I just think there are much better ways to solve this problem (e.g. local disk, convergence, local flash, RAM caching, etc) in most scenarios than purchasing disparate islands of SAN. And many of the things that make an AFA so “cool” (e.g. in-line dedupe, compression, no RAID, etc.) would be even cooler if the technology could be incorporated into a hybrid array. The AFA craze feels very much like the VDI craze to me, lots of hype about how “cool” the technology is but in reality a niche use case. Ironically, VDI is the main AFA use case.
The Emergence of Convergence
This year has seen a real spike in interest and deployment of converged storage/compute software and hardware and I’m extremely excited for this technology going into 2014. With VMware VSAN being GA in 2014, I expect that interest and deployment to rise to even greater heights. VSAN has some distinct strategic advantages over other converged models that should really make the competition for this space interesting. Name recognition alone is getting them a ton of interest. Being integrated with ESXi gives them an existing install base that already dominates the data center. In addition, it’s sheer simplicity and availability make it easy for anyone to try out. Pricing still hasn’t been announced so that will be the big thing to watch for in 2014 with this offering, that and any new enhancements that come with general availability. In addition to VSAN, EMC’s ScaleIO is another more ‘software-based’ rather than ‘appliance-based’ solution that is already GA that I’m looking forward to seeing more of in 2014. Along with VMware and EMC, Nutanix, Simplivity, Dell, HP, VCE, et al. all have varying “converged” solutions as well so this isn’t going away any time soon. With this new wave of convergence products and interest, expect all kinds of new tech buzzwords to develop! I fully expect and predict “Software Defined Convergence” will become mainstream by the end of the year!
Random convergence links:
Duncan Epping VSAN article collection – http://www.yellow-bricks.com/virtual-san/
Scott Lowe – http://wikibon.org/wiki/v/VMware_VSAN_vs_the_Simplicity_of_Hyperconvergence
Cormac Hogan looks at ScaleIO – http://cormachogan.com/2013/12/05/a-closer-look-at-emc-scaleio/
Good look at VSAN and All-Flash Array performance – http://blogs.vmware.com/performance/2013/11/vdi-benchmarking-using-view-planner-on-vmware-virtual-san-part-3.html
Chris Whal musing over VSAN architecture – http://wahlnetwork.com/2013/10/31/muse-vmwares-virtual-san-architecture/?utm_source=buffer&utm_medium=twitter&utm_campaign=Buffer&utm_content=buffer59ec6
The Fall of XenServer
As any reader of this blog knows, I used to be a huge proponent of XenServer. However, things have really gone downhill after 5.6 in terms of product reliability. So much so that I really have a hard time recommending it at all anymore. ESXi was always at the top of my list but XenServer remained a solid #2. Now it’s a distant 3rd in my mind behind Hyper-V. I’ll grant that there are many environments successfully and reliably running XenServer, I have built quite a few myself, but far too many suffer from bluescreen server crashes and general unreliability to be acceptable in many enterprises. The product has even had to be pulled from the site to prevent people from downloading it while bugs were fixed. I’ve never seen so many others express like sentiments about this product as I have seen this past year.
Random CTP frustration with XenServer:
Random stuff I’m reading
Colin Lynch has always had a great UCS blog and his two latest posts are great examples. Best UCS blog out there, in my opinion:
“UCS Manager 2.2 (El Capitan) Released”
“Under the Cisco UCS Kimono”
I definitely agree with Andre here! Too many customers don’t take advantage of CBRC and it’s so easy to enable:
“Here is why your Horizon View deployment is not performing to it’s max!”
Great collection of links and information on using HPs Moonshot ConvergedSystem 100 with XenDesktop by Dane Young:
“Citrix XenDesktop 7.1 HDX 3D Pro on HP’s Moonshot ConvergedSystem 100 for Hosted Desktop Infrastructure (HDI)”
In the end, this post ends up being an “end of year” post with a few predictions. Alas, at least I got the “random” part right…
Both VMware View and Citrix XenDesktop require permissions within vCenter to provision and manage virtual desktops. VMware and Citrix both have documentation on the exact permissions required for this user account. Creating a service account with the minimal amount of permissions necessary, however, can be cumbersome and as a result, many businesses have elected to just create an account with “Administrator” permissions within vCenter. While much easier to create, this configuration will not win you any points with a security auditor.
To make this process a bit easier I’ve created a couple quick scripts, one for XenDesktop and one for View, that create “roles” with the minimal permissions necessary for each VDI platform. For XenDesktop, the script will create a role called “Citrix XenDesktop” with the privileges specified here. For View, that script will create a role called “VMware View” with privileges specified on page 87-88 here. VMware mentions creating three roles in its documentation, but I just created one with all the permissions necessary for View Manager, Composer and local mode. Removing the “local mode” permissions is easy enough in the script if you don’t think you’re going to use it and the vast majority of View deployments I’ve seen use Composer, so I didn’t see it as necessary to separate that into a different role either. You’ll also note that I used the privilege “Id” instead of “Name”. The problem I ran into there is that “Name” is not unique within privileges (e.g. there is a “Power On” under both “vApp” and “Virtual Machine”) while “Id” is unique. So, for consistencies sake I just used “Id” to reference every privilege. The only thing that will need to be modified in these scripts is to make sure to enter your vCenter IP/Hostname after “Connect-VIServer”.
Of course, these scripts could be expanded to automate more tasks, such as creating a user account and giving access to specific folders or clusters, etc., but I will let all the PowerCLI gurus out there handle that. 🙂 Really, the only goal of these scripts is to automate the particular task that most people skip due to its tedious nature. Feel free to download, critique and expand as necessary.
This version has an updated look-and-feel from the XenReference card I created for XenApp. I used the same methods to create this card as I did the last one. The XenDesktop 5 Administration exam prep guide was used as a basic template for the content that went into the card but with minor variations. This is why the “XenServer” section is so short in this card, there was very little requirements listed in the prep guide. The purpose of this card is to be a quick reference guide for basic XenDesktop 5 information and a useful tool for studying for the “XenDesktop 5 Administration″ (1Y0-A19) exam. Feel free to comment with any suggestions on improving this document.
Stay tuned for the XenReference for XenServer card in the coming weeks…
Citrix Provisioning Server (PVS) has been a vital component in the Citrix technology stack for years. Allowing for the rapid provisioning of machines through OS streaming, it has been the bedrock provisioning mechanism for XenDesktop and is also used in provisioning XenApp servers and streaming to physical endpoints. Even though PVS provides all these benefits and has been so integral to various Citrix technologies, its days are clearly numbered. Fundamentally, streaming an OS over the network is inferior to provisioning machines and delivering the OS locally in some way. As an example, technologies like Machine Creation Services (MCS) can be used to provision an OS without the additional streaming component. And while the initial scalability numbers for MCS were lower than PVS and is currently limited to the XenDesktop technology stack, MCS is new and its scalability estimates are improving all the time and there’s no reason to think it can’t or won’t be integrated with other Citrix products. Indeed, there has been talk for years of merging XenDesktop itself with other Citrix products. So, what other possible reasons will there be for holding onto PVS in the future?
- “PVS can use the caching capabilities inherent to the local OS, this reduces IOPS”
When a target devices boots up or accesses portions of the base image, those portions of the OS are then cached in RAM on the PVS server. Subsequent attempts by additional target devices to access those portions of the OS will be read from RAM, thereby reducing the amount of IOPS required on the backend storage. Since IOPS are one of the biggest concerns for VDI deployments, this has been a major selling point for PVS. However, with the rise in popularity of VDI over the past couple of years, storage vendors have really focused on optimizing their array’s for IOPS, with many having terabytes of caching capabilities in them. So, if you now have enough RAM to cache at the storage level, is there really much benefit in being able to cache at the OS level? In addition to that, you have emerging technologies like Intellicache and whole distributed storage models being developed for VDI that should make IOPS less of a concern in the future.
- “MCS will never be able to deliver an OS to a physical endpoint”
This is true. You will never be able to use a locally delivered OS solution for remote endpoints. However, what is the purpose of streaming an OS to physical endpoints? Two use-cases come to mind. The first involves streaming the OS to desktop PC’s outside the datacenter. Companies usually choose this option as a first step into the VDI world. It’s cheap because it uses already existing hardware and it gives you the single-image management and security benefits of VDI without purchasing thin-clients, hypervisors and backend storage arrays. But the important thing to point out here is that this is usually just a stepping stone towards much more robust VDI rollouts. Once their currently functioning PC’s reach end of life, these companies start to replace them with thin-clients and are more willing to invest in hypervisors and backend storage rather than a hardware refresh, thus eleminating the need to stream the OS over the network. The use-case for this in the future will become extremely “niche” as companies move away from purchasing fat-clients as a standard. The second use-case involves streaming to blade PC’s. This is usually done when high performance desktops are a “must”. Like the previous use-case we examined though, there is limited need for this today and as hypervisors continue to advance, there will soon be very little reason, if any, why a desktop cannot be run as a virtual machine and still expect optimal performance.
Now don’t get me wrong, PVS today is still a great solution and should be the main provisioning mechanism for most XenDesktop deployments. For the reasons listed above however, the next few years should see PVS use-cases diminishing rapidly. MCS or some future locally delivered OS solution will take it’s place.