Virtual Machines: Difference between revisions
Yuron [PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
W81054ch [PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
||
(One intermediate revision by one other user not shown) | |||
Line 4: | Line 4: | ||
physical machine may appear as several, distinct [https://en.wikipedia.org/wiki/Virtual_machine <em>virtual machines</em>]. | physical machine may appear as several, distinct [https://en.wikipedia.org/wiki/Virtual_machine <em>virtual machines</em>]. | ||
There are different ways to approach this virtualisation. In one | There are different ways to approach this virtualisation. In one sense, the simplest approach is to use an application program which runs a software model of a separate machine, modelling the hardware including the processor. This is a machine <strong>emulator</strong>. | ||
sense, the simplest approach is to use an application program which | |||
runs a software model of a separate machine, modelling the hardware | |||
including the processor. This is a machine <strong>emulator</strong>. | |||
[[Image:process_VM.png|link=|alt=Process Virtual Machine]] | [[Image:process_VM.png|link=|alt=Process Virtual Machine]] | ||
Line 21: | Line 18: | ||
* using software to model hardware is <strong>slow</strong>; typically <em>much</em> slower than a real system. | * using software to model hardware is <strong>slow</strong>; typically <em>much</em> slower than a real system. | ||
An example is the [https://en.wikipedia.org/wiki/Java_virtual_machine Java Virtual Machine] (JVM) which emulates a computer which runs a [https://en.wikipedia.org/wiki/Java_bytecode Java bytecode] instruction | An example is the [https://en.wikipedia.org/wiki/Java_virtual_machine Java Virtual Machine] (JVM) which emulates a computer which runs a [https://en.wikipedia.org/wiki/Java_bytecode Java bytecode] instruction set. Some emulators – such as [https://en.wikipedia.org/wiki/QEMU QEMU] – apply various clever acceleration techniques but it is difficult to get close to hardware performance speeds. | ||
set. Some emulators – such as | |||
[https://en.wikipedia.org/wiki/QEMU QEMU] – apply various clever | |||
acceleration techniques but it is difficult to get close to hardware | |||
performance speeds. | |||
If all the code runs on the native hardware [[Extra:ISA|ISA]] then the | If all the code runs on the native hardware [[Extra:ISA|ISA]] then the efficient approach is to run directly on that hardware. This is the same principle applied to processing as is used in [[Virtual Memory|virtual memory]] – and presents similar problems: there must be some way of preventing the guest system from doing something it shouldn’t. | ||
efficient approach is to run directly on that hardware. This is the | |||
same principle applied to processing as is used in [ | |||
memory] – and presents similar problems: there must | |||
be some way of preventing the guest system from doing something it | |||
shouldn’t. | |||
In a software emulation the software can check for this; with the | In a software emulation the software can check for this; with the software layer removed there needs to be a hardware check. (In memory management this is the [[Memory_Fault|page fault]].) Indeed, in some sense, in a multi-tasking system each [[Processes|process]] is in its own ‘virtual machine’, cocooned by the operating system, which is supported by the hardware. | ||
software layer removed there needs to be a hardware check. (In memory | |||
management this is the [[Memory_Fault|page fault]].) Indeed, in some | |||
sense, in a multi-tasking system each [[Processes|process]] is in its | |||
own ‘virtual machine’, cocooned by the operating system, | |||
which is supported by the hardware. | |||
With a sufficiently detailed virtual model, this can be extended so | With a sufficiently detailed virtual model, this can be extended so that the process is a whole machine model which can run its own operating system. | ||
that the process is a whole machine model which can run its own | |||
operating system. | |||
[[Image:emulated_OS.png|link=|alt=Emulated OS]] | [[Image:emulated_OS.png|link=|alt=Emulated OS]] | ||
<em>However</em>, the O.S. feels free to manipulate the hardware directly | <em>However</em>, the O.S. feels free to manipulate the hardware directly (it’s its job) which is a problem if there is more than one O.S. trying to run simultaneously. To support this, <em>another</em> abstraction layer can be added, between the operating system(s) and the hardware. This is called a Virtual Machine Monitor (VMM) or – more catchily – a “[[hypervisor]]”. | ||
(it’s its job) which is a problem if there is more than one | |||
O.S. trying to run simultaneously. To support this, <em>another</em> | |||
abstraction layer can be added, between the operating system(s) and | |||
the hardware. This is called a Virtual Machine Monitor (VMM) or – | |||
more catchily – a “[[hypervisor]]”. | |||
[[Image:hypervisor_layers.png|link=|alt=Hypervisor layers]] | [[Image:hypervisor_layers.png|link=|alt=Hypervisor layers]] | ||
Line 58: | Line 34: | ||
Here’s a [https://www.youtube.com/watch?v=ZmPY9nEFPMk video] (13 mins.) of someone demonstrating his virtual machinery. | Here’s a [https://www.youtube.com/watch?v=ZmPY9nEFPMk video] (13 mins.) of someone demonstrating his virtual machinery. | ||
This is a [https://www.youtube.com/watch?v=zLJbP6vBk2M comprehensive view of virtualisation] and | This is a [https://www.youtube.com/watch?v=zLJbP6vBk2M comprehensive view of virtualisation] and hypervisors, particularly from the user’s perspective (1 hr.) | ||
hypervisors, particularly from the user’s perspective (1 hr.) | |||
---- | ---- | ||
{{BookChapter|18|701-729}} | |||
{{PageGraph}} | {{PageGraph}} |
Latest revision as of 10:03, 5 August 2019
Depends on | Virtualisation |
---|
Virtualisation extends to whole machines, thus, for example, one physical machine may appear as several, distinct virtual machines.
There are different ways to approach this virtualisation. In one sense, the simplest approach is to use an application program which runs a software model of a separate machine, modelling the hardware including the processor. This is a machine emulator.
There are several benefits to this model:
- it allows simple control of security in that the virtual application is completely contained by the emulator
- the emulator can emulate any machine: the virtual processor can be completely different from the actual hardware
- the emulator may collect additional monitoring information; this can help with debugging etc.
There are also at least one significant drawback:
- using software to model hardware is slow; typically much slower than a real system.
An example is the Java Virtual Machine (JVM) which emulates a computer which runs a Java bytecode instruction set. Some emulators – such as QEMU – apply various clever acceleration techniques but it is difficult to get close to hardware performance speeds.
If all the code runs on the native hardware ISA then the efficient approach is to run directly on that hardware. This is the same principle applied to processing as is used in virtual memory – and presents similar problems: there must be some way of preventing the guest system from doing something it shouldn’t.
In a software emulation the software can check for this; with the software layer removed there needs to be a hardware check. (In memory management this is the page fault.) Indeed, in some sense, in a multi-tasking system each process is in its own ‘virtual machine’, cocooned by the operating system, which is supported by the hardware.
With a sufficiently detailed virtual model, this can be extended so that the process is a whole machine model which can run its own operating system.
However, the O.S. feels free to manipulate the hardware directly (it’s its job) which is a problem if there is more than one O.S. trying to run simultaneously. To support this, another abstraction layer can be added, between the operating system(s) and the hardware. This is called a Virtual Machine Monitor (VMM) or – more catchily – a “hypervisor”.
Here’s a video (13 mins.) of someone demonstrating his virtual machinery.
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, pages 701-729 |
---|