DESKTOP VIRTUALIZATION PILOT PROJECT

Transcription

1 DESKTOP VIRTUALIZATION PILOT PROJECT Project Sponsor Tom Holub, Letters and Science Computing Resources Project Manager Ryan L. Means, Technology Program Office Project Team Ron Amis, Computer Operations & Information Services Michelle Bautista, Departmental On-site Computing Support Kevin Burney, Computer Operations & Information Services Tim Faircloth, IST Workstation and Microcomputing Facilities Paul Garnett, IST Departmental On-site Computing Support Gabriel Gonzalez, Berkeley Law Seth Novogrodsky, Letters and Science Computing Resources Luke Nucum, IST Departmental On-site Computing Support Curtis Salinas, IST Windows Team Sian Shumway, IST Workstation and Microcomputing Facilities Michael Sinatra, IST Network Services

2 As a result of the Campus Technology Council's IT Funding Request process for 2008, the Desktop Virtualization Pilot Project received funding to research and develop several small pilot programs to determine if a centrally-hosted desktop virtualization service would provide value to the University. The project participants came from a cross-section of the campus, with representation from both small and large academic and administrative IT units. The project launched on October 13 th, 2008, and ran through July 31 st, This report includes: a brief overview of virtual desktop technology, the use cases the team selected against which to evaluate the technology, the various solutions the team researched, a description of the pilot architecture, comments and experiences from the team, and a conclusion with recommendations. OVERVIEW OF DESKTOP VIRTUALIZATION Desktop virtualization (or Virtual Desktop Infrastructure - VDI) is a server-centric computing model that borrows from the traditional thin-client model, but is designed to give system administrators and endusers the best of both worlds: the ability to host and centrally manage desktop virtual machines in the data center while giving end users a full PC desktop experience. USE CASES ADMINISTRATIVE / OFFICE WORKER Administrative / office workers often have relatively uniform desktop technology needs. This use case looked at replacing staff machines with a standardized virtual desktop solution that includes typical productivity software and a pre-defined set of applications specific to the user s job. The goal was to take advantage of the desktop standardization that VDI provides, while balancing performance requirements and costs. Participants in this use case included Berkeley Law, DOCS, and Letters and Science Computing Resources (LSCR). STUDENT COMPUTING LAB Student computing labs usually have standardized hardware and software, with centralized administrative controls. This use case evaluated replacing the typical computer lab machine with a virtual desktop solution, preferably one that included a thin client, to lower the TCO for computer lab systems. Student labs are particularly sensitive to audio/video performance issues due to requirements for instruction-related multimedia. The Workstation and Microcomputing Facilities group within IST evaluated this use case.

3 LECTURER/VISITING FACULTY Many academic departments have kiosk or "hotel" desktops for lecturers or visiting faculty members. These users have needs for access to a standard suite of software, but also customizable work spaces with mobility features and session persistence. The performance needs for this use case would be similar to those of the administrative / office worker desktop. LSCR evaluated this use case. SECURE DESKTOP Many users of confidential data store that data on their own desktop machine, or even on laptops or home machines. A server-hosted virtual desktop environment could provide better security, because user data written to the local disk is actually stored on the server infrastructure; this configuration mitigates the risk of data theft or loss. It might be a recommended configuration for users who frequently deal with restricted data in areas that are at high risk for theft. This use case was evaluated by COIS. TELECOMMUTE/WORK-AT-HOME Telecommuting users have need of access to data and session persistence. This use case evaluated using VDI to allow users who frequently work from home to create a standardized, manageable home work environment. This standard work environment could be free from viruses, Trojans, and other malware because the OS image would be kept on the server and users would not have Administrator rights. COIS also explored this use case with a small group of their users. TECHNOLOGY CHOICES After establishing the use cases, the team selected a small group of vendor solutions to evaluate based on market popularity and prior relationships to UC Berkeley. We set up meetings with representatives from VMWare, Citrix, and a Palo Alto startup called MokaFive. Each one offered a slightly different product that had particular advantages and disadvantages for the purposes of the pilot. VMWARE We reviewed VMWare View, a traditional server-based desktop virtualization environment built on a VMWare ESX server farm, a virtual machine broker called View Manager, and either an installable or web-based client. One of the main advantages of VMWare View is that IST already has strong experience with a large ESX deployment, so we would not need to train on a new environment, and we could quickly deploy another ESX farm for the pilot. The biggest disadvantage with VMWare was the maturity of their solution. VMWare View 3, their recommended version, was released after the pilot was already underway. CITRIX

