Virtualizing Specialized Software

Key Takeaways

• With the shift of student computing away from fixed locations such as public computer labs and toward anywhere, anytime, on-demand mobile computing, colleges and universities must realign their computing services accordingly.
• Specialized software for computing—whether for mapping and imaging, design and modeling, computation and visualization, or statistical analysis—traditionally has been made available on computer lab systems, not widely distributed on students' personal devices.
• Virtualizing delivery of specialized software enables students to access the programs they need independent of location or time of day, while allowing institutions to reduce the number of computer lab machines provided and maintained for student use.
• The University of Virginia piloted two approaches to delivery of specialized software to students before settling on the system they call the Hive, which became a full production service in fall 2010.

Student computing is now mobile. For college students across the nation, convenient access to information — anytime, anywhere, on demand — has become not only a priority, but a necessity. To successfully serve the needs of this current generation of students, colleges and universities must recognize the trend and align services accordingly.

That's what we're doing at the University of Virginia, where mobile student computing emerged relatively quickly. In 1997, over 25 percent of our students did not own a personal computer, and of those who did, fewer than one in five had a laptop. Back then, trekking across campus at odd hours to use a desktop machine in a public computing lab was the norm for many students. Just a decade later, virtually all incoming first-year UVa students owned a computer — and not a desktop, either. Since 2007, 98 percent of our students have brought a portable laptop computer with them to college. (This laptop saturation has occurred across all student income levels because the University of Virginia, like many other colleges, has resources in place to provide computers to students with financial need.)

In recent years, more and more of our students have even brought a second computer with them to school, as well as other "portable network devices" — our name for the small gadgets that provide access to the web — such as smartphones and the iPod touch. One-third of the class entering UVa in 2008 brought some type of portable network device, as did nearly 60 percent of the class entering in 2009.¹ Although we don't have data for the class entering in 2010, based on the recent emergence of the Android mobile platform and the iPad, as well as the continued popularity of other iOS devices, it seems safe to assume the numbers have continued to climb.

Figure 1 shows ownership statistics of portable network devices — such as smartphones, PDAs, and the iPod touch — among first-year students who entered the university in the fall semester of 2009. Table 1 documents computer and device ownership statistics — including laptops, desktops, and multiple machines, as well as portable network devices — among first-year students who entered UVa in the fall semesters 1997–2009. Of particular note is the fact that since 2007, over 98 percent of the incoming class has brought a laptop computer with them to school. The data for the past three years is shaded in the table to further emphasize this recent increase in mobile student computing.

Figure 1. Incoming Student Portable Network Device Ownership

Table 1. First-Year Student Computer and Device Ownership at the University of Virginia, 1997–2009

Providing Lab Computers: A Duplication of Effort?

Even as student laptops and mobile devices have become commonplace, we — like most other colleges and universities — have continued to provide desktop computers for students to use in public labs. Many of these labs stayed open late, and some were staffed; all had bulky computer workstations, loaded with costly specialized software packages that needed updates and patches applied regularly. In short, our centrally supported public computing labs required significant investments of funding and time. With mobile student computing so ubiquitous, they had essentially become redundant.

We reviewed our computing lab usage statistics, and the data only confirmed our hypothesis that much of the time students spent in our labs was to run software already on their own computers. Statistics showed that, on average, about 95 percent of the time students spent in our labs during the school year was to run commodity or free programs such as Firefox, Internet Explorer, Adobe Acrobat Reader, or Microsoft Office. (All these applications come preloaded on student laptops or are available at very low or no cost to UVa students.)

In contrast, students spent much less time running specialized academic software packages such as MATLAB, Mathcad, and SPSS in our computing labs. Even during the heaviest usage periods — mostly in the summers — the time spent running specialized software in the labs remained below eight percent, and during the school year, it averaged around just five percent.

Virtualization: A More Cost-Effective Approach

Based on this information, we sought a more strategic long-term solution for UVa, one that would decouple specialized academic software packages and the public computing labs. We wanted to free our students from having to use a specific physical space to do coursework. We envisioned such software available to our students whenever and wherever they needed it. In a time of budget constraints, though, we decided to move toward a university-wide virtualized computing environment only if such a move could be cost-neutral. This meant we had to take a second look at the infrastructure costs we incurred when providing those public computing labs to students who already owned computers.

