Hypervisor
| On path: OS Topics | 1: Concepts • 2: Cache • 3: Context • 4: Processor Privilege • 5: Process Scheduling • 6: Exceptions • 7: Interrupts • 8: Direct Memory Access (DMA) • 9: Virtualisation • 10: Hypervisor |
|---|
| Depends on | Virtualisation • Security • Processes • Virtual Machines |
|---|
An operating system can be described as a software layer which provides a virtual machine for application processes to run on. Each application process can then act as if it is alone on a machine with a particular set of (abstracted) devices, memory etc. The operating system provides the interface to the physical hardware.
A hypervisor extends this concept by providing a further layer of software between an operating system and the hardware. This means that more than one operating system can run on a single machine at the same time, in much the same way as many applications can run on a single operating system. Thus, for example, one could run Linux and Windows on the same machine, simultaneously. (Don’t confuse this with “dual boot” which runs one or the other at any time!)
Historically, the operating system was sometimes called the “supervisor”, so a “hypervisor” is the next layer.
Advantages
- One physical computer can support all the software you want: favourite old software can be retained when your main operating system is upgraded etc.
- The notional ‘computer’ an operating system is running on is defined in (the hypervisor) software so it can be more standardised than the hardware. This makes portability of software easier: if you upgrade the hardware then only a new hypervisor installation is required – former operating systems (with all their applications) can simply be copied onto the new box.
Minimal reconfiguration required. - Rather than keeping separate computer boxes for different applications – with consequential maintenance and electricity costs – investing in one powerful machine will bring that performance level to all applications …
… as long as you don’t try to run everything at once of course. (As if you physically could!) This is the same principle employed by any multi-tasking O.S. where many applications (processes) may be active but only need resources such as processor time intermittently.
Types
Hypervisors are often classified into two types – imaginatively called “type 1” and “type 2”. These differ in where in the software ‘stack’ the hypervisor is located.
Type 1
The type 1 hypervisor is adjacent to the hardware and separates the physical computer from all the other software; just like an operating system in the absence of a hypervisor, this is an abstraction layer. The hypervisor is a virtual machine upon which operating systems can run.
Conceptually this is quite simple. Implementationally this has numerous details which make things rather more tricky.
- Privilege: an operating system believes it has full privilege to modify system hardware. Because two or more operating systems might have conflicting opinions on this, attempts have to trap to the hypervisor. This requires another level of privilege in the hardware, needed to be gained via some form of hypervisor exception (cf. system call).
A modern x86 processor (as an example) has four nested “rings” of privilege.
A few instructions will only work when the processor is in the inner ring(s); attempts to execute these by a user task will result in a trap such as a “general protection fault”. - Features such as page tables need to be reflected by the true hardware. Note that an operating system can update a page table purely in its own memory. However this is now not mapping to the (true) physical memory; conceptually, a second level of page tables, translating from each operating system’s idea of ‘physical memory’ to the true physical memory is required.
Example: a guest O.S. has some memory in which it maintains its page tables. These cannot be the page tables which the MMU hardware uses (they don’t contain the second level of mapping) so some real page tables are also needed. The hypervisor needs to detect changes made by each guest O.S. to reflect these in its own tables; similarly if a page’s status is altered (e.g. a write to a page is detected) this may need back-annotating for the guest O.S.
With the appropriate degree of hardware support, an application can run largely on the hardware directly, which allows better performance than a type 2 hypervisor.
High-performance, multiprocessor machines – such as servers – are probably the biggest ‘market’ for type 1 hypervisors at time of writing.
Type 2
A type 2 hypervisor runs under a host operating system, so is really a form of application program. It can still provide a virtual machine environment but there is a greater need to intercept particular operations and emulate hardware actions in (hypervisor) software.
Type 2 hypervisors are (perhaps) conceptually slightly simpler and can require less hardware support. Because more of the work is done in software (emulation) there is a performance penalty. Furthermore, the (each) virtual machine has resources such as RAM allocated statically and may thus be less flexible about being able to reallocate resources according to demands.
Type 2 hypervisors are the sort currently more likely to be found in ‘domestic’ use.
This is a comprehensive view of virtualisation and hypervisors, particularly from the user’s perspective (1 hr.)
| Also refer to: | Operating System Concepts, 10th Edition: Chapter 18.1, pages 701-703 |
|---|