4 Citrix offers a server-based desktop virtualization solution called XenDesktop, with a server, broker, client architecture similar to VMWare View. One major difference is that Citrix does not require a particular server hypervisor, so the back end could be provided by ESX, Citrix, Microsoft, or any virtual machine solution. In addition, as of XenDesktop 3, Citrix was the only vendor to offer support for ICX, a higher performance display protocol. One of the major shortcomings for Citrix, however, was a poor interaction with the account manager and an inability to nail down specific details about how a pilot project would work in terms of hardware and licensing. MOKAFIVE MokaFive's approach is different than the solutions offered by VMWare and Citrix because it is a clientbased hypervisor. Similar to Parallels or VMWare Fusion, client-based hypervisors allow a client system to run multiple independent machine images. MokaFive s solution includes centralized synchronization of these client images with a server. MokaFive s greatest advantage was that it used the client hardware natively, so there were little to no performance problems; however, this was also its greatest shortcoming, because it required client hardware with more power (and cost) than a thin client. DECISION Ultimately, the team chose to proceed with VMWare View for the pilot, based on the demonstrations from the VMWare account team, a generous free license for the duration of the pilot, and the aforementioned VMWare infrastructure experience that would provide for a quick project ramp-up. In addition, the team decided to use IST's infrastructure instead of building our own because of the short timeframe involved and the assumption that a successful pilot could yield a service built on IST infrastructure. PILOT ARCHITECTURE The architecture for the pilot was comprised of an ESX Server farm running ESXi 3.5 Update 3 on three Dell PowerEdge M600 blades hosted in the Data Center. Each blade was equipped with 32Gb of RAM and 2 quad-core CPUs and fiber-attached to a high performance SAN. The VMWare View 3 broker component (View Manager) was installed on a virtual machine in the farm, and VirtualCenter 2.5 Update 3 was used for management. For client hardware we used a wide variety of Wyse thin clients (V10, X90, and R90 models) running either Wyse ThinOS or Windows XP Embedded. We also tested the View client on repurposed Windows machines from the participating units and connected to View VMs from Mac and Linux machines using the web interface. EXPERIENCES

5 Even though the project was broken up into separate use cases, many of the teams findings applied across the board. Unless otherwise indicated, the experiences below were common to a majority of the pilot participants. BACKEND (INFRASTRUCTURE AND SERVICE SUPPORT) The backend administration of the server farm and broker (infrastructure) was performed by Curtis Salinas from the IST Windows Team, while the setup of virtual machines, snapshots, and the creation of pools (service support) was performed by Curtis, Seth Novogrodsky from LSCR, and Gabriel Gonzalez from Berkeley Law. For service support, the virtual desktop environment is managed by the View Manager web interface. The web interface is easy to use but not particularly intuitive. Wizards are used to create and manage pools. Internet Explorer is required to access View manager. The team experienced a number of problems with View Manager: Provisioning new machines would sometimes fail; in some cases, most of the machines in a new pool would be created successfully, but a few would not. In addition, creating new pools of machines would often take a very long time, sometimes hours, with some of the machines failing to be created properly. VMware View allows two types of pools: persistent and non-persistent. The persistent machines allow settings and user data to be retained. One of the purported benefits of a persistent machine is the ability to recompose it (i.e., update the image on which it is based) without losing that data. In actual practice, profile information would often be lost after a recomposition. Logging into View Manager would periodically be slow, and sessions would time out at seemingly random intervals. Deleting machines was sometimes problematic. Some machines would delete within a few minutes; others would take days or require a restart of the backend software. In one case, a machine would not delete even after a restart of the software. Curtis Salinas, who managed the infrastructure for the project, summarized his impressions as follows: My impressions of the backend were/are good with respect to VirtualCenter/ESXi (obviously), and a little less so regarding the View software. It seems like an immature product, but one that is rapidly advancing, and VMware managed to address my concerns (at least on the management side) fairly quickly. COMMENTS ON SETTING UP AND MANAGING A VIRTUAL DESKTOP ENVIRONMENT