Enhancing Services While Managing Costs

To achieve our goal of cost-neutrality, we scaled up the ongoing lab closures that ITC already had under way, as shown in Table 2.

Table 2. UVa Lab Closures by Academic Year

Three years ago, we announced our plans to phase out 375 machines at the end of their life cycles, thereby augmenting our gradual reduction in the number of public labs and desktop computers on campus. The lab phaseout will be complete in summer 2011; at that time, only one ITC-supported public computing lab will remain. This timing coincides well with the findings from our laptop ownership data, as students who entered in fall 2007 — the first year we had 98 percent laptop saturation — will be graduating just as the last labs scheduled for closing shut their doors.

By cutting the expenses associated with the upkeep and maintenance of these public desktop machines, we obtained significant savings:

• First, the university regained much-needed space, which can be repurposed for classrooms or other academic pursuits.
• Second, we have also saved on utility costs with lower power consumption.
• Finally, we estimate the savings generated by closing the public labs to be about $240,000 annually, which reflects the costs recovered by not leasing computer hardware and not spent on machine maintenance.

In comparison, we estimate that our planned virtualization solution, the Hive, will cost approximately $68,900 when averaged over a five-year period. If we realize the savings expected, the university will save about $170,000 each year. (Of course, these figures are specific to UVa — our total costs in our particular computing environment — and not necessarily the costs other schools would see with different hardware, staffing organizations, software contracts, etc.).

As we worked to reduce the number of seats available in public computing labs around campus, we also worked to enhance the individual student's laptop experience. For example:

• We improved the university's secure wireless network, making it more robust and user-friendly, recognizing that if faculty elect to use the Hive during their class meetings, we will have additional load on our wireless infrastructure.
• We also negotiated a Campus Agreement with Microsoft, making essential word processing and other basic productivity software much more affordable and easily accessible for all UVa students.
• Finally, with an eye toward fostering group collaboration and experimentation, we partnered with other organizations around the university to create more formal and informal collaboration spaces at UVa — technology-rich zones where students can bring laptops and mobile devices to pursue group work. Whenever possible, we implemented these enhancements during already scheduled updates and refurbishing.

Staffing and Expertise Required for Virtualization

While working to improve the mobile computing experience, we also began pilot-testing ways to provide our students with virtualized access to software. To begin, we formed a virtualization project steering committee comprised of employees across the university with expertise in key arenas that were critical to the project's success:

• Software imaging
• Software licensing compliance
• Back-end server infrastructure
• Instructional technology
• Communications and public relations
• Technical support

Pilot-Testing Virtualization Solutions

The project steering committee decided to test potential virtual software delivery channels and determine which best suited our environment. We considered several vendors before deciding on a two-pilot test of the following virtualization solutions:

• Microsoft Remote Desktop Services (also known as Terminal Services), which we branded the "Virtual Lab" pilot, held in fall 2009
• VMware, which we called "The Hive" pilot, held in spring 2010

While we considered other vendors with similar virtualization offerings, such as Stoneware and Citrix, our experience with Microsoft Terminal Services and VMware in server-based virtual environments meant they were the front-runners for consideration at UVa. Virtualization technology and the associated software market are rapidly evolving, however, and we believe that our technical solutions will evolve over time as new capabilities become available.

Evaluation Criteria for Both Pilots

Before beginning the pilots, the steering committee established criteria for evaluating them. We wanted to make our final recommendation based on:

• Feedback received from users regarding speed and ease of use
• Feedback received from technical support staff who implemented the solutions on the back end
• Comparison of the total cost of ownership for each potential solution tested (including expenses associated with hardware, software, licensing, and staff time)

During both pilots, the steering committee asked participants to test preselected software titles in a variety of ways: on laptop and desktop machines, in wired and wireless environments, and using Linux, Macintosh, and Windows platforms. We wanted to test the potential software delivery solutions in these likely student use scenarios to ensure they could perform adequately in a virtual environment.

Software Programs Tested in the Pilots

