Implementing VDI for Anywhere Access

In this article, we'll tell you how to deploy VDI using VMware. VDI, to reiterate briefly, places a 'virtualized' desktop on a remote central server, instead of the local storage of a physical desktop PC. It's accessed using a client, which in case of VMware is called VMware View. The client doesn't stress the resources of the local machine, but accesses the desktop from remote server. A user will feel as if the desktop is running locally (if it's on a LAN). All the user's work will be saved on the remote server.

As a result, the same user can run multiple virtual desktops on the same machine, without compromising on performance. As a result, the local machine doesn't need to be very powerful, and won't require an hardware upgrade for a long time. In this sort of virtualization, the VDI solution is running on a central server, and all desktops are hosted on a central storage. You provide each user with a unique ID and password to access the desktop. Another type of VDI implementation involves storing the virtual desktop image on the local desktop itself. It doesn't connect to a central server. If it's connected to a network, synchronizations takes place. The drawback of this setup is that it relies on the local hardware resources. We'll only concentrate on the first type of VDI implementation in this article.

Requirements:

We used the following for our VDI implementation:

Hardware Servers: An Intel Xeon E7-4870 based server with 40 cores and 128 GB RAM for VDI; An Intel Dunnington based 24-core server with 8 GB RAM for Controller.

Storage: EMC's VNXE 31100 Unified Storage (reviewed in the last issue).

VDI Software: VMware ESXi Server, VMWare vSphere, VMWare View Connection Manager, VMWare View client

OS: Microsoft Windows 2008 Standard Server with the latest updates, running ADS, DHCP, and DNS services.

The Setup

We used VMware ESXi server on 2 Intel based servers, as described above. These had 4 Quad core Xeon processors with 256 GB RAM connected in a cluster mode for load balancing. We then took the Dell PowerEdge Server and made it the controller. The controller server runs VMware vSphere Client on top of Windows 2008 Standard Server. Note that you have to assign a static IP to the controller before installing the VMware vSphere Client. The storage box was fine-tuned to host all the VMs that we created, using the VMFS file system. We connected the storage box over iSCSI interface @ 1Gbps on an isolated network. We created a VMFS volume of 500 GB and dedicated it to the virtual infrastructure as a storage pool.

VMware View

For this, you need a server running Windows 2008 Server connected as a part of your domain. On this, you need to login as Administrator of your running domain controller. Once logged in, you need to install VMware View Connection Server. It takes some time to get installed. Once done, it will install View LDAP as the data repository for all View Manager configurations using AD Application Mode as its data store. After that, you would be asked to restart the server. VMware View Connection Server acts as an interface between the client machines and your VMware infrastructure where you will host your VMs.

Setting up of VMs

Next you have to install the OS on the above created VM inside the virtual infrastructure and these VMs will be used as VDI. You can make a bare bone base and then replicate it as clones whenever required. In order to access the infrastructure, you can use any machine provided it is on the network and VMware vSphere client is installed on it. Connect it to the infrastructure using the IP address or hostname of the controller machine and you will be asked to feed in the username and the password. You have to enter the username and password of the controller machines only. Once opened, you have to add the server on which you have to host the virtual machines, which are actually the ESX servers. Since the storage is already configured, we assigned 500 GB to the server. Now the next step is to create the virtual machines under the server. This process is the usual process of creating virtual machine in VMware. We created two virtual machines with Windows 7 installed on them. After this, virtual machines are up and running. Now we mapped the username of the clients in the domain server, so that they can access it remotely.

Note: Once you are through installing Windows OS on the VMs, you need to install VMware tools on all the running VMs, otherwise accessing VM on the VMware vSphere would be too slow. Install VMware View Connection Server on any Windows Server 2008 32-bit or 64bit machine (physical or virtual) which does not have Terminal Services installed.

Configuring VDI on VMware View

connection Server

Now it's time to configure the above created VMs as a VDI and map those VMs to individual user in the active directory. For this, you will get a name VMware view connection manager. This will open a web based interface asking username and password of your domain (active directory). Now, login with administrative user credentials of your domain on this view server. Once logged in successfully, you will get an interface where you need to create desktops and pools. This is done through the Administrator interface. From there, you can see all the desktops and pools that exist and their current state. You can also create, edit and tune any desktops or pools. Configuring VDI with its user-friendly wizard is easy. You just need to map your AD user with the VMs hosted on the ESX hosts.

Accessing VDI from client end

Once you have created your desktops, the final stage is to install the View Client onto user devices. When the user logs onto the network they will be taken to a screen where you need to select the desktop that user needs to access. Once selected, you will feel like as if you are working on a local desktop, however virtual desktop is setting in a virtual infrastructure as a virtual machine.

We installed it on three different platforms --Windows, Android and iOS, and for these platforms we used iPad 2, laptop with Windows 7 installed on it and a smartphone with Android 2.3 installed. After that we tried to access the virtual desktop from these platforms and we successfully logged in. It was working perfectly fine in all the three platforms. We also tried to disable the USB for different users from the server and it successfully disabled the usage of USB for the client machine. This gives user the freedom to run the virtual desktop on any platform. Whether it is iPad 2, an Android machine or a desktop, a user can access these virtual desktops from virtually anywhere.