The Future of XenApp and XenDesktop Image Management – A Utopian Viewpoint

GIFSec.com

 

 

 

 

 

 

 

 

Over the past year or so, I have witnessed a number of heated debates around the future of image management for XenApp and XenDesktop. On one side we have the Provisioning Services (PVS) fan-boys and on the other we have the Machine Creation Services (MCS) gang. The PVS vs MCS topic has been beaten to death in the past and here are some of my favorite posts/debates:

I totally enjoy a heated debate by passionate individuals who truly believe what they preach With regards to Image Management both sides have their merits and there is no clear winner. The PVS camp is worried that eventually the technology will be deprecated in favor of MCS. Their argument (fully justified) is that 80-90% of all large scale XenApp and XenDesktop deployments leverage PVS, and MCS lacks the scalability and version management capabilities of PVS, not to mention the inability to support physical bare metal workloads. With the introduction of MCS for server based workloads in XenApp/XenDesktop 7.x, we have another camp that prefers Machine Creation Services mainly because of the simplicity of the solution and do not want to invest in additional infrastructure required for PVS and don’t want to deal with the added complexity of the PVS infrastructure. Before we delve into what the future could look like, lets break down the pro’s and con’s of each solution.

PROVISIONING SERVICES

  • Whats hot?
    • Highly Scalable
    • In built Version Management Capabilities
    • IOPS efficiency and reduced storage requirements.
    • Supports both physical and virtual workloads.
  • Whats not?
    • Additional Infrastructure
    • Complexity related to network configuration
    • Difficult to troubleshoot
    • Designed primarily for non persistent read only workloads

MACHINE CREATION SERVICES

  • Whats hot?
    • Simplicity
    • Technology built into core product and no additional infrastructure required.
    • Better suited for cloud provisioning.
    • Ideal for both persistent and non persistent workloads
  • Whats not?
    • Scalability not upto par with PVS, however has been tested upto 10000 endpoints.
    • Images have to be copied onto every hypervisor which increases time to rollout updates.
    • Storage requirements higher than PVS. Higher IOPS hit on the storage back-end (although not a big difference)
    • No native version management capabilities.
    • Does not support physical workloads

Clearly, both solutions have their strengths and weaknesses and there is no clear winner. So what should the future image management solution look like? I believe the future solution has to be a hybrid solution that combines the merits of both PVS and MCS. Here are some of the key elements that I would expect in an ideal scenario:

  • Most customers are currently looking at the public cloud or have already starting using the public cloud in some limited fashion. With that established, it is fair to assume that cloud providers are not going to like the network complexity associated with a PVS infrastructure and might not support it. So the solution would fundamentally have to be based on the MCS platform.
  • The solution needs to have some form of version management capability similar to what we have in PVS today.
  • Should support both persistent and non persistent workloads
  • High availability and disaster recovery should be addressed and simplified as much as possible.
  • Scalability of the solution has to be similar to what the users are used to with PVS.
  • No additional infrastructure should be required and the solution needs to be integrated within the core product. Administration should be possible from within Studio or some other central console
  • Troubleshooting should be simplified.
  • The solution should minimize storage requirements and should be IOPS efficient. There should not be a requirement to copy images onto every hypervisor supporting the virtual workloads.
  • Ideally the solution should be able support image management for physical machines as well, although I dont see this as being a key requirement 5 years from now.
  • Rapid provisioning and tear down of workloads.

While the above list seems daunting, I don’t think its far fetched to expect a solution in the future that addresses a majority of the features listed above. Unlike some, I am not in either the PVS or MCS camp. There are use cases for both solutions, which is why a hybrid solution would make the most sense. To all those out there who think PVS or MCS is the be-all end-all, let me quote George Bernard Shaw: “Progress is impossible without change, and those who cannot change their minds, cannot change anything” I would love to hear your thoughts, especially with regards to what the future of image management would look like. I l look forward to an engaging conversation!

5 Comments on The Future of XenApp and XenDesktop Image Management – A Utopian Viewpoint

  1. Andrew Morgan
    May 16, 2014 at 2:13 pm (3 years ago)

    Agreed on all points, two missing items on the utopian merge:

    1: version control and dev / test / production built in
    2: Image inventory, a historical view on how the image came to be and what has changed between releases. I covered the need for this here: http://andrewmorgan.ie/2012/06/01/citrix-provisioning-server-questionable-assumptions-why-i-dont-trust-people/

    Those who love PVS, have learned to overcome the typical gotcha’s associated with your first installations of PVS (blue screens, oddities, etc).

    For new comers, MCS is certainly the simplest approach but you covered off some of the current short falls of MCS well.

    I’m neither for or against either technology, for now both have a sweet spot. I would however love to see a merge of functionality at some point, or some serious love given to PVS.

    A

    Google Chrome 34.0.1847.137Windows
    Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36
  2. George
    May 16, 2014 at 2:22 pm (3 years ago)

    Thanks for the feedback Andrew. Glad you mentioned version management. I included that under PVS and forgot to port it over to Utopia 🙂

    Google Chrome 34.0.1847.120Google Chrome OS x64
    Mozilla/5.0 (X11; CrOS x86_64 5500.100.6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.120 Safari/537.36
  3. Swarna
    May 16, 2014 at 9:42 pm (3 years ago)

    Hi George
    Excellent blog post. Thanks for sharing it; I learned something new today 🙂

    I would love to see a follow-up blog post on the use cases you see more often, the criteria that the solution would need to meet for those use cases and a second follow-on post for best practices/gotchas. There might be blog posts written already on those topics, but would love to hear from your experiences.

    Thanks,
    Swarna.

    Google Chrome 34.0.1847.131Mac OS X 10.9.2
    Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36
  4. Paul Stansel
    May 21, 2014 at 4:30 am (3 years ago)

    Great post. One other driver I would mention for PVS however is cost. MCS still relies on storage as part of the design and with PVS we can cache to RAM. Combine UCS 12 core blades and 384GB of RAM using just 16GB sticks and you can easily scale 9000 concurrent users across 32 blades with zero storage needed. The cost per user is ridiculously cheap and in large organizations not having to involve your storage guys is often another benefit 😉

    Google Chrome 34.0.1847.114Android 4.4.2
    Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.114 Mobile Safari/537.36

Leave a Reply