During the pilots, we had participants test virtual use of a range of specialized software packages. We chose these programs for testing because they were already in use at the university and available on ITC-supported public computing lab machines. (Again, we were particularly interested in comparing how a potential virtualized solution performed relative to an average student experience in a lab; making the same software programs available virtually ensured a type of "control" for testing during the pilot process.) A sampling of the programs tested virtually and a brief description of their common uses follows:

• ArcGIS (spring) — geographic mapping and imaging, viewing and analyzing spatial data
• AutoCAD (fall and spring) — 2D and 3D computer-aided design and modeling
• Aspen (fall and spring) — advanced engineering calculation and simulation
• Maple (fall and spring) — symbolic and mathematical computation and visualization
• MATLAB (fall and spring) — mathematical computation and visualization
• Mathcad (spring) — mathematical computation
• Mathematica (fall and spring) — symbolic and mathematical computation and visualization
• SAS (spring) — data management, data mining, and data analysis
• SPSS (spring) — statistical analysis in the social sciences
• Stata (spring) — integrated statistical analysis, data management, and graphics

Pilot Communication Channels

Aware that substantial feedback from our testers would be crucial when evaluating our potential virtualization solutions, the steering committee sought to identify communication tools and feedback mechanisms that would yield the highest possible response rates from students. We decided to maximize the opportunities for contact by collecting their opinions using multiple tools, including sending out weekly e-mails to pilot testers; monitoring blog comments and Twitter responses; and conducting class visits, focus groups, and end-of-semester online surveys.

We also identified a variety of tasks associated with testing a potential virtual software delivery solution and focused our queries on these topics. Through several channels, we garnered substantial user feedback from our students during both pilots regarding:

• Ease of first-time installation and setup for each solution
• Quality of our documentation and instructions for each solution
• Speed of software applications tested virtually
• User experience when attempting to map local and network drives
• Convenience of saving and printing from a virtual desktop
• The means by which they accessed the virtual solution (wirelessly, on a Mac, from another state or country, etc.)

Using Prizes to Encourage Feedback

From the beginning, we made offering feedback a clear expectation of all pilot testers, but we also learned right away that students will take the time to submit suggestions much more quickly, frequently, and thoroughly when incentives are offered for their active participation. The steering committee decided to provide additional motivation to share comments and suggestions by promoting opportunities to win prizes. In this case:

• Replying to our e-mailed "Question of the Week" entered student testers into a weekly drawing for a $20 gift certificate to the campus bookstore.
• Participating in a focus group got them a free lunch and entered them into the running for an iPod touch.
• Completing the end-of-semester online survey made them eligible for a drawing for a new iPad.

We found that the relatively small cost associated with obtaining these prizes was well worth it, considering how enthusiastically our student testers responded to each feedback opportunity. We reliably received valuable feedback, both in terms of quality and quantity, virtually every time we solicited it from our students during these pilots.

Piloting Microsoft Remote Desktop Services

The fall 2009 pilot of Microsoft Remote Desktop Services was small, with about 200 testers. While Virtual Lab worked fairly well from the student perspective, on the back-end server infrastructure side, things went a little less smoothly. Maintenance required server downtimes, which interrupted student workflow and was often labor-intensive for technical staff, decreasing flexibility and making changes to the image more difficult. Furthermore, not all specialized software applications could run via this solution, so many software programs that we typically offered in the computing labs —  SPSS and AMOS, Mentor Graphics' FPGA Advantage, PADS 2009, Quartus II, some MS Excel and browser plug-ins — simply were not available virtually for our students.

Thus, while Remote Desktop Services met the most basic needs for a virtualized lab solution at UVa, we found it was not flexible enough to accommodate all of the university's specialized software needs. Still, our small-scale fall pilot proved that our students could successfully access software virtually on their laptops, and also revealed areas of concern — including the importance of convenient drive mapping, printing capabilities, and general communication — helping us to focus on important attributes that would ensure the success of the larger-scale spring pilot.

Piloting VMware

The spring 2010 pilot of VMware, which we branded "The Hive," quickly grew in size as more and more learned about it and wanted to try it. By the end of the semester, the test group included nearly 900 students, faculty, and independent testers from the university community. Figures 2–5 show the sequence of screens users saw when logging into the UVa Hive during the pilot.

