VMware's VDI solution makes virtual desktops real, but not particularly easy to manage
Everyone in the pool
Once the core components of View are installed and running, at least one desktop pool needs to be built to support the users. The primary source of the desktop pool is a single VM that's built like any other Windows VM. The base OS is installed, then patches and service packs, followed by applications, and so forth until the VM is completely prepped and ready for a user. This source VM is then joined to the domain, and the VMware Agent is installed. The Agent is a small piece of code that runs on every View desktop and permits interaction with the View server.
Additionally, all the Microsoft Sysprep code must be installed on the vCenter Server to facilitate the automatic building of new desktops from the single image. This is the code that permits Windows machines to be cloned and run on the same network as unique entities, with various unique parameters such as the SID (security identifier) modified during the cloning process.
Once all those pieces are in place, the source VM is shut down, and a snapshot is taken of the system. This snapshot forms the basis of all subsequent desktop VMs.
Back in the VMware View Web interface, a desktop pool can now be created. Desktop pools can be built in several ways. The most common is likely to be linked clones. This method is used by View to allow for a large number of desktops without requiring that each desktop have a separate base disk image. Even a small desktop VM might require a 10GB disk, and creating a pool with 100 desktops would then require 1TB in storage. However, using linked clones, the total storage requirements of 100 users will only require a fraction of that space. View manages this trick by using the snapshot of the source VM as a baseline and creating links to that baseline for each VM. Thus, each desktop runs as an extension to the primary, with any and all changes made to the VM during normal use stored as a delta to the original. Also, View offers the option of creating a user disk with a fixed limit for users to store files separately from the linked clone.
In production, you'll want to use Microsoft Active Directory Group Policy to limit or prevent users from storing anything locally to the VM or to the user disk by redirecting My Documents and other directories to file shares served elsewhere. This is very similar to a normal Microsoft Terminal Services or Citrix installation.
The pool of desktop VMs can also be created with support for persistent or non-persistent desktop sessions. The difference here is whether or not a user is tied to a specific desktop instance, or if they simply log in to the next available desktop. In a call-center scenario, non-persistent desktops are probably the best idea, since users likely won't be using more than one or two applications, nor will they need a place to park their personal files.
Otherwise, persistent desktops are likely to be the best bet. This assigns a specific desktop to a specific user during their initial log-in, and they will always be connected to that desktop for each subsequent log-in, much like they would with a physical desktop beneath their desk.
This weekend's Windows 10 upgrade has users angry, and it's unclear if the ploy will continue
Here’s the best of the best for Windows 10. Sometimes good things come in free packages
Speaking at the O'Reilly Fluent conference, Eich also endorsed the Service Workers mobile app...
Four rich, pretrained machine learning APIs bring the smarts behind Google to your apps
For organizations considering cloud migration, here are nine proactive steps that companies can take to...
The July 29 deadline looms. Here's what you need to know to reserve your free upgrade, even if you're...
The newest version of OpenBSD closes potential security loopholes -- such as its Linux compatibility...