6 One of the potential advantages of a virtual desktop environment is ease of management and administration. In practice, we were unable to realize this potential, partly because of the learning curve and partly because of the deficiencies in the current generation of desktop virtualization software from VMware. A pool of virtual machines is based on single image (a snapshot" of a template virtual machine). The virtual machine can be created from scratch or be based on a Ghost image of a physical machine. There are specific documented procedures that need to be followed for an image to work properly as the basis for a virtual machine; not following those procedures invariably resulted in problems. There were more problems with templates based on Ghost images than with those created from scratch, and pools based on the Ghost images took quite a bit longer to provision. The main tool to set up and configure an image for pool of virtual desktop machines is the VMware Infrastructure Client (VIC). The VIC is not specific to View. The VIC provides a log-in console to test and configure the VM, install software, etc. It is not sufficient, however, just to test the template VM. Machines based on the template will differ in some respects because new user profiles are created when a user actually logs in. Getting the default user profiles to behave as we wanted them was a timeconsuming process. One of the potential advantages of a virtual desktop environment is the ability to have multiple snapshots of the same template. If a problem is discovered with an update, for instance, it is easy to revert to an older snapshot without the update. To reduce storage requirements for these snapshots, VMware View uses linked clone technology. However, it is very important to keep an eye on the storage usage. In one instance, excessive snapshots filled the datastore and caused provisioning failures with little information about the root cause. Having different pools based on different snapshots proved difficult to manage; for example, in one instance, a snapshot that was being used was accidentally deleted, and the VM based on it stopped functioning. Another potential advantage of a virtual desktop environment that was not realized was ease of management and administration. Below are some of the issues that the team experienced: Administrative access to machines: Virtual machines are accessed through one of two mechanisms: the View Portal and the VMware Infrastructure Client. For a number of reasons, using the VIC console is a better way to access the machine as an administrator. (For example, if you log in as the user through the View Portal and then log out, the connection to View server will be broken and you will need to reconnect again, whereas with the VIC console, you can just log in and log out again.) There are two problems with the VIC as a management tool: o o The VIC has to be installed on each machine that you want to be able access VMs in this way. In addition, each consultant needs to learn how to use it. While any AD account can be used to log in to the VWware infrastructure via the VIC, for a large IT organization, managing accounts for multiple people with access to a variety

7 of VM could be a burden, and incorrect management of permissions could inadvertently give accounts complete control of the wrong VMs. Access to View Manager and features of the VMware Infrastructure Client. In the pilot, three people were given access to View Manager. The reason for limiting access is that those with credentials to log in can inadvertently damage other people s pools of virtual machines. Likewise, only one person had access to all features (such as cloning a template) of the VIC. The reason for the limited access was due to the lack of granularity in the ability to assign specific administrative rights to specific users. This issue may be remedied in future versions of the software, but in the pilot, it added a layer between the departmental virtual desktop administrators and the tasks they needed to complete (such as provisioning, recomposing or refreshing a pool). Performance issues: Provisioning and recomposing pools of virtual machines is extremely resource intensive; performing these tasks can result in degraded performance for all users of the virtual desktop infrastructure. For this reason, we needed to perform these tasks after hours. Some tasks could be scheduled, but it was necessary to monitor the progress, as provisioning and recomposition would often fail for one or more machines. From a support perspective, it would have been helpful if these tasks could have been performed at any time. That might have been possible with more powerful hardware, but also would have substantially increased the infrastructure costs. VIEW CLIENT (USER DATA, LOGIN, AND PERFORMANCE) USER DATA Some users experienced unexpected disconnection of the virtual machine's data disk, resulting in a loss of profile information. This was an issue for multiple pools and was a major factor in the decision to end the pilot. The problem was attributed to a disk space issue within the affected VMs. In addition, not all flash drives were recognized properly by the View Client. If a user was using a virtual client instead of a traditional PC in the computer lab, improper flash drive recognition could cause the user to lose data. LOGIN ISSUES Inability of entitled users to log in, even after a verification of their CalNet passphrases. This issue affected L&S users as well as almost 10% of users in the campus labs. There was no resolution to this problem found during the pilot. Slow performance reported by some users when attempting to log in.

8 Users entitled to use more than one pool became confused when presented with multiple choices for pools to log into. This was a problem during the pilot, as the campus Workstation and Microcomputer Facilities entitled all domain users to use their machines, forcing all domain users to be presented with a pool choice rather than an immediate login. Related to the above issue, some use cases required compiling lists of the CalNet IDs for all users entitled to use a specific virtual machine. This presented a problem for general access machines; one of the departments opted not to install a specific machine for this reason. There was no way to restrict logins for a pool to a specific set of client machines. This resulted in situations such as students from the Microcomputer Facilities logging in to virtual machines from other pilot departments. There may be a solution to this issue, but we were unable to find one during the pilot. If a user login hangs, the user is unable to log in from a different machine until the login resets (15 minutes). Logging on from a Mac was somewhat convoluted and confusing for users. (More on Mac issues below). PERFORMANCE The team encountered some performance issues: The View portal was sometimes slow to respond when users attempted to log in. Some users experienced slow performance when running standard applications. Increasing the RAM mitigated the problem somewhat. Video performance was unacceptable. Videos such as campus podcasts were often unwatchable, with jerky motion and sound, often not synchronized. Outside of the issues listed above, VM performance was acceptable with standard productivity applications such as Office 2007, Firefox, Thunderbird, and AFS. The virtual desktop performance was also very good remotely, and required only a simple client install to function. THIN CLIENT ISSUES (WYSE TERMINALS) L&S used Wyse thin client machines with Windows XP Embedded. Configuring these machines to access the View portal was not difficult, but there were some issues: In one case, there was not sufficient memory on the device to install an HP printer driver (using the HP installer), even after stripping out all unneeded software. (We ultimately had to install the driver without using the installer.)

9 The thin clients lack an optical drive, which make them unsuitable for many academic uses. An external drive can be added, though that detracts from the simplicity of the thin client. Some departments used thick clients, essentially older PCs that that had been repurposed. There are two issues with the thick clients : There are two operating system environments to maintain, one for the repurposed PC and the other in the VM. Using the repurposed PC as a PC (instead of as a terminal for a VM) can provide a superior user experience in many cases. In the computer labs, where Wyse terminals were already in use, the migration from Terminal Services to VDI was easy. Both the labs and COIS found that management of the Wyse terminals was simple through FTP or the Wyse Management server. MAC ISSUES Providing virtual Windows machines for Mac users was not one of the original use cases, but it was one of the most intriguing possibilities for several of the pilot participants. A significant number of Mac users run VMware Fusion, Parallels, or Boot Camp to access Windows on their Macs. A virtual desktop for the users could provide a number of advantages, particularly in improving management of the Windows VM. There were, however, some significant issues with accessing the VMs from a Mac: Connecting to the VM requires a somewhat cumbersome procedure involving multiple dialog boxes and repeatedly having to download a connection file. The only supported browser is Safari. Connecting to the View Portal requires Microsoft s Remote Desktop Connection client for Mac. Unlike with a standard remote desktop connection from a Mac, with VMWare View there is no supported way to save preferences for a VDI connection. The default preferences are problematic in that they do not allow for such features as sound and mounting USB flash drives. VMware has claimed that a dedicated Mac VDI client is being developed; such a client should remedy these problems. LICENSING ISSUES For the lecturer / visiting faculty use case, in order to provide functionality similar to a standard PC environment, LSCR decided that the best approach would be to give each participant his or her own virtual machine. This required purchasing licenses for Acrobat Professional and Microsoft Windows and Office for each user. Overall software cost could be greater in some cases for a VDI solution, as a physical shared machine could have met the needs in some instances. In any case, a broad VDI deployment clearly would require subscription to a Microsoft Consolidated Campus Agreement (MCCA).

10 CONCLUSION AND RECOMMENDATIONS While the team saw promise in the technology and saw an immediate application for virtual desktop technology to provide Windows environments for Mac users, we conclude that VMWare View is currently too immature to be considered for a production rollout. This conclusion is based on the following major factors: Technical problems with the implementation were found to be overwhelming, and even groups that were successfully able to implement the solution continued to run into unexpected bugs on a regular basis. No team saw a reduction in technical support for virtual desktop deployments; on the contrary, they consistently had more problems and required more attention. For support costs to decrease, the service would need to be mature, stable, and well-supported by the vendor, reducing or eliminating the amount of trial-and-error troubleshooting for each problem. Users were generally unhappy with the performance of virtual desktops and even more unhappy with desktops that did not work consistently. Because of these problems, students using the computer labs were actively choosing to use traditional PCs over the thin clients running VDI, and one academic department requested that we remove the thin clients and replace them with old thick client PCs. The team recommends postponing deployment of virtual desktop technology until there is compelling evidence that the product offerings are more mature. Some project participants would be interested in revisiting the technology in a year to determine if there have been developments that enhance the reliability, supportability, and user experience.