Virtual Computing Laboratories Past, Present, and Future Stephen D. Burd Associate Professor

1. Virtual Computing LaboratoriesPast, Present, and Future Stephen D. Burd Associate Professor Provost’s Academic Technology Liaison burd@mgt.unm.edu Last Revised: 10/26/2012 8:12 AM

2. Acknowledgements • Others that have and/or continue to work with me on VLAB-related issues • Alex Seazzu – Faculty member and ASM IT services director • Greg Gaillard – Manager of infrastructure and services – including the ASM VLAB • Josh Saiz – Application developer and database manager, adjunct faculty member, and VLAB user in multiple courses • Eugene Rooney – Application developer, VLAB web portal developer, and adjunct faculty member • Kara Nance – Faculty member and VLAB developer/user at the University of Alaska Fairbanks • Brian Hay – VLAB developer and manager at the University of Alaska Fairbanks • Ronald Dodge – Faculty member and VLAB developer/user at the United States Military Academy

3. Definitions • Virtualization • Simulating one type of computing resource with another, for example • Virtual memory - using disk as a RAM extender • Hardware abstraction layer - emulating an Intel CPU and chipset with software executing on a POWER CPU • Technique for making the sum of allocated computing resources appear greater than actual physical resources • Virtual computing environment (VCE) • Software that enables simulating one “complete” computing environment • Examples: VMware Workstation or ESX, Microsoft Hyper-V, Apple Parallels, Xen • Combines earlier “single resource type” virtualization approaches into an integrated whole • Today, the term virtualization is synonymous with the use of VCEs • Virtual machine (VM) • A single simulated computing hardware environment with network connections/services and installed system and application software (e.g., a virtualized workstation or server) • Configuration • Multiple VMs operating on a virtual network with or without network services (e.g., DHCP) and connected to or isolated from other networks

4. Resurgence of Virtualization • VCEs were widespread in the 1960s but faded by the early 1980s • IBM 370 and 3090 systems used virtualization to share a single mainframe between batch and online operating systems • IBM AS/400 operating in System 36 emulation mode was one of the last commercial implementations in that era • VCEs made a comeback in the late 1990s – Why? • Reduced cost disparity among desktops, minicomputers, and “big iron” • CPU cycles in abundance • Fast networks and consolidated storage • Reduced management complexity and total cost of ownership (TCE) • Usage scenarios: • Software testing (single machine) • Server consolidation • Desktop virtualization • Complex test environments containing multiple VMs on an isolated virtual network

5. What is a VLAB? • VLAB = Virtual computing laboratory • The virtual equivalent of a physical computing laboratory in an educational setting • Users access hardware and software resources without being “in the same room” as the physical resources • Shared multiuser resources (e.g., server clusters) emulate single-user resources (e.g., desktop computers) • Resources may be general-purpose or customized to specific educational needs • Resources are updated and reconfigured to match changing needs

6. Sample Educational VLABs

7. Common VLAB Usage Scenarios

8. Educational VLAB BenefitsThe Sales Pitch • Support learning at a distance • Reduced hardware and space costs • Efficient use of lab, site, and academic licenses • Minimal investment required of students • Simpler management (of some things) • Support for complex hardware/software environments • Specialized configurations per course or assignment • Multi-machine configurations with customized networks • Fast/simple setup and tear-down • A protected sandbox for “dangerous games”

9. UNM VLAB Implementations - Past • VLAB version 1 (2005-2008) • Rack of ordinary workstations connected to a SAN (see image on right) • Custom-developed Web portal + remote desktop protocol (RDP) • 42 users – one per computer • VLAB version 2 (2008-2010) • 4x Dell 2950s (32 CPU cores, 128 GB RAM) • 2 TB storage array • VMware ESX v3 + vCenter Lab Manager v3 • Ordinary web server for portal • Client console interface via ActiveX browser plug-in • Up to 100 users and scalable to more

10. UNM VLAB Implementation – Present • VLAB version 3 (2010-2013) • 3x Dell R910s (32 CPU cores, 512 GB RAM each node) • 6 TB storage array • VMware • ESX v4 • vCenter Lab Manager • Same web server and ActiveX console interface • Up to 400 users? • Version 3a (early 2013) • Migrate ESX to ESX 5.0? • Add a few more network interfaces?

11. VM-Based VLAB Architectural Overview

12. Quick VLAB Demo

13. VLAB Challenges – The Gotchas Acquiring, configuring, and supporting the VCE and its underlying physical resources Limited I/O efficiency Clunky user interfaces – portal and VM console More complex management (of some things) Student and faculty training and support

