Abstract - The use of virtual machines to deploy software in courses and/or laboratories is discussed. Virtual machine software, such as VMWare, can be installed on every computer and then students can run various operating system images. This allows a separation between the ‘application software’ and the hardware platform. For example, a course instructor can prepare a disk image file with an operating system and a suite of commercial or free software. The virtual machine could then be installed on laboratory computers or distributed to the students to run from USB devices. Regardless of what type of computer or operating system the students are using, they will all see and use a consistent computational interface. The paper includes a discussion of the requirements of this technology and various models of how it may impact courses utilizing computers.

Introduction

The use of software has become prevalent in engineering education. Standards have arisen that make software easy to use on a variety of hardware platforms and Operating Systems (OSs). However, this does not mean that the process is seemless. For example, as newer versions of OSs are introduced, or hardware standards become obsolete, older software will often cease to function. Another common problem is the dependence upon other professionals, such as Information Technology departments, who are tasked to maintain the software, but are not familiar with it. In other cases we may want to distribute software to students, but find the configuration issues for each student’s computer to be too varied. Virtual Machines (VMs) have been examined as a tool to help overcome or minimize some of these issues.

A VM emulates computer hardware so that other OSs may be installed and used. A simple example is shown in Figure 1 where a host operating system (for example OS/X) runs on regular physical hardware. It takes care of hardware interfaces such as sound, video, disks, USB devices, and keyboards. The OS also runs programs as directed by the user. In simplistic terms a virtual machine is just another program running on the host computer. As a bare minimum the VM only provides Basic Input Output System (BIOS) functions. However other OSs, and software applications can be installed. As the figure suggests, the guest and host operating systems do not have to be the same. The virtual machine often exists as a disk image file on the host computer.

There are a variety of reasons for using this type of software architecture including,

• to create a ‘virtual sandbox’ for software testing (e.g. software development)

• to isolate OSs on one machine for efficiency (e.g. server security)

• to run multiple VMs on one machine for hardware sharing (e.g. web servers)

• to allow programs from multiple OSs to run side by side (e.g. Linux/Windows)

• to allow software portability (e.g. hardware independence)

As expected, there are a number of negative issues involved with VMs, as listed below.

speed - there is a loss of computational efficiency when using virtual machines. When the guest and host processor are the same, the guest OS typically runs at half (or less) of the maximum possible speed possible on the hardware alone.

hardware interface - the VM is often unable to take full advantage of special hardware acceleration features, such as 3D graphics acceleration.

To recap, the abstraction of hardware does mean that a VM will seem to be on the same computer, regardless of where it is running. For example the guest OS may always see an S3 video driver, regardless of the actual video hardware (ATI, NVidia, etc.). However this eliminates the benefits of accessing the hardware directly. There are a few exceptions to this, with the most notable being USB devices that can be easily connected to the VM.

A screen capture of a VM is shown in Figure 2. The guest OS is Windows XP. The host OS shown is also Windows XP. The VM is running industrial Programmable Logic Controller (PLC) software that is very resource intensive. This software communicates through the host OS to I/O hardware over ethernet. In a laboratory course the students are using the same VM, but the host OS is Windows 2000. The host OS could easily be any other supported by the VM.

There are multiple VMs available, both commercial and open source. The author has extensively used VMWare [1] and Qemu [2] but is not advocating a particular VM. VMWare was chosen for much of this work because it runs relatively quickly, is well supported well across multiple host OSs, and has a ‘free player’ that allows others to install the software without purchasing it. The VM software should be downloaded and installed on the target platforms. One or more VM disk images can be stored on fixed or portable drives, and then executed with the VM.

To simply test the systems a variety of operating system images are available. For example the VMWare website contains samples of (free) OSs such as Linux, ReactOS, and FreeDOS. It is also possible to install an OS from the beginning by inserting the installation CD in the CD player, starting the virtual machine, and following the normal procedure for installing the OS. The VM exists as a set of files on the host OS. These can be moved (or copied) and used from other media including hard drives, USB drives, and network drives. One of these files will be very large and contain a copy of the disk drive image. Files larger than 4GB are not allowed under the FAT32 file system commonly used on most portable storage devices, so it might be necessary to format it in a newer format such as NTFS. It was found that Universal Serial Bus 2 (USB2) and Firewire devices were fast enough to provide a usable computing environment.

Using a Virtual Machine for Laboratory Support

The popular axiom is ‘if it ain’t broke, don’t fix it’. As we know, small changes will often ‘break’ computing systems, including software. However, within academic and technical environments the drive to change equipment is constant. In the author’s school the computers are reimaged with software every semester by a laboratory supervisor. This normally comes with a variety of changes and despite our best efforts there are frequently issues with software that has been reinstalled or reconfigured. Most of these problems arise because of the complexity of installing a combination of all applications. Moreover, they rely heavily upon the underlying OS. A VM can be used to install an OS and a limited set of software for use in a laboratory. These images are then copied to the machines when they are needed. A few examples where these images would have value are listed below.

obsolescence - older software could still be run in the original environment. For example software that was written for an early version of DOS or Windows 3.11 could be used on current computers in a VM running windows 3.11.

security - the virtual machines can have additional layers of protection, such as Network Address Translation (NAT), to provide a greater level of protection from worms and cracking attempts.

maintenance - the VMs are generally more isolated, but in the event that there is a security breach, corruption, or configuration issues, the VM is simply replaced with the original VM. [3]

virtual laboratories - multiple VMs can be run on a single machine to provide the equivalent to multiple computers. This has been done to simulate networking laboratories without a large number of physical computers. [4]

The industrial control software shown in Figure 2 is currently being used to support undergraduate and graduate courses at Grand Valley State University. This software is very complex to install and configure. However, now that it has been installed in the VM, it is ready for use each semester. Even if other software (including VMWare) is changed on the machine it will remain unaffected. And, as new hardware and OSs are added to the laboratory, there is no need to disturb a working system. It is worth noting that if the software licenses permitted, it would be trivial to distribute this software, in working condition, to our students.

Using a Virtual Machine for Software Distribution

In some cases we want to distribute software to our students. If this is done by handing them installation disks we face a variety of problems including multiple OSs, multiple hardware platforms, and basic installation problems. When the software installation is more complex the problems increase accordingly. The reaction is that ‘it would be easier to do it yourself’. A very compelling alternative is to create a virtual machine with all of the software already installed. An instructor may also be motivated to include additional notes, code examples, drawings, etc. This is already reasonable using virtual machines loaded with a free OS such as Linux. Once the virtual machine has been constructed and tested, it is distributed to students. If the size is small enough it can be run from a flash memory drive. The benefit to our students are that they are able to move quickly to the use of the software, avoiding needless delays and frustration. They all see the same interface so the tutorials and assignments can be uniform.

Currently most students are carrying flash memory drives with approximately 1GB of memory. Portable 100GB USB2 hard drives are available for under $100 and would be able to store a large number of virtual machines, documentation, students, and still have room for personal files.

Jack, H., “Work In Progress - The Use of Virtual Machines in Laboratories”, The Frontiers In Education Conference, Milwaukee, Wisconsin, October 2007.

Introduction

Using a Virtual Machine for Laboratory Support

Using a Virtual Machine for Software Distribution

Conclusions

References