Enabling Local Mode - VMware View: Chapter 11

Enabling Local Mode in VMware View

Very Important (Yes I mean VERY important. You should read this. You really should!)

Local Mode uses a new role called the Transfer Server that is used to speed up the download and upload process. On Windows 2008 R2, VMware ONLY support the BusLogic or LSI Logic controller, unfortunately Windows 2008 R2 defaults to the LSI Logic SAS controller. Sadly, there is no safe or supported method to changing this if you have this in your default template for Windows 2008 R2. Even adding in second disk on different SCSI controller doesn’t work, and renders the VM unbootable. This caused me to install Windows 2008 R2 all over again. I wasn’t best pleased I could tell. You see I have better things to do with my life and time, than install Windows. That’s why I got into VMware.

Finally, unlike the other server roles that make up View – the transfer server MUST be installed into a virtual machine running under vSphere. Well, at least they got that part right, eh?

The Local Mode feature allows a user to carry on using their virtual desktop even when they are not connected to the network. Users now represent an increasingly mobile population who expect access to corporate services on the move – and not all of those services can currently be provided by handheld devices such as smartphones and PDAs. A Local Mode desktop is enabled by installing a special client onto the user’s computer, and installing the Transfer Server component on the View back-end. The Transfer Server is a new component in View. Previously, offline desktops (as they were then called) were managed by the Connection Server. VMware have developed a more efficient Transfer Server role to improve the synchronization process. The main engine of the Transfer Server is the Tomcat web service. The Transfer Server is designed to run solely and only in a virtual machine, and it is possible to have more than one. All Transfer Servers connect to a centralized repository of virtual desktops (the Image Library) that have been checked out for Local Mode use. In a simple configuration its possible to store the checked out offline desktops inside a second virtual disks inside the Transfer Server rather than on an external file server on the network.

Local Mode desktops work by first downloading the user’s entire virtual desktop to their local computer in a process called “Checking Out”. This initial download can take some time, so it’s best done from the LAN in this first instance. The Local Mode desktops essentially then become a synchronization feature that you might have come across in other technologies, with just the differences synchronized between the user’s local computer and the View environment. When the user is disconnected from the network - say on a longhaul flight - the locally-cached offline desktop is powered on and available. While the user works with the offline desktop, changes accrue in a snapshot delta file. This allows for further functionality such as:

  • Check In – when the user returns the corporate network the user Checks In the virtual desktop, and any changes (just the differences) are synchronized back to the vSphere4 environment
  • Rollback – when the user decides to return the virtual desktop to its state before it is Checked In
  • Backup to Server – when the user decides that the changes should neither be Checked In nor Rolled back but maintained, until such time as they choose to Check In or Rollback their virtual desktop

These privileges can be taken away from the end user by using the View administration web pages and adjusting the policy options. During the transfer process the transfer server mounts the virtual disks used by the virtual desktop to additional SCSI controllers inside the VM. This speeds up the transfer process. Any VM can only have a maximum of 4 controllers, with 15 slots. This allows for a maximum of 60 transfers at any one time. As such the ESX host that the transfer server executes on must have access to all the datastores the virtual desktops reside on in order for the mounting process to be successful. The transfer process itself is carried out on a non-encrypted channel, as virtual desktops might contain sensitive data, you might wish to consider ways of encrypting the TCP sessions it generates or restricting transfer to LAN use only. Finally, once added to the View configuration the transfer server is isolated from DRS and set to be disabled for DRS. Watch out for maintenance modes that might “hang” at 2% because transfer server must be manually moved by the administrator of vCenter.

Want to read more of this guide?

Download the full “Administering VMware View 4.5” Guide (21 Chapters). The full guide contains additional step-by-step instructions and screen shots in each chapter.

Dig Deeper on VMware Resources

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.