If it looks like a duck, walks like a duck, and quacks like a duck, more than likely, it's a duck. With a computer, not so much. It could be a virtual computer.

Consider a company which produces workflow software supported under Windows XP, Vista, Linux, and Mac OSX. It's time for a new release. All of the supported flavors can be tested on a single computer. The idea is to run an operating system, say Vista, on the computer, and test each product flavor under its own virtual machine running XP, Linux, or whatever. You'd like to run repeated tests under each OS. Each test created workflow steps, filling the database with all kinds of who knows what. No problem, just restore the virtual machine to its initial state and begin the next test. no reboot necessary! No setup necessary!

Next, you're part of a group building a custom, embeddable, parallel processor board. The prototype board isn't physically ready yet, but you can start producing and testing its software, because they can run a virtual version of the board on your computer.

Finally, consider a machine-independent language, like Java. You want to implement a new language feature. Used to be, language compilers converted high-level languages directly to machine-specific instructions, but Java is compiled "just in time" from intermediate instructions (Java Byte Code) to native code by the Java Virtual Machine (JVM). It's the virtual machine that's adapted behind the scenes to different platforms and operating systems. So you can implement your new feature, verify it once, and be relatively sure it will run on all of the supported platforms. (...at least in theory. It is still a good idea to test it on all the platforms, which brings us back to the first case, above.) The .NET CLR operates in a similar manner. A benefit of the JVM and CLR is that, since system calls are done by the virtual machine, multiple, diverse languages can be built that can take full advantage of the system calls. Which is why CLR stands for Common Language Runtime.

In the first case, above, you're running application code on your computer's processor, but you're emulating different operating systems. In the second case, you're emulating the entire processor board. In the third, you have an entirely virtual environment - one whose physical counterpart has never been built. These are aspects of virtualization, the topic of a course to be offered this summer at Loyola's Columbia Graduate Center. Veteran instructor Patrick Stakem intends to provide students with hands-on experience building and using virtual machines, much as he does himself at the Goddard Space Flight Center. You'll even come to understand the hypervisor.

Hypervisor? that's a hip term for the virtual machine monitor (VMM), the software that enables your various virtual machines to run concurrently on a physical host computer. Hypercalls, or calls to the hypervisor, are needed to stop and start the virtual machine, read the system clock, perform disk I/O, and perform other essential functions. The best-known example of a hypervisor is the VMWare product.

Recently, multicore hardware has made possible the ability to run a different operating system on each core, concurrently, with a distributed hypervisor. This allows for the virtualization of real-time operating systems - those having to offer guaranteed millisecond or less response time to incoming events or process information with hard deadlines. Just as important, virtualization is one of the technologies critical to much of Cloud Computing, the ability for applications and data to be distributed throughout the Internet "cloud."

Virtualization is the topic of a summer Special Topics course to be taught by Patrick Stakem, an affiliate instructor in the graduate program and a software engineer at the Goddard Space Flight Center. Students will gain hands-on experience implementing and using virtualization. His April 28 lecture will preview the topic; see the box, above.