Problem solve Get help with specific problems with your technologies, process and projects.

The downsides of VMware View Local Mode may outweigh its benefits

Local Mode in View 4.5 provides offline support for virtual desktops but poses challenges that IT pros should consider before deeming it the answer to disconnected VDI.

VMware re-engineered its offline desktop feature in View 4.5, incorporating several improvements that broaden the use case for virtual desktops, but the Local Mode feature has some drawbacks that may outweigh the benefits of using disconnected VDI.

The idea behind Local Mode is to let VMware View users run virtual desktops while offline, giving them portability and the ability to run applications even when they aren't connected to enterprise servers. That's ideal for supporting employees who travel with laptops, work with multiple PCs at different locations or do not have persistent access to a broadband connection.

VMware also built in the ability to manage virtual desktops while in Local Mode, so the management benefits of virtual desktops aren't lost when desktops are offline. For example, the same policies and templates used for VMware View 4.5 sessions control Local Mode sessions. So when a user "checks out" a virtual desktop for Local Mode use, defined policies travel with the Local Mode session. Administrators can control how a Local Mode session operates by shutting off USB ports, limiting software changes, enforcing security policies and so on.

Local Mode downsides
Local Mode seems like a good idea, but it changes the virtual desktop infrastructure (VDI) formula and poses some unique challenges that you must consider before committing to it for disconnected VDI. To understand those changes and challenges, let's look at how Local Mode works.

You'd need to take a few steps to enable end users to access Local Mode. First, the users' PCs must have the VMware View 4.5 client with Local Mode installed and enabled, and they must have the appropriate rights to access a Local Mode session assigned to them by the administrator.

During a VMware View session, the user can choose to run his virtual desktop locally. The virtual desktop session is "checked out" and copied to the local machine, where the user is able to run the virtual machine. When the user is done with the Local Mode session, he "checks in" the virtual machine, which is then moved back into the centralized VMware View environment. Any changes made during Local Mode operation are synched back to the original virtual desktop, so no data is lost.

For many users, running a virtual desktop locally is very appealing, because odds are the desktop runs faster, is more reliable and is less susceptible to interruptions because of network problems. However, if users do not regularly check in their desktops, they won't be properly backed up and may not get automatic software updates or new applications.

To avoid that problem, administrators have to enforce policies that require regular desktop check-ins, and they also have to manage and monitor how virtual desktops are consumed. That adds to the overall management burden of running VDI.

Local Mode also requires that a hypervisor be running on the client device. That in itself makes Local Mode much like VMware Workstation (a local, Type 2 hypervisor for virtualization) instead of a VDI-type implementation, which requires very little local processing power to function. So to support Local Mode, a user's physical PC must have adequate processing power, memory and storage to support the Type 2 client hypervisor.

User PCs must have a recent high-performance processor and enough RAM to run the host operating system, the hypervisor, and the guest OS and desktop, along with enough storage to support the virtual hard disk. In many cases, the cost for the PC, hardware and operating system negates any savings offered by a virtual desktop with Local Mode.

That may leave you wondering, "Why run a virtual desktop locally, when the physical desktop offers better performance?" The answer lies within the savings offered by the deployment and management capabilities offered by VMware View. Nevertheless, it is a question that will arise during budget time.

Corporate application access is another problem for Local Mode. Many business apps, such as customer relationship management and corporate databases, aren't available when users aren't on the corporate network. So, even though users can access their desktops while disconnected, they may not be able to access the applications they need to do their jobs. This may require a complete re-engineering of how remote users access business apps.

So, while Local Mode meets the need for desktop backups, centralized management and enterprise desktop portability, it also comes at a price -- namely in hardware and management burdens. The trick is to be aware of those limitations and not to expect Local Mode to solve a number of VDI-related problems. When used judiciously, Local Mode may prove to be a life-saver for administrators who need to support disconnected users and overcome virtual desktop performance problems. It all comes down to knowledge, planning and management. Local Mode may prove to be successful, albeit niche, product.

Frank Ohlhorst is an IT journalist who has also served as a network administrator and applications programmer before forming his own computer consulting firm.

Dig Deeper on VMware virtual desktop software

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

One key benefit of Local Mode that I want to make sure is communicated is the built in backup that occurs each time a user is able to communicate with the VMware View infrastructure. It performs a block by block delta sync to whatever has changed to the checked out VM. This is important to understand since getting a user back up and running with data that was lasted synced is as simple as getting them to a device that has the ability to connect to the hosted desktop infrastructure. At that point, they can choose to check out the desktop again or leave it running on the hosted infrastructure.

*Disclaimer, I work for VMware