14. Current Network Issues • Acceptable performance requires • High-bandwidth and low-latency Internet connections at both ends – particularly problematic at the user end • Avoid I/O-intensive applications and features (e.g., complex desktop backgrounds, transparency, and motion-video) to minimize bandwidth requirements • Need high-performance connections among compute, storage, and network resources

15. Current User Interface Issues • VMware Lab Manager is misnamed! • Not really designed for an educational computing lab • Better suited to “professional” administration of virtual servers • All the shortcomings of a Web-based application, e.g., • Click, wait for refresh, click, wait for refresh, ... repeat ad nauseum • Lacks many standard desktop capabilities such as drag/drop, limited support for other such as cut/paste • Non-intuitive interface and terminology for end-users (e.g., workspace, template, configuration, clone, deploy, and undeploy) • “Atomic” actions from the student or faculty perspective require multiple steps with many “traps for the unwary”

16. Browser Support • Limited browser support • Internet Explorer with an ActiveX control works best • Firefox also works • Customized browser and firewall configuration • Enable/accept ActiveX download • Disable Internet Explorer protected mode • Add lab manger URL to trusted sites list • Open 90x ports

17. Library Management • Faculty and/or technical staff typically manage a library of VMs and configurations: • Standard VM provided to all users for general-purpose needs • Many courses use a single VM with all needed tools (e.g., Office + Visio + Visual Studio for a database course) • Some courses use multiple VMs alone or in a configuration • Library management issues: • Creating VMs and multi-VM configurations is complex and time-consuming • Complex classes (e.g., information assurance) may have dozens of VMs and multi-VM configurations • No tag, index, or search capabilities (so, is it really a library?) • Sharing VMs and configurations across classes and faculty is cumbersome – OUs are hierarchically related with no inheritance

18. User Management • User management issues: • Large classes and general-purpose lab access require managing hundreds to thousands of user accounts • Lab manager can be configured to use “internal” accounts – best avoided! • User account import from LDAP or Active Directory is straightforward though not for non-technical faculty and staff • Doesn’t use LDAP or Active Directory as a central authentication service • Implementing access controls requires management of groups, permissions, roles, and resource pools - beyond the skill of non-technical faculty • Accounts and groups must be defined and redefined from semester to semester

19. Resource Management and Overall VLAB Performance • RAM and disk are usually the most limited server resources • VMs must economize on both or overall VLAB performance suffers • Economization can be complex and may require usability or suitability-to-purpose compromises (e.g., older OS version or disabled features in newer OSs) • VM and template management • VM templates can be created and cloned to a library or workspace • Cloning creates long dependency chains and a trail of linked disk image and delta files that compromise performance (due to more complex disk I/O) • Shortening dependency chains • Improves VM and overall VLAB run-time performance • Requires lots of disk space for “full” clones • Increases administrative effort • In an Active Directory environment clones can’t be “on domain” unless their GUIDs are modified – which may break preinstalled software and services • VM existence and deployment duration • “Throw-away” VMs are best since they consume no resources when idle • But, they must be cloned from a library or template before each use – a delay • Many educational activities require longer-lived VMs and configurations that consume disk resources even when not deployed • Need to balance more immediate access but greater resource requirements of long-lived always-deployed VMs against the lower resource requirements but delayed access implied by cloning and deploying – available resources vs. user patience

20. Training and Support Requirements • There are two significant resource requirement increases when using a VLAB • User support for faculty and staff • Student and faculty training to navigate Lab Manager and deal with browser configuration issues – significant even for “technically-savvy” users • Additional training for faculty to self-manage libraries and users • Help desk support • Technical staff • Acquire, configure, and manage back-end resources • Acquire, configure, customize, and manage the front-end • Configure and manage “general-purpose” VMs • Perform class-related tasks that faculty are unwilling or unable to perform

21. UNM VLAB Implementation - Future • Primary drivers for change • VMware Lab Manager reaches end of life in June 2013 • Current hardware architecture has reached limits • Want to explore cloud-compatible approaches • Want greater access from non-Windows devices • Want an easier-to-use interface for students and faculty • Dell will supply new hardware for VLAB experimentation • Blade architecture with a 40 Gbps backplane • Fractional provisioning of CPU, storage, and network resources • We’ll partition it into at least two pieces to experiment with different VLAB architectural approaches • VLAB experimental version 4a • vCloud Director 1.5 • ESXi 5.0 • VMware View? • VLAB experimental version 4b • Windows Server 2012 • Hyper-V and Windows desktop virtualization services • Library, configuration manager, and portal – to be developed

