Implementation Levels Of Virtualization

Virtual Machines and Virtualization of Clusters and Data Centers

3.1 Implementation Levels Of Virtualization

3.1.1 Levels of Virtualization Implementation

3.1.1.1 Instruction Set Architecture Level

3.1.1.2 Hardware Abstraction Level

3.1.1.3 Operating System Level

3.1.1.4 Library Support Level

3.1.1.5 User-Application Level

3.1.1.6 Relative Merits of Different Approaches

3.1.2 VMM Design Requirements and Providers

3.1.3 Virtualization Support at the OS Level

3.1.3.1 Why OS-Level Virtualization?

3.1.3.2 Advantages of OS Extensions

3.1.3.3 Disadvantages of OS Extensions

3.1.3.4 Virtualization on Linux or Windows Platforms

3.1.4 Middleware Support for Virtualization

3.1 IMPLEMENTATION LEVELS OF VIRTUALIZATION

  • Virtualization is a computer architecture technology by which multiple virtual machines (VMs) are multiplexed in the same hardware machine.
  • The purpose of a VM is to
    • enhance resource sharing by many users and
    • improve computer performance
      • in terms of resource utilization and application flexibility.
  • Hardware resources (CPU, memory, I/O devices, etc.) or software resources (operating system and software libraries) can be virtualized in various functional layers.
  • The idea is to separate the hardware from the software to yield better system efficiency – enhance the use of compute engines, networks, and storage.

3.1.1 Levels of Virtualization Implementation

  • A traditional computer runs with a host OS specially tailored for its hardware architecture.
  • After virtualization, different user applications managed by their own operating systems (guest OS) can run on the same hardware, independent of the host OS.
  • This is often done by adding additional software, called a virtualization layer as shown in Figure 3.1(b).
  • This virtualization layer is known as hypervisor or virtual machine monitor (VMM).
  • The VMs are shown in the upper boxes, where applications run with their own guest OS over the virtualized CPU, memory, and I/O resources.
  • The main function of the software layer for virtualization is to virtualize the physical hardware of a host machine into virtual resources to be used by the VMs, exclusively.
  • The virtualization software creates the abstraction of VMs by interposing a virtualization layer at various levels of a computer system.
  • Common virtualization layers include
    • the instruction set architecture (ISA) level,
    • hardware level,
    • operating system level,
    • library support level, and
    • application level.

3.1.1.1 Instruction Set Architecture Level

  • At the ISA level, virtualization is performed by emulating a given ISA by the ISA of the host machine.
  • With this approach, it is possible to run a large amount of legacy binary code written for various processors on any given new hardware host machine.
  • Instruction set emulation leads to virtual ISAs created on any hardware machine.
  • The basic emulation method is through code interpretation.
  • An interpreter program interprets the source instructions to target instructions one by one.
  • One source instruction may require tens or hundreds of native target instructions to perform its function.
  • Obviously, this process is relatively slow.
  • For better performance, dynamic binary translation is desired.
  • This approach translates basic blocks of dynamic source instructions to target instructions.
  • The basic blocks can also be extended to program traces or super blocks to increase translation efficiency.
  • Instruction set emulation requires binary translation and optimization.
  • A virtual instruction set architecture (V-ISA) thus requires adding a processor-specific software translation layer to the compiler.

3.1.1.2 Hardware Abstraction Level

 

  • Hardware-level virtualization is performed right on top of the bare hardware.
  • On the one hand, this approach generates a virtual hardware environment for a VM.
  • On the other hand, the process manages the underlying hardware through virtualization.
  • The idea is to virtualize a computer’s resources, such as its processors, memory, and I/O devices.
  • Purpose – upgrade the hardware utilization rate by multiple users concurrently.
  • The idea was implemented in the IBM VM/370 in the 1960s.
  • More recently, the Xen hypervisor has been applied to virtualize x86-based machines to run Linux or other guest OS applications.

3.1.1.3 Operating System Level

 

  • This refers to an abstraction layer between traditional OS and user applications.
  • OS-level virtualization creates isolated containers on a single physical server and the OS instances to utilize the hardware and software in data centers.
  • The containers behave like real servers.
  • OS-level virtualization is commonly used in
    • creating virtual hosting environments to allocate hardware resources among a large number of mutually distrusting users.
    • consolidating server hardware by moving services on separate hosts into containers or VMs on one server.

3.1.1.4 Library Support Level

  • Most applications use APIs exported by user-level libraries rather than using lengthy system calls by the OS.
  • Since most systems provide well-documented APIs, such an interface becomes another candidate for virtualization.
  • Virtualization with library interfaces is possible by controlling the communication link between applications and the rest of a system through API hooks.
  • The software tool WINE has implemented this approach to support Windows applications on top of UNIX hosts.
  • Another example is the vCUDA which allows applications executing within VMs to leverage GPU hardware acceleration.

