We look at two main approaches in this chapter: emulation and virtualiza-tion. To some extent these two terms are interchangeable, and many forms of emulation involve a certain amount of virtualization.
Emulation refers to the idea of creating an environment (as a running program) that behaves in terms of input and output like the target system. For example, the dosemu program is an emulation of a DOS system. Although it is just a program running under Linux, it responds to interactions from users just as a real DOS system would. Wine's Windows emulation behaves slightly differently. Strictly speaking, Wine's approach is not emulation (indeed the name Wine stands for "Wine is not an emulator'')
because there is not a process running that pretends to be a Windows system. What Wine does is intercept calls by Windows programs to the operating system and libraries and replace them with calls to its own infrastructure, which results in the right behavior.
Virtualization implies (at least) that a virtual machine exists: in other words that there is a software environment that emulates (at least some aspects) of a real hardware machine. If you can emulate an entire hardware platform, then you are doing virtualization. The term is used most often in cases where there is also some mechanism for transferring some of the resources directly to the virtual environment, which is a requirement that the virtual machines must provide to ensure decent performance.
It is possible to emulate an entire hardware platform. For example, the bochs project emulates an entire PC environment. You can then install an operating system into this virtual PC. The operating system thinks that it is being installed into real hardware. When you start the emulator, the guest operating system boots within it and you have a virtual machine running on top of your real one.
This is the approach used by bochs, VMware, QEMU, and Xen, but there are very significant differences in how they work. To get decent performance in a virtual machine, there needs to be a way to share some of the real hardware resources with the guest operating system. As noted previously, the term "virtualization" is usually used with the implication that as well as providing a virtual machine capability, some of the resources of the real hardware are "virtualized" and offered to the guest operating system. This is not the case with bochs, which is why it is so slow, although it provides an entire emulated PC environment. However, bochs can run on any Unix system and on any hardware platform. VMware, QEMU, and Xen do have the ability to virtualize real resources and hence provide better performance. To be able to virtualize real system resources in this way requires that the emulated system have the same architecture as (or in the case of Xen, very similar to) that of the real hardware.
The Xen virtualization system is creating a great deal of interest at the moment, as it is a way of running multiple virtual systems on a single server with minimal loss of performance. It also allows running systems to be migrated from one physical server to another with downtime measurements of only fractions of a second. This makes it a serious competitor with VMware's high-end server products.
An operating system can run under Xen in two modes: paravirtualized and fully virtualized (the latter is more accurately described as "hardware-assisted virtualization"). For paravirtualization, the "guest system'' needs to be aware that it is running on top of Xen. For hardware-assisted virtualization, the underlying hardware has to be a processor with the new virtualization extensions: Intel's VT or AMD's AMD-V (formerly known as Pacifica Technologies).
Was this article helpful?