22. Market and Technology Trends • Migrating to the cloud • Migrate what, precisely? • Migrate using which supporting technologies/products? • Private cloud, public cloud, or both? • End-user devices • Fixed workstations • Mobile workstations (keyboard, touchpad and/or mouse, and “large” screen) • Tablets (no/optional keyboard, touch screen, and “midsized” screen • Handheld (e.g., smart phone)

23. Market and Technology Trends - Continued • How to access virtual software, data, and services on end-user devices • As in current VLAB architecture – complete VM executing on a server with a remote console • Local execution of VMs (e.g., Windows 8 with HyperV or Parallels/BootCampon a Mac, VM downloaded or distributed on a flash drive) • Application streaming (e.g., Citrix, Microsoft App-V, VMware ThinApp) • Web applications (e.g., Office 365 and GoogleDocs) • Cloud storage (e.g., SkyDrive)

24. Market/Technology Trends - Observations • Virtualization and VLABs are here to stay for the foreseeable future • Virtualization support hardware is wired into CPUs • Virtualization is a standard feature of latest client OSs and will likely migrate to “lower” platforms like tablets and smart phones • Distance education is growing • Users expect anywhere/anytime access to every education resource • Back-end tools and infrastructure for application and desktop virtualization deployment are well-developed • Nearly mature technology • Available from multiple vendors • Still some variation in support for host hardware and OS environment • Rapidly migrating into the cloud • Application virtualization and software as a service are also well-developed, though there’s room for improvement and standardization • Mixed environments that deliver resources via a combination of methods are feasible (e.g., Office via SAS, Adobe Creative Suite via app streaming, and developer toolkits encapsulated within complete VMs) • Using, administering, and supporting them may be overload for both users and technical staff

25. More Observations • Cloud-based VLABs (VLABs as a service) are a natural progression forward • Management and security issues will become more important than technology and accessibility issues • App-streaming and stateless-desktops will probably be first, followed later by stateful desktops and multiple-VM configurations • Streamed apps and virtual desktops will need to integrate seamlessly with cloud storage • Lab administrators will have to determine which apps/desktops/services can be supported on which clients • Some software and services will easily move from desktop to laptop to tablet to phone (e.g., many office apps) • Some software and services will be limited to devices with sufficient screen size and I/O flexibility (e.g., users can’t feasibly interact with current programming toolkits via a tablet or phone)

26. Current VM-Based VLAB Infrastructure Alternatives • VMware ESX + vCloud + View • Industrial strength product with a long track record • Strong support for Windows and UNIX VMs and clients • Apple client support is a recent addition • Portal environment?? Unclear what is Lab Manager successor – possibly third-party solutions (e.g., LiquidwareProfileUnityFlexApp) • Strong support for virtual networks and multiple-VM configurations • Windows Server 2008/2012Microsoft Hyper-V • Hyper-V bundled with server OS and embedded in Windows 8 • Strong support for Microsoft clients/servers and UNIX servers • Adequate support for UNIX and Apple clients via RDP • Portal environment can be provided through IIS and bundled desktop virtualization tools – unclear how well they fit an educational VLAB environment • Support for virtual networks and multiple-VM configurations? • Apache Virtual Computing Lab • Linux/Xen virtualization and VM deployment – Open source • Strong support for Linux and Windows VMs • Strong support for UNIX, Windows, and Mac clients via RDP • Apache web server and tool-kit for portal development – some templates provided through IBM • Weak support for virtual networks and multiple-VM configurations

27. Sample Cloud-Based VLAB Solutions • IBM Cloud9 • Xen-based desktop virtualization • Relatively complete solution • Dell Virtual Labs • Suite of products/services targeted to educational uses • App streaming products/services use Citrix XenApp or VMware View infrastructure with thin clients • Integration of Dell hardware and setup support services with third-party infrastructure • Nimbus • Open-source Xen-based VM deployment to third party cloud providers • Targeted to scientific and high-performance applications • GENI • Xen-based VM deployment to local and remote server clusters (of member institutions) across configurable/experimental I2/LR connections • Targeted to research applications for next-generation network and distributed software architectures

28. Summary VLABs do deliver on their benefits, but not without significant costs and some limitations Current VLAB technology can’t deliver the same experience to all users all of the time as sitting in front of a directly-connected console There are multiple implementation alternatives, but nothing yet comprises and “out of the box” solution for local installation IBM Cloud9 is the best-developed cloud-based VLAB service Successful VLAB implementations require lots of training, user support, and technical staff resources