Virtualising Citrix XenApp is a Waste of Time and Effort

Tags: ,

6 Responses to Virtualising Citrix XenApp is a Waste of Time and Effort

  1. Mr. X
    November 8, 2010 at 11:34 AM

    I strongly recommend reading the “Virtual Reality Check – Phase II version 2.0″ white paper you mention at http://www.projectvrc.nl/index.php?option=com_docman&task=cat_view&gid=39&Itemid= (free registration required). It points out a number of things regarding the virtualization of XenApp:

    - It definitely makes sense to virtualize Terminal Server/XenApp, but you will gain more by virtualizing the 32-bit versions than the 64-bit versions.

    - The Intel Nehalem processor architecture is a game-changer regarding the processing power it brings to virtualization.

    - On a Intel Nehalem host with 16 logical processors the optimal configuration is now 4VMs with 4vCPUs, instead of 8VMs with 2vCPUs.

    I definitely recommend reading the paper. vSphere, XenServer, and Hyper-V are all discussed.

  2. Mark
    November 19, 2010 at 5:59 AM

    ” it is possible to move a server instance to different hardware in case of failure”

    The ability to move guests around in the event of failures is often touted as an advantage of virtualisation. However in reality this is not always the case. If a host has gone down, how do you get the guests moved off? They’ve gone down with the host.

  3. November 19, 2010 at 7:28 AM

    Mark,

    Sure, its not magic – if you’ve suffered a catastrophic failure and all lights are out, you’re sunk in the same boat as a physical server. There are failures – be it with components or process usage – where being virtualised affords you the ability to move instances. But you’ve a valid point.

  4. November 19, 2010 at 8:12 AM

    Mark,

    The ability to move guests around requires the use of shared storage. Because I am using shared storage amongst a cluster of my virtualization hosts, other hosts have access to the same storage. There is no need to ‘move’ the guests off the shared storage but to automatically boot the workloads on a new host (High Availability solutions). If you can ‘predict’ a host failure due to hardware monitoring then you can also vMotion/LiveMigrate the VMs before the failure.

    It is quite easy to “get the guests moved off”.

    Edward L. Haletky

  5. January 8, 2013 at 4:39 AM

    Hi Mark,

    Stumbled upon this article while searhcing for something else. Think youŕe missing one additional point when going for a PV server. You also add tons of flexibility. If you’re working in an organization where use cases are shifting and it’s implicating a different use of resources, a virtualization layer also provides a lot of flexibility to differ in the use of your resources. Or scale up / down when needed. For instance, you could assign blades to XenApp, but quickly repurpose them for VDI or something else. Project VRC has some nice takes on this perspective indeed, maybe a good time to rethink the article?

  6. January 8, 2013 at 10:47 AM

    Michael,

    Thanks for taking to the time to contribute. You are indeed correct – virtualisation gives the option of flexibility (e.g. moving underutilised servers to a common host for example). Obviously you’d want some control in there as reference architectures typically advise against sharing RDS/TS loads: but that in itself is controllable. XenApp has expanded on its features and services since 2010 that can make better use of this features, and likely will do so even more as part of Avalon.

    Indeed, Mark discusses limitations here due to shared storage, which were true, but then modern hypervisors can give live migration capabilities *without* sharing storage.

    You’ve also (perhaps) the consideration of utilising cloud based services from amazon/azure/rackspace et al.

    2010.. yes indeed maybe time for an update :)

Leave a Reply

Your email address will not be published. Required fields are marked *

Please Share

Featured Solutions