3.1.1.5 User-Application Level

  • Virtualization at the application level virtualizes an application as a VM.
  • On a traditional OS, an application often runs as a process.
  • Therefore, application-level virtualization is also known as process-level virtualization.
  • The most popular approach is to deploy high level language (HLL) VMs.
  • In this scenario, the virtualization layer sits as an application program on top of the operating system, and the layer exports an abstraction of a VM that can run programs written and compiled to a particular abstract machine definition.
  • Any program written in the HLL and compiled for this VM will be able to run on it.
  • The Microsoft .NET CLR and Java Virtual Machine (JVM) are two good examples of this class of VM.
  • Other forms of application-level virtualization are known as application isolation, application sandboxing, or application streaming.
  • The process involves wrapping the application in a layer that is isolated from the host OS and other applications.
  • The result is an application that is much easier to distribute and remove from user workstations.
  • An example is the LANDesk application virtualization platform which deploys software applications as self-contained, executable files in an isolated environment without requiring installation, system modifications, or elevated security privileges.

3.1.1.6 Relative Merits of Different Approaches

  • Table 3.1 compares the relative merits of implementing virtualization at various levels.
  • Four technical merits.
    • “Higher Performance”
    • “Application Flexibility”
    • “Implementation Complexity” – the cost to implement that particular virtualization level.
    • “Application Isolation” – the effort required to isolate resources committed to different VMs.
  • Each row corresponds to a particular level of virtualization.
  • The number of X’s in the table cells reflects the advantage points of each implementation level.
  • Five X’s implies the best case and one X implies the worst case.
  • Merits of virtualization at various levels
    • Higher performance – hardware level virtualization and OS level virtualization
    • Hardware and application levels are also the most expensive to implement.
    • ISA implementation offers the best application flexibility.
    • Implementation complexity – hardware level virtualization and user application level
    • Application isolation – user application level
    • User isolation is the most difficult to achieve.

3.1.2 VMM Design Requirements and Providers

  • Hardware-level virtualization inserts a layer between real hardware and traditional operating systems.
  • This layer is commonly called the Virtual Machine Monitor (VMM)
  • It manages the hardware resources of a computing system.
  • Each time programs access the hardware – the VMM captures the process.
  • One hardware component, such as the CPU, can be virtualized as several virtual copies.
  • Therefore, several traditional operating systems which are the same or different can sit on the same set of hardware simultaneously.
  • There are three requirements for a VMM.
    • First, a VMM should provide an environment for programs which is essentially identical to the original machine.
    • Second, programs run in this environment should show, at worst, only minor decreases in speed.
    • Third, a VMM should be in complete control of the system resources.
  • Any program run under a VMM should exhibit a function identical to that which it runs on the original machine directly.
  • Two possible exceptions in terms of differences are permitted with this requirement:
    • differences caused by the availability of system resources and
    • differences caused by timing dependencies.
  • The former arises when more than one VM is running on the same machine.
  • The hardware resource requirements, such as memory, of each VM are reduced, but the sum of them is greater than that of the real machine installed.
  • A VMM should demonstrate efficiency in using the VMs.
  • To guarantee the efficiency of a VMM, a statistically dominant subset of the virtual processor’s instructions needs to be executed directly by the real processor, with no software intervention by the VMM.
  • Complete control of these resources by a VMM includes the following aspects:
    • (1) The VMM is responsible for allocating hardware resources for programs;
    • (2) it is not possible for a program to access any resource not explicitly allocated to it; and
    • (3) it is possible under certain circumstances for a VMM to regain control of resources already allocated.
  • Not all processors satisfy these requirements for a VMM.
  • A VMM is tightly related to the architectures of processors.
  • It is difficult to implement a VMM for some types of processors, such as the x86.
  • Specific limitations include the inability to trap on some privileged instructions.
  • If a processor is not designed to support virtualization primarily, it is necessary to modify the hardware to satisfy the three requirements for a VMM.
  • This is known as hardware-assisted virtualization.

 

 

3.1.3 Virtualization Support at the OS Level

  • With the help of VM technology, a new computing mode known as cloud computing is emerging.
  • Cloud computing is transforming the computing landscape by shifting the hardware and staffing costs of managing a computational center to third parties, just like banks.
  • However, cloud computing has at least two challenges.
    • The first is the ability to use a variable number of physical machines and VM instances depending on the needs of a problem.
      • For example, a task may need only a single CPU during some phases of execution but may need hundreds of CPUs at other times.
    • The second challenge concerns the slow operation of instantiating new VMs.
      • Currently, new VMs originate either as fresh boots or as replicates of a template VM, unaware of the current application state.
    • Therefore, to better support cloud computing, a large amount of research and development should be done.

