You said that the I/O is offloaded to another server. How does this work with relation to speed? Are you limited to the TCP link between the VM and the Unidesk server?

There are 2 parts to the I/O story with Unidesk:

1. Layer replication: Unidesk uses TCP based replication of layers between CachePoints. When IT updates an existing shared layer or creates a new layer on the Master CachePoint, this change is replicated to the other CachePoints, as needed, via TCP. Unidesk automatically copies the deltas of the updated layer or the new layer over the network to the Desktop CachePoints only if you assign the layers to desktops hosted by that CachePoint. This can work over the slowest of links – a Desktop CachePoint won’t use a layer for a desktop until the entire layer has been cached.
2. Becoming the C: drive: Each Desktop CachePoint basically becomes the C: drive for the virtual desktops it hosts. The file I/O from the virtual desktop is directed at boot time to the Unidesk CachePoint VM and this is where the layer sharing happens. If there are 50 desktops hosted on a CachePoint and they’ve all been assigned the same layers, all 50 desktop VMs access the same layers and get their I/O from the same CachePoint VM. All I/O goes over the vSwitch on the local host, so there’s no issue there. I/O performance is more dependent on the type of storage you’re accessing from the CachePoint. This is where Unidesk’s ability to leverage centralized storage or local (high-performance) storage can help you choose the right cost/performance/availability mix.