System Virtualization
vir·tu·al - adj. - Computer Science Created, simulated, or carried on by means of a computer or computer network.
Computer system virtualization can be thought of as "a framework or methodology of dividing the resources of a computer into multiple execution environments, by applying one or more concepts or technologies such as hardware and software partitioning, time-sharing, partial or complete machine simulation, emulation, quality of service, and many others."[1]. What this means is that virtualization can make one computer work as multiple computers (or Virtual Machines or VMs), thereby running multiple disparate OSes or multiple instances of the same OS, at the same time, on the same box, without rebooting. Virtualization is a general term and has been the moniker for many systems. They were first developed and used in the 1960s, with the best-known example being IBM's VM/370. At the time, general-purpose computing was the domain of large, expensive mainframe hardware, and users found that Virtual Machine Monitors (VMMs) provided a compelling way to multiplex such a scarce resource among multiple applications[2]. IBM designed their virtual machine systems with the goal that applications, even operating systems, run in the virtual machine would behave exactly as they would on the original hardware. However, with the advent of the PC, VMMs disappeared to the extent that computer architectures no longer provided the necessary hardware to implement them efficiently. The capabilities of modern operating systems and the drop in hardware cost-the very combination that had obviated the use of VMMs during the 1980s-began to cause problems that researchers thought VMMs might solve. Less expensive hardware had led to a proliferation of machines, but these machines were often underused and incurred significant space and management overhead. And the increased functionality that had made operating systems more capable had also made them fragile and vulnerable.
Approaches to Virtualization Design
As a layer of software, VMMs build on a lower-level hardware or software platform and provide an interface to higher-level software. In a traditional or full virtualization, the virtual hardware exposed is functionally identical to the underlying machine provided by a Virtual Machine Monitor (VMM). This software-abstraction layer partitions a hardware platform into one or more virtual machines where typically each of these virtual machines is sufficiently similar to the underlying physical machine to run existing software unmodified.[3]. The VMM decouples the software from the hardware by forming a level of indirection between the software running in the virtual machine (layer above the VMM) and the hardware. This level of indirection lets the VMM exert tremendous control over how guest operating systems - operating systems running inside a virtual machine - use hardware resources. So for example, in a conventional system the resident OS would control memory access in a non-virtualized system, whereas memory access in a virtualized system would be controlled by the VMM. Finally, a CPU architecture is virtualizable if it supports the basic VMM technique of direct execution - executing the virtual machine on the real machine, while letting the VMM retain ultimate control of the CPU[4] . Implementing basic direct execution requires running the virtual machine's privileged (operating- system kernel) and unprivileged code in the CPU's unprivileged mode, while the VMM runs in privileged mode. Thus, when the virtual machine attempts to perform a privileged operation, the CPU traps into the VMM, which emulates the privileged operation on the virtual machine state that the VMM manages. Although full virtualization has the obvious benefit of allowing unmodified operating systems to be hosted, it also has a number of drawbacks. This is particularly true for the prevalent IA-32, or x86, architecture and support for full virtualization was never part of the x86 architectural design.
Types of VMM
An operating system consists of instructions to be executed on a hardware processor. When an operating system
is virtualized, some portion, ranging from none to all, of the instructions may be executed by underlying software.
However the definition of a VMM does not specify how the VMM gains control of the VM to interpret instructions
that cannot be directly executed on the processor. Excluding a complete software interpreter machine (CSIM)
and a real machine (neither meet Goldberg's definition of a virtual machine[3]), there are two different types
of VMMs that can create a virtual machine environment, namely Type I and Type II[5]. A Type I VMM (also
known as "hypervisors") runs directly on the machine hardware (See figure).
It is a precise
operating system or kernel that has mechanisms to support virtual machines. It must perform scheduling and resource \
allocation for all virtual machines in the system and requires drivers for hardware peripherals. To support a Type I VMM,
a processor must meet three virtualization requirements: First, the method of executing non-privileged instructions
must be roughly equivalent in both privileged and user mode. For example, a processor cannot use an additional bit
in an instruction word or in the address portion of an instruction when in privileged mode. Second, there must
be a method such as a protection system or an address translation system to protect the real system and any other
VMs from the active VM. Third, there must be a way to automatically signal the VMM when a VM attempts to execute
a "sensitive instruction" . So for Type I VMMs (that access hardware directly), the set of requirements to enable
virtualization entirely depends on the hardware. VMware ESX, Xen, and Windows virtualization would be examples of
a Type I VMM. A Type II VMM runs as an application on a host operating system and relies on the host OS for
memory management, processor scheduling, resource allocation, and hardware drivers (See figure).
It provides
only virtualization support services. To support a Type II virtual machine a processor must meet all of the
hardware requirements for the Type I VMM listed above. In addition, the following software requirements must be
met by the host operating system of the Type II VMM: First, the host OS cannot do anything to invalidate the
requirement that the method of executing non-privileged instructions must be roughly equivalent in both privileged
and user mode. Secondly, primitives must be available in the host OS to protect the VMM and other VMs from the
active virtual machine. When the virtual machine traps because it has attempted to execute a sensitive instruction,
the host OS must direct the signal to the VMM. Therefore, the host OS needs a "primitive" to perform this action.
And finally, the host OS needs a mechanism to allow a VMM to run the virtual machine as a sub-process. To summarize,
since a Type II VMM does not have direct access to hardware, the requirements to enable virtualization are
actually at the OS interface. JavaVM and Microsoft's Dot Net environment would be examples of a Type II VMM.
Often, if a processor does not meet the Type I or Type II VMM requirements, it can still implement a hybrid
virtual machine monitor (HVM) (See figure).
A hybrid VMM has all of the advantages of normal VMMs and avoids
the performance penalties of a CSIM. However, an HVM and a VMM differ in that an HVM interprets every privileged
instruction in software, whereas a VMM may directly execute some privileged instructions. An HVM has less strict
hardware requirements than a VMM in two ways. First, the HVM does not have to directly execute non-sensitive
privileged instructions because they are all emulated in software. Second, because of the emulation, the HVM
need not provide additional mapping of the most privileged processor mode into another processor privilege level.
However, increased interpretative execution usually lowers the performance of an HVM relative to a VMM[6].
Microsoft's Virtual PC / Virtual Server VMM is an example of a HVM. The HVM runs in ring 0 'beside' the
Windows kernel. When executing a virtual machine the VHM essentially backs the Windows OS state off of the CPU
and runs the virtual machine state. However any access to hardware resources is routed through the Windows OS[7].
Paravirtualization
The above exploration of the different VMMs may seem unduly complex; it is primarily a result of the prevalent IA-32 or x86 architecture. Support for full virtualization was never part of the x86 architectural design. However several techniques address how to implement VMMs on CPUs that can't be virtualized, the most prevalent being Paravirtualization. With paravirtualization, the VMM builder defines the virtual machine interface by replacing nonvirtualizable portions of the original CPU instruction set with easily virtualized and more efficient equivalents. Although operating systems must be ported to run in a virtual machine, most normal applications run unmodified. This approach can provide extremely high-performing virtual machines for example by eliminating virtualization overhead such as traps on privileged instructions. As an example the virtual monitor can present the host operating system with an intelligent Network Interface Card (NIC) interface with support for DMA-based sending of packets, even though the NIC on the real system lacks this capability. Sending packets is then done entirely by the virtual monitor (which also process the NIC interrupts). Since delivering interrupts to the host operating system is expensive, performance can improve. As an example, a brief explanation of one of the first paravirtualizations was in the form of the Denali VMM[8] follows.
The interface the Denali VMM provides for the virtual machines is not an exact replica of the system hardware. Not providing an exact replica requires the operating system and software running with that operating system to be modified to run in the Denali environment. However, by not providing an exact replica, Denali has developed methods that substantially improve performance over fully virtualized systems in the following ways. Idle loops are actually are replaced by a new "idle" instruction. When the virtual machine calls the idle instruction a context switch to the VMM occurs so that it can schedule other virtual machines. In addition interrupt queuing is used to defer interrupt processing until the intended VM has been context switched in as the current process. Because supporting virtual memory between the VMM and the virtual machine is extremely difficult, especially on architectures that are not designed to be virtualized, Denali does away with virtual memory by constraining each virtual machine to a single address space. Denali does away with the BIOS by providing system information in read-only virtual registers. And finally, Denali provides no specialized access to devices on the physical system. Instead exposing only a small set of "generic" devices, such as a network interface card, serial port, a timer, and keyboard. This greatly improves the performance of the guest operating systems-rather than going through complex drive I/O routines to send a network packet, for example, Denali exposes a virtual I/O instruction that handles everything for the guest OS.
Hardware Assisted Virtualization
As previously noted virtualization on the x86 architecture has required seemingly unnecessary complexity due to its inherent lack of support for virtual machines. However, new extensions to the x86 should remedy this problem and as a result, can support a much simpler VMM. Further, the extensions succeed in making the x86 architecture classically virtualizable. Both leading chip manufacturers, Intel and AMD , have rolled out these virtualization extensions in current processors. Intel calls its virtualization technologyVT-x, previously codenamed Vanderpool. AMD's extensions go by the name AMD-V, previously Secure Virtual Machine (SVM) and codenamed Pacifica. While Intel VT-x and AMD-V are not entirely equivalent, they share the same basic structure. Intel VT-x introduces new modes of CPU operation: VMX root operation and VMX non-root operation[9]. One can think of VMX root operation being similar to previous IA-32 operation before VT-x and is intended for VMMs ("host" mode), while VMX non-root operation is essentially a guest mode targeted at virtual machines. Both operating modes support execution in four privilege rings - thus facilitating clean layering off VMMs and guest OSes. In conclusion, virtualization has numerous advantages including providing better security by compartmentalizing environments, increasing reliability and availability by not allowing a software failure in one VM to affect another, lowering costs through consolidation, naturally facilitating load-balancing, and easily providing support for legacy applications. In the past it was difficult to circumvent the idiosyncrasies of the x86 architecture. Techniques such as paravirtualization provided good virtualization support but not without their drawbacks. With the advent of hardware assisted virtualization however those days seem to be numbered.
Conclusion
Open licensing, a viable a collaborative framework, and the modular nature and manufacturability of software applications, have proliferated OSS to where even the harshest naysayers have
conceded to its success. With greater acceptance by established software companies and the increasing potential for individual gain, OSS seems to have established itself as a potentially
viable alternative to proprietary software offerings.< /p>
[1] K. R. Lakhani and R. G. Wolf, "Why hackers do what they do: understanding motivation effort in free/open software projects," Perspectives on Free
and Open Source Software, vol. MIT Press, Cambridge, MA, 2005.
[2] M. Csikszentmihalyi, "Flow: The Psychology of Optimal Experience," New York: Harper and Row, 1990.
[3] J. Lerner and J. Tirole, "Some simple economics of open source," Journal of Industrial Economics, vol. 50, pp. 197-234, Jun 2002.
[4] S. A. Hissam, C. B. Weinstock, D. Plakosh, and J. Asundi, "Perspectives on Open Source Software," TECHNICAL REPORT CMU/SEI-2001-TR-019 2001.
[5] E. S. Raymond, "The Cathedral and the Bazaar," O’Reilly Books 1999.
[6] T. O'Reilly, "Lessons from open-source software development." vol. 42: ACM, 1999, pp. 32-37.
[7] J. W. Paulson, G. Succi, and A. Eberlein, "An empirical study of open-source and closed-source software products," Software Engineering, IEEE Transactions on, vol. 30, pp. 246-256,
2004.
[8] B. Behlendorf, S. Bradner, J. Hamerly, K. McKusick, and T. O'Reilly, "Open Sources Voices from the Open Source Revolution," O'Reilly ∓ Associates, Inc, 1999.
[9] J. Feller, B. Fitzgerald, S. A. Hissam, and K. R. Lakhani, "Perspectives on Free and Open Source Software," pp. 93 - 112, 2005.
[10] T. J. Halloran and W. L. Scherlis, "High Quality and Open Source Software Practices," Carnegie Mellon University, 2003.
[11] SourceForge.net, http://sourceforge.net/, 2008.
[12] A. R. Jeffrey, H. Il-Horn, and A. S. Sandra, "Understanding the Motivations, Participation, and Performance of Open Source Software Developers: A Longitudinal Study of the Apache
Projects." vol. 52: INFORMS, 2006, pp. 984999.
[13] F. Machlup, "An Economic Review of the Patent System," Study No. 15, Subcomm. Patents, Trademarks and Copyrights of the U.S. Senate Judiciary Comm., pp. 1-2, 20-21, 44-45, 76-80,
1958.
[14] S. Krishnamurthy, "An Analysis of Open Source Business Models," http://faculty.washington.edu/sandeep/d/bazaar.pdf, 2003.
[15] C. Daffara, J. M. González-Barahona, and E. Humenberger, "Free Software / Open Source: Information Society Opportunities for Europe?,"
http://eu.conecta.it/paper/brief_history_open_source.html, 2000.
[16] LinuxDevices.com, "Embedded Linux Market Survey," http://www.linuxdevices.com/articles/AT8693703925.html, 2004.
[17] D. A. Wheeler, "Why Open Source Software/Free Software (OSS/FS, FLOSS, or FOSS)? Look at the Numbers!," http://www.dwheeler.com/oss_fs_why.html, 2007.
[18] S. Shankland, M. Kane, and R. Lemos, "How Linux saved Amazon millions," CNet News Inc., vol. http://investor.com.com/How+Linux+saved+Amazon+millions/2100-1001_3275155. html, 2001.
[19] S. Shankland, "Verizon switches programmers to Linux," CNet News Inc., vol. http://www.news.com/2100-1001-949913.html, 2002.