3.1.3.1 Why OS-Level Virtualization?

  • Issues in hardware level VM
    • Slow to initialize – because each VM creates its own image from scratch.
    • Storing the VM images also becomes an issue.
    • Slow performance
    • Need for para-virtualization to modify the guest OS.
    • To reduce the performance overhead hardware modification may be needed.
  • Alternative: OS–level virtualization.
  • Operating system virtualization inserts a virtualization layer inside an operating system to partition a machine’s physical resources.
  • It enables multiple isolated VMs within a single operating system kernel.
  • This kind of VM is often called a virtual execution environment (VE), Virtual Private System (VPS), or simply container.
  • From the user’s point of view, VEs look like real servers.
  • This means a VE has its own set of
    • processes, file system, user accounts, network interfaces with IP addresses, routing tables, firewall rules, and other personal settings.
  • Although VEs can be customized for different people, they share the same OS kernel.
  • Therefore, OS-level virtualization is also called single–OS image virtualization.
  • Figure 3.3 illustrates operating system virtualization from the point of view of a machine stack.

3.1.3.2 Advantages of OS Extensions

 

  • Compared to hardware-level virtualization, the benefits of OS extensions are twofold:
    • (1) VMs at the operating system level have minimal startup/shutdown costs, low resource requirements, and high scalability; and
    • (2) for an OS-level VM, it is possible for a VM and its host environment to synchronize state changes when necessary.
  • These benefits can be achieved via two mechanisms of OS-level virtualization:
    • (1) All OS-level VMs on the same physical machine share a single operating system kernel; and
    • (2) the virtualization layer can be designed in a way that allows processes in VMs to access as many resources of the host machine as possible, but never to modify them.

3.1.3.3 Disadvantages of OS Extensions

  • The main disadvantage of OS extensions
    • all the VMs at operating system level on a single container must have the same kind of guest operating system.
      • That is, although different OS-level VMs may have different operating system distributions, they must pertain to the same operating system family.
    • For example, a Windows distribution such as Windows XP cannot run on a Linux-based container.
    • Figure 3.3 illustrates the concept of OS-level virtualization.
    • The virtualization layer is inserted inside the OS to partition the hardware resources for multiple VMs to run their applications in multiple virtual environments.
    • To implement OS-level virtualization, isolated execution environments (VMs) should be created based on a single OS kernel.
    • Furthermore, the access requests from a VM need to be redirected to the VM’s local resource partition on the physical machine.
  • For example, the chroot command in a UNIX system can create several virtual root directories within a host OS.
  • These virtual root directories are the root directories of all VMs created.
  • There are two ways to implement virtual root directories:
    • duplicating common resources to each VM partition;
      • incurs significant resource costs and overhead on a physical machine
    • sharing most resources with the host environment and only creating private resource copies on the VM on demand.

3.1.3.4 Virtualization on Linux or Windows Platforms

 

  • By far, most reported OS-level virtualization systems are Linux-based.
  • Virtualization support on the Windows-based platform is still in the research stage.
  • The Linux kernel offers an abstraction layer to allow software processes to work with and operate on resources without knowing the hardware details.
  • New hardware may need a new Linux kernel to support.
  • Therefore, different Linux platforms use patched kernels to provide special support for extended functionality.
  • However, most Linux platforms are not tied to a special kernel.
  • In such a case, a host can run several VMs simultaneously on the same hardware.
  • Table 3.3 summarizes several examples of OSlevel virtualization tools that have been developed in recent years.
  • Two OS tools (Linux vServer and OpenVZ) support Linux platforms to run other platform-based applications through virtualization.
  • The third tool, FVM, is an attempt specifically developed for virtualization on the Windows NT platform.

3.1.4 Middleware Support for Virtualization

 

  • Library-level virtualization is also known as user-level Application Binary Interface (ABI) or API emulation.
  • This type of virtualization can create execution environments for running alien programs on a platform rather than creating a VM to run the entire operating system.
  • API call interception and remapping are the key functions performed.
  • This section provides an overview of several library-level virtualization systems: namely the Windows Application Binary Interface (WABI), lxrun, WINE, Visual MainWin, and vCUDA, which are summarized in Table 3.4.
    • The WABI offers middleware to convert Windows system calls to Solaris system calls.
    • Lxrun is really a system call emulator that enables Linux applications written for x86 hosts to run on UNIX systems.
    • Similarly, Wine offers library support for virtualizing x86 processors to run Windows applications on UNIX hosts.
    • Visual MainWin offers a compiler support system to develop Windows applications using Visual Studio to run on some UNIX hosts.
    • The vCUDA provides virtualization support for using general purpose GPUs to run data–intensive applications under a special guest OS.