So… with vmware View, you have a connection broker that connects to vCenter that connects to the ESX hosts using vSphere API which then tells whichever ESX host to build whichever linked-clones from the replica-vm to which ever destination datastore they are supposed to be on… right? :)

Well… with Citrix XenDesktop Machine Creation Services (MCS) its a little-bit different… well a lotta-bit different.

With MCS, you have a connection broker (DDC) that connects to the XenServer Pool Master using XenServer API which copies the replica-vm to which ever destination datastore the linked clones are supposed to live on, then builds whichever linked-clones from there on the same datacenter… right? :)

The problem with that, is by default; you only have 4 vCPU’s and 700MB of memory to process all of that I/O :(

First, in a XenServer environment, we do not have an API plugin that allows the hypervisor to be storage aware (VAAI). This plugin allows the hypervisor to offload disk execution to the storage layer and no need to bring it into the kernel as massive IOP’s. With VMware, the hypervisor will communicate to the storage to request blocks to be copied and will be hands off till the blocks are copied.

With XenServer, the copying is done with the hypervisor. Every block that needs to be copied flow into the hypervisor and out to the storage.

Second, with XenServer, one of the servers is the pool master. This box is the only server that manages the copying. All I/O during the publishing is through this single box. As you can see below, this is a screen shot of the XenServer-02 (pool master). The wait state is at 48%, swap usage was at 25% and buffer was 10x normal operation time. The server is maxed out and is buffering and swapping. Wait state is way to high.

All this, confirmed with Citrix :(

Their answer, add more sites (duplicate storage needed); or switch to Citrix Provisioning Services.

That being said, the formula used to determine the amount of storage needed with Citrix Machine Creation Servies is as follows:

Gold Image+(# of catalogs*(# of LUNs*Gold Image))+(# of Images*Image-Size)