First, users authenticated themselves by providing their UVa login credentials, as shown in Figure 2.

Figure 2. Logging In to the Hive

They then saw the four available Hive "desktop" images, organized by academic discipline, as shown in Figure 3.

Figure 3. Selecting a Hive Image

When they "moused over" the name of one of the images, hovering on a title such as Engineering_and_Arts_and_Sciences, a dropdown appeared, as shown in Figure 4. This contained the full list of specialized software titles available on that particular image. They simply clicked "connect" by their desired image to get a Hive virtual desktop session with that selection of software programs on it.

Figure 4. Viewing Available Software

After a few seconds, their connection to the Hive was established, and they were logged in to their Hive virtual desktop (which looked like a typical Windows Vista desktop screen). From there, they could go to the Start menu, click "All Programs," select their desired software package from the list of available titles as shown in Figure 5, and begin their work.

Figure 5. Using a Hive Virtual Desktop

User Feedback

Based on the comments we received from the Question of the Week, we learned that the vast majority of students found logging into the Hive quite simple, and only a handful experienced minor technical issues. Frequently, we saw responses such as, "Connecting was surprisingly fast; no complicated setups." One student who participated in both our pilots even noted, "Logging on for the first time is a little confusing if you try to do it without the instructions, but the website lays it out very clearly. Logging on after the first time is much easier than the old way [using Microsoft Remote Desktop Connection] and I'm happy with this improvement."

Midway through the pilot, in response to student feedback we received from the Question of the Week and to provide a better user experience, we did address some student concerns about saving and drive mapping. Also, a few students complained about printing and web browser incompatibility issues. More details about these challenges — plus our findings on speed and how we handled licensing and security — are provided in the "Caveats and Limitations" section below.

Overall, we heard through various feedback channels that students were satisfied with the Hive. They remarked on its ease of use, convenience and flexibility of access, cross-platform capabilities, and the ability to get work done effectively whenever and wherever needed. Respondents in the Hive's closing online survey² overwhelmingly (89 percent) agreed that they would recommend the Hive to others, with two enthusiastic users indicating:

"The Hive rocks!"

"The Hive is the best thing that's ever happened to me."

We learned from the Question of the Week that students were successfully doing their UVa work via the Hive from all across the country and even as far away from campus as China. We learned from focus groups that many found it convenient to "roll out of bed" to do their homework at home, instead of rushing to a lab the morning before an assignment was due or trekking to campus alone in the dark for an all-nighter.

Technical Support Staff Feedback

From the back-end server infrastructure perspective, the servers remained stable throughout the VMware pilot. Updates could be applied seamlessly, with no downtimes required, minimizing disruptions to student work. ITC staff also appreciated the ability to generate and duplicate images with great flexibility.

We did not encounter any application compatibility issues, either: VMware was able to run multiple images with different software packages and operating systems. This enabled us to offer more software titles virtually than in the fall Remote Desktop Services pilot, and in a very flexible format that enabled us to organize and group images by discipline and software type, as shown in Figures 3 and 4, thus streamlining the user logon process, too.

Comparing Costs

We conducted a five-year assessment to estimate what it would cost us to run Virtual Lab (Microsoft Remote Desktop Services) versus the Hive (VMware) for 200 "seats" (simultaneous sessions). We found that Virtual Lab would cost about $887 per seat per year, versus $345 per seat per year for the Hive — a difference of more than $500 per seat. These figures reflect all of our anticipated expenses associated with virtualization, even accounting for five percent inflation, and factoring in hardware and software costs and licensing and maintenance fees. But, they exclude staff time, including time spent on:

• Initial setup, support, and maintenance of the back end
• Software image creation and maintenance
• PR, marketing, and web documentation
• Licensing oversight
• User support

Conclusion for Our VMware Pilot

