VMware View: Transfer Server Functions

Summary 
I thought I'd put together some notes on the VMware View Transfer server as there doesn't seem to be to much information easily available on this feature of View.  Essentially it is used to Check-Out and Check-In virtual desktops, allowing them to be used in Local-mode (Offline). I want to show you in a bit more depth what happens when you Check-in, Check-out, Replicate and Rollback your virtual desktops.

Transfer servers are installed as virtual servers onto your virtual environment. You may need more than one transfer server depending on how many users you are planning to allow to take their virtual desktops offline. Each transfer server can support a maximum of 20 concurrent Check-In/Out processes. So if you may encounter higher concurrency levels you'll need to add extra transfer servers to suit.

Your transfer server/s are added into View Administrator where view configures the virtual machines with 4 SCSI controllers and sets DRS to manual to stop the virtual server from moving hosts. If at some point you need to move the virtual server to another host, you will need to put the transport server into Maintenance Mode to do this.

Next you assign a transfer server repository. This can be either a local disk share on the transfer server or a network share. If you plan on having more than one transfer server in your environment you will need to use a network share for the repository.
Transfer Server
Once you have your transfer servers installed and added into your View environment you next need to publish your view composer base image as a package to the transfer server repository. This packaging process takes a copy of your Linked-Clone base image, encrypts it, and places it onto the transport server repository. These packages can also be compressed to streamline downloads to local desktops. The transport server is now ready for users to check-out their desktops.

Check-Out
So what happens when a user "Checks-Out" their view desktop? A copy of the base image is downloaded from the transport server repository and placed onto the local desktop hard drive. Alongside the base image a copy of your Linked-Clone desktop is download from the datacenter. The desktop consists of the Linked Clone OS Delta disk and a view composer persistent disk. It is possible to copy the packaged base image to a mass storage device. This will enable you to copy the base image to your laptop via usb/firewire etc, bypassing slow network transfer rates. 

Transfer Server Check-Out
In the datacenter Linked-Clones desktops share access to a base image. When you run a linked-clone desktop in local mode, a copy of the base image must reside with the linked-clone desktop on the local computer.

Once all of these files have successfully been copied down to the local disk, the delta disk and persistant disk stored on the datastore are then locked to prevent any changes made them whilst the desktop is Checked-Out. The user is now able to disconnect their laptop from company the LAN and continue to use their virtual desktop wherever they wish.

Replication

Transfer Server Replication

When a user makes changes to a desktop that is in Local-mode, as with all Linked-Clones, the changes are stored in either the OS delta disk or the persistent disk. The base image stays the same.

To synchronize these changes to the desktop stored in the datacenter the offline desktop needs to be replicate the user-generated changes. Replication can either be forced by a policy or user initialized. Of course the laptop in Local-Mode has to be connected to the LAN/WAN for Replication to take place.

Check-in
This process is very simular to the Replication function. When a Check-In is performed the delta disk and the persistant disk changes are uploaded from the laptop to the datastore and the disk locks are removed. Future View client connections are directed via the connection broker to the desktop stored in vCenter until the desktop is Checked-Out again. 

Rollback
If a user looses their laptop or the hard disk in the laptop becomes corrupt, the view administer can run a Rollback operation which allows the desktop to be Checked-Out again to another computer.

During the Roll-Back process, the local desktop stored on the laptop is discarded and the locks on the disks stored in the datastore are released. Future View client connections are directed via the connection broker to the desktop stored in vCenter until the desktop is Checked-Out again. The Diagram below shows a Roll-Back then a Check-Out after the image on the local disk was corrupted.

Transfer Server Roll-Back

Optimize data transfer
To reduce the amount of data that is transferred between the local computer and the datacenter VMware have given you the option to use deduplication and compression. Of course there are overheads to using see features, so you will have to weigh up the pros and cons to see if they would help or hinder your environment.

If I have missed anything, please drop me a comment a I'll make sure I add it in.

Sources: