Virtual Machines & VMware, Part I December 21, 2001 By: Jay Munro Ever want to try out a new operating system on your pc without trashing your existing Operating System? Got a legacy application that won’t run on your current OS? Are you a developer who needs to test your code on a number of platforms? Would you like to test distributed applications on a network without requiring a server farm? Find out what companies like Symantec and Merrill Lynch know--you can do these tasks with a Virtual Machine (VM) on a single PC. A Virtual Machine is a software environment that encapsulates one or more Operating Systems and applications that actually run inside or "under" the VM. The OS can’t tell the difference between operating in a VM or in a "real" machine. Within a Virtual Machine, you can do almost anything you can do with a real PC, with complete safety. Furthermore, the type of virtual machine we’ll soon discuss is encapsulated in a file that can be moved from one PC to another, without worrying about hardware compatibility. Virtual machines are isolated entities, and the security of a host is not threatened by an errant application. A virtual machine can let you use a given platform’s operating system software under another OS on the same platform, such as running a copy of Linux in a VM on your Windows 2000 PC. Virtual machine files can be stored on a server, and used more than one person, so a team of developers can use a common configuration to test. In this article we will look at where Virtual Machines came from, how they work, how they differ from software emulators, and finally a look at the new version of VMware Workstation 3.0 for Windows. VMware is an industrial strength virtual machine company with three levels of VM products: VMware Workstation, VMware GSX server, and VMware ESX server. We’ll be concentrating on the Workstation for Windows product, but we’ll also discuss a few of the differences between the products. The idea of a virtual machine is not new--its roots actually go back almost to the beginning of computing itself. Initially, the concept of a virtual machine came about in the 1960’s on mainframes as a way to create less complex multi user time share environments. As described by Melinda Varian’s canonical paper "VM and the VM Community: Past, Present, and Future", a time sharing system was developed by a group of MIT programmers, working with equipment donated by IBM. The system, "Compatible Time Share System" or CTSS, was initially developed in 1961 and evolved over the years as the example of how to do time sharing. CTSS was designed much like current multitasking systems, doling out processing time in scheduled slices. The system provided a supervisory program that controlled resources, and scheduled time shares for foreground and background tasks. The key to its operation was the supervisor program’s control of Trap Interrupts. By trapping interrupts, the control program was able to isolate the users or processes from each other. As the systems developed, changes in the hardware were made to support relocation of memory, a key process to facilitating a virtual memory system. Without the ability to relocate (page) memory, entire programs would need to be swapped in and out to active memory address space. With virtual memory, a big performance boost could be realized. In the 1960’s, the concept of a "virtualizable machine" was developed, and virtual machine technology became a very popular subject of study, and the key focus of user organizations and conferences in the late 60’s and 70’s. For some deeper background, in late 1964, a project at MIT called CP-40 (Control Program for IBM System/360 Model 40 mainframes) really turned the corner on virtual machines. The idea was to create an operating system that would let each mainframe user have their own IBM System/360 virtual machine (which was originally called a pseudo machine). The subsequent release of a single user virtual environment running atop CP-40 called CMS (Cambridge Monitor System) was the beginning of a long line of IBM VM operating system products. Later CMS would be called Conversational Monitor System, and it worked in conjunction with CP on IBM System/370 systems. Though IBM was reluctant to invest in VM technology in the 60’s and 70’s, it became fairly successful in the 80’s, and they still sell VM systems today. According to Mendel Rosenblum PhD, VMware’s Chief scientist and co-founder, standard college textbooks on computer architecture do not have a discussion of the virtualization of processors. Virtual Machines were also not in Intel’s mind as they designed the 64bit IA64 chip architecture, as the processors (like Itanium and the upcoming McKinley) are not completely virtualizable. Rosenblum offers a tongue in cheek theory that maybe the engineers had not been exposed to virtual machine technology in college, so they never considered implementing such capability. During the 1990’s, at Stanford University, work was being done on designing and building scalable multi-processor machines-- ones that could scale to 1000 or more processors. Rosenblum and a group of graduate students were tackling the problem from the operating system point of view, and came on the idea of building a virtual machine monitor (VMM) with an existing operating system, rather than designing one from scratch. In talking with various software and operating system development companies, the feedback Rosenblum received was favorable on the idea, but he had trouble securing development assistance from those companies. Since Rosenblum’s team was going to use Microsoft operating systems, the idea of having Microsoft work on the project in conjunction with their operating systems seemed like the best idea. However, rather than asking Microsoft to help integrate a virtual machine directly into the OS, Mendel came up with the idea of running a VMM under the Microsoft operating systems, without requiring core OS modifications. As an extension to that concept, Mendel and his graduate students started experimenting with creating a virtual machine monitor that can also run other commodity operating systems within a VM for use on single or multiprocessor systems. Since many of the graduate students had friends in entrepreneurial enterprises in nearby Silicon Valley, they started kicking around the idea of starting a company. The initial research and development at Stanford was targeted at building VMM’s on a server. However, the added complexity of the logistics of partnering with server companies soon gave the team the realization that they should start smaller, so they scaled back to a workstation platform to work out the design. VMware Workstation was born, and a company as well. Before we get too far, we should take a second to define some terms. A Virtual Machine (VM) is defined by Popek and Goldberg (in their paper "Formal requirements for virtualizable third generation architectures," Communications of the ACM, Vol 17, July 1974) as an "efficient, isolated duplicate of a real machine". A real machine has a number of systems that it provides to an operating system and applications for use. Starting at the core, the CPU and motherboard chipset provides a set of instructions and other foundational elements for processing data, memory allocation, and I/O handling. On top of that are hardware devices and resources such as memory, video, audio, disk drives, CDROMs, and ports (USB, Parallel, serial). In a "real machine", the BIOS provides a low level interface that an operating system can use to access various motherboard and I/O resources. With a real machine, when an operating system accesses a hardware device, it typically communicates through a low-level device driver that interfaces directly to physical hardware device memory or I/O ports. The effective opposite of a real machine is an emulator. An emulator will reproduce everything from the CPU instructions to the I/O devices in software. An emulator can provide cross-CPU operation, such as running Windows software on a Mac. Unfortunately, an emulator takes a performance hit since it must translate every instruction, function call, or data transfer. In addition, an emulator is quite complex, as it needs to emulate most if not all of the CPU instructions. The functionality and abstraction level of a Virtual Machine lies between a real machine and an emulator. A virtual machine is an environment created by a Virtual Machine Monitor (VMM). The VMM can create one or more VM’s on a single machine. While an emulator provides a complete layer between the operating system or application and the hardware, a VMM manages one or more VMs, with each VM providing facilities for an application or "guest OS" to believe it’s running in a normal environment with access to physical hardware. Instead, when applications or guest OSs execute low-level instructions that inspect or modify hardware state, they appear to the app or OS to be directly executing on the hardware, but are instead virtualized by the VM and passed to the VMM. For traps or interrupts occurring at the application level, they can pass directly to the VMM, which in turn interacts with the hardware. In the case of VMWare, we’ll see that its VMM isn’t in direct control of the hardware, but actually runs atop a primary or "host" OS for low-level hardware I/O control, while it also plants a low-level driver in the host OS to handle various low-level VM management chores and certain hardware interactions.