Based on user feedback (the complete survey results are now available online), infrastructure support staff feedback, and our cost assessment, summarized in Table 3, we decided that VMware was a viable long-term solution for virtualized software delivery. We began offering the Hive as a university-wide production service in August 2010. We are currently promoting the availability of this new service to faculty and students using various communication channels, reimplementing on a larger scale most of the outreach we conducted for the smaller group of pilot testers. UVa is now moving toward virtualized delivery for nearly all of the specialized software applications typically accessed in a computing lab environment.

Table 3. Summary of Virtual Lab and Hive Pilots and Findings

Caveats and Limitations of Virtualization

UVa encountered a number of challenges along the path to virtualizing the delivery of specialized software. Here we revisit how the university addressed these issues.

Saving and Drive Mapping

From the beginning of the pilots, we warned students that they had to be careful to save their work someplace other than the virtual desktop itself (the C: drive). Because each virtual session is discarded on logoff, those who failed to do so would lose their work. In addition, to ensure there were enough virtual "seats" for everyone, we set a policy that virtual sessions would automatically time out and log off after 30 minutes of inactivity, which would also result in data loss for those who had not saved recently. We therefore made a point of noting "Save often!" on our web pages, e-mails to students, and information packets.

Early in the spring pilot, we heard from students that saving their work from within the Hive was a little confusing. They complained that they could not easily find their local hard drive while inside the Hive in order to save to it. Many reported they had to e-mail files to themselves as a workaround. So, we had some ITC staff write a simple script that would automatically map a student's local drive(s) on login to the Hive. We added this script to the Hive image on the back end very easily, with no downtime required. Because the script had to run each time a student logged in to a virtual session after that, it did add a few seconds to the initial wait time required for each Hive desktop to boot up. Still, this short delay enabled students to easily select their local hard drive or other external media on the menu when saving a file. The script starts with Z and goes back up the alphabet; if a drive letter is already in use, it skips that one. So, whenever students select the Z: drive (or the Y: or X: drive, as the case may be) in the Hive, they are actually accessing their local drives. Many students commented later in the pilot how much they appreciated a more intuitive "save to drive letter" option.

Printing

During the pilot, some students reported frustration that they could not print to their local printers from the Hive. Because it was not feasible for us to install drivers for every possible type of printer, we recommended one of the following workarounds:

• Save the file to a local drive, external media, etc., then print from there to a local printer.
• Send the print job from the Hive to any UVa printer.

In fall 2010, just as the Hive became a full production service, the second workaround became fully possible. UVa's Printing and Copying Services Department (PCS) unveiled its new "Follow You" printing service. PCS installed public laser printer kiosks all across campus — in the handful of labs that remain, plus in the libraries, dorm lounges, and other dedicated study areas. This meant we had to install only two printer drivers in the Hive, one for black-and-white print jobs and one for color. Now, whenever students want to print from the Hive, whether on or off campus, they use the "Print" command in their application, choose either black-and-white or color, then go to the nearest university public printer kiosk. They log in, view a list of their individual print jobs, select the one they want, swipe a card to be charged, and pick it up off the printer.

Browser and Operating System Limitations

We did run into a few technical difficulties with some web browsers and operating systems. First, the Hive required Windows computers to connect using Internet Explorer versions 7 or 8 and not to have disabled their Active X controls. (Macintosh users could connect to the Hive with Firefox or Safari; for Linux users, only the Firefox browser worked reliably.) Several students with Windows computers who primarily used Firefox or Google Chrome, or who had newer or older versions of IE, complained about the Hive's web browser limitations. We let them know that this was a limitation associated with our implementation of VMware. For these students, installing the VMware client manually (and accessing the Hive via a software program on their computer, rather than via the Hive portal page in their web browser) resolved these issues.

Also, after some testers' initial confusion, we figured out that students with the older Mac OS X 10.4 (Tiger) operating system needed to connect to the Hive differently than students with the newer versions. We developed an installation procedure specifically for the older operating system and offered one-on-one "Get Connected" sessions for Tiger users in order to resolve their issues. Since the university retired support for Tiger as of August 2010, this was no longer a problem by the time the Hive became a full production service.

In addition, because we do not provide university-wide support for the Linux operating system, once the pilot ended and the Hive became a full production service, we decided to categorize Linux as unsupported as well. Some students still do run the Hive on their Linux machines successfully — we just do not provide support for them beyond one web page of documentation, instructions, and tips.

Speed

In both pilots, students had few concerns about speed; applications weren't superfast, but seemed to be fast enough. Some students reported minimal lags when using advanced software on the Hive, but complaints centered on very large and complex applications such as AutoCAD and ArcGIS. We believe that a more robust network connection is required for these types of complex mapping and modeling applications to perform as well in a virtual environment as they do in a lab.

Still, most users seemed satisfied with the speed — 81 percent of respondents to the Hive survey ranked every application they tested as either "Fast/Functional" or "Tolerable/Acceptable." As shown in Table 4, only about 3 percent of respondents ranked one or more applications as "Slow/Unusable," and when they did, they tended to agree that resource-intensive packages were the problematic ones.

Table 4. User Satisfaction with Application Speed Using the Hive

Licensing

Like other schools and universities seeking to move toward virtualization, we initially harbored significant concerns regarding licensing. However, our experience suggests that licensing is perhaps not as significant a hurdle as feared. In tandem with these two pilots, several ITC team members reviewed every license agreement for all the software programs offered virtually, looking for any language that might make virtual use questionable. We found many licenses were either open-source or the vendor's language made it clear they were willing for universities to provide access however they chose. For the few software licensing agreements that we felt needed additional clarification or modification, our staff contacted the vendors individually to discuss virtualization. We found that most vendors were amenable, and vendors who did have restrictions on virtual use were satisfied with our proposed three-pronged solution:

• The Hive website includes a list of limitations on usage.
• When a user downloads and installs the VMWare View client in order to connect to the Hive for the first time, and every time a user logs in to the Hive via a web browser, a warning appears that some software titles have restrictions, as shown in Figure 6.
• A "splash screen" also appears each time a student launches a software package with licensing restrictions while using the Hive (a pop-up message details the limitations associated with using that particular piece of software).

Figure 6. Hive Software Restriction Notification Splash Screen

By posting reminders in these three ways, we reassured vendors that we had communicated their restrictions to each student at the time of use. In particular, we found that the just-in-time nature of the pop-up screens that appeared when launching software effectively emphasized the license restrictions to students.

Currently, the only licensing issue still outstanding is for SSPS. UVa and IBM have not reached a licensing agreement for the long term, so SSPS has been removed from the Hive. It will continue to be available to our students via download from our Research Computing Database and in the one remaining physical computing lab on campus. UVa continues negotiations with the vendor in hopes it may be offered again virtually in the future.

Security

The steering committee decided we would replicate in the Hive the security settings we use for software in our physical lab machines. Specifically, this means:

• Users have no write privileges to anything other than a temporary area on the local desktop machine (in a lab) or virtual session (in the Hive).
• The image is erased and reloaded from a master that is known to be secure on a regular basis (in a physical lab, this occurs on a weekly basis; in the Hive, at each logoff).
• Authentication is Active Directory–based (at UVa, we call this "Eservices"), allowing us to quarantine known abusers and protect the system from them.
• Updates and software patches are "slipstreamed" into the master image as often as needed.

As mentioned, each student's virtual desktop is discarded once he or she logs off. While this means that user-generated settings and configurations are not preserved from one session to the next — something our students would probably prefer for convenience — it also means that any malware infections disappear when that virtual session ends. Since the possibility of malware in a virtual machine infecting the host is exceedingly remote, virtualization is actually more secure than the desktop computers in our labs. Although malware could infect a student's disk storage, such as a flash drive and/or local hard drive, flash drives can be easily scanned for malware on insertion, and network storage receives regular scans. From a security standpoint, virtualization provides clear benefits.

Concern over Lab Closures

As expected, some public outcry followed our initial announcement that ITC-supported computing lab seats were being reduced. We spent a significant amount of time explaining that the lab phaseout would be gradual; that ITC did not provision every single desktop computer on campus (and that we could not speak to what departments were doing with their desktops); and that once implemented, virtualization would ultimately be much more convenient than labs for students. We sent out individualized responses explaining these points to each student who contacted us, held meetings with the Student Council and the student newspaper staff, and invited particularly concerned students to join the steering committee's ongoing meetings to plan the two pilots. The most effective approach, though, proved to be providing students with the opportunity for hands-on testing, so they could learn firsthand the benefits of virtualization.

Having experienced the Hive, students began to recognize the benefits of a virtualized student computing environment. In online surveys, distance learners commented that virtualized access to software was particularly helpful for them, and Macintosh users shared that they appreciated being able to run Windows platform-specific applications. The campus student newspaper ran a story on the obsolescence of the labs and the increasing popularity of the Hive pilot, along with a student column calling the labs a “luxury” and the decision to close them “pragmatic.”³ In focus groups, students noted they enjoyed the ability to access the programs they needed on their own computers, in their pajamas at home, rather than in crowded and noisy computing labs. One student commented in her Question of the Week response that this new technology was keeping her safe, removing the need for her to travel to and from campus to use a lab late at night. As the Hive has become a full-fledged production service, the positive feedback from students has continued.

As Mike McPherson, associate vice president and deputy CIO, explained to the campus community:

"With physical computer labs, availability of special-purpose software was limited to a small number of fixed locations with limited hours. Using virtualization, we're able to deliver special-purpose software around the clock, into all of the work environments, both physical and virtual, in which our students and faculty pursue their learning and scholarship."

Considerations for Other Universities and Next Steps

Given the success of the Hive thus far at UVa, we have every reason to believe that virtualized software delivery will be a key component of teaching and learning in the future — at the University of Virginia and beyond. In a time when many institutions are evaluating their services and searching for ways to reduce costs and make specialized software more directly available to students on and off campus, virtualization is an excellent option to promote mobile computing and save on costs.

Other colleges and universities considering such a transition are probably weighing similar factors. This article has focused on answering how we at the University of Virginia approached the following concerns:

• Whether virtualized software delivery is more cost-effective, or at least cost-neutral, when compared to the upkeep and maintenance of desktop computers in public labs
• Which types of specialized software applications might suit virtual delivery in lieu of, or alongside, installation in public labs
• The caveats and limitations that might affect virtualization, including speed and licensing concerns, and what workarounds might address these
• The staffing expertise needed and back-end technical components required for successful implementation
• Which student communications tools and feedback mechanisms might yield the greatest response when evaluating possible virtualization solutions
• The resources available for incentives to garner greater feedback, respond to criticisms, and/or promote the new virtualization service to user populations

Our next step will be hardening the system to further stabilize the Hive by ensuring that the server environment supporting it has sufficient redundancy to survive most common incidents that might cause a downtime. We are working on building a second hardware location that can quickly take over the Hive service load should a failure occur. In addition, we will be investing in technology to provide something similar to the Hive in a virtual desktop initiative for faculty and staff. We expect that a few centralized software images managed remotely at a departmental level will save considerable time for our technical support staff, who currently maintain and update every employee's computer. Of course, this means ongoing investments in our wireless infrastructure to support more users, as well as more software licensing negotiations.

We believe the University of Virginia is moving in the right strategic direction because college students today expect software — indeed, everything — to be available free from the constraints of a physical location. Virtualization is one innovative way university IT organizations can provide services more in sync with the needs and expectations of today's mobile students. With careful planning and testing, delivering specialized software applications virtually is not only a possibility for colleges and universities, but a realistically implementable solution.

1. All these data were gathered by student employees of the Department of Information Technology and Communication (ITC) at the University of Virginia. ITC has conducted a census of freshman residence halls each fall since 1997. This First-Year Student Computing Inventory provides annual statistics regarding computer ownership, operating system, network capability, peripherals, and, in recent years, portable network device ownership among incoming first-year students at UVa.
2. We had a 24 percent response rate to the end-of-semester survey, with 59 percent of respondents identifying themselves as undergraduate testers and 35 percent as graduate students; the remaining were staff or other independent testers.
3. See both stories in the Cavalier Daily: Jane Ma, “ITC Plans to Remove Computers from Labs,” April 28, 2010, and Prashanth Parameswaran, “Computing Cost Savings,” February 24, 2009..

© Lauren T. McSwain-Starrett and Stephanie Scheer Conley. The text of this EQ article is licensed under the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 license.