Exploring Virtual Environments in Computing: An Overview

undefined
1
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
David Bednárek
Computing in virtual environments
virtual
2
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
virtual
Merriam-Webster dictionary
very close to being something without actually being it
existing or occurring on computers or on the Internet
from Latin 
virtus
 
- 
strength, virtue
f
rom 
vir
 
- 
man
Virtual – examples outside computing (2009)
3
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
undefined
4
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
Virtual elements in computing
Virtual elements in computing infrastructure
5
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
Virtual memory
1962; in daily use since 1970s (IBM S/370 and many others)
Always implemented in hardware, controlled by OS
Virtual machines
1972 (IBM S/370), abandoned before 1990
Revived in 1999 (VMWare at Intel/AMD x86)
Originally implemented purely in software
But co-developed with hardware in IBM S/370
Specific hardware support in Intel/AMD CPUs since 2005
Virtual disks
1974 (Unix)
Originally implemented as block-device drivers (RAM-disks etc.)
High-performance versions implemented in dedicated HW (RAID controllers)
Virtual NICs, VLANs, VPNs, …
Virtual execution environments
6
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
Virtual execution environment
An environment in which a piece of software runs
Different from the native environment for which the software was designed
Even if the software developers know that they are developing for a virtual
environment, they want to ignore the complexity of the target environment,
pretending that they develop for the plain old physical world
Built upon some or all of the previously existing virtual technologies:
Virtual memory (always)
Virtual machines (sometimes; always in clouds) and/or containers
Virtual disks or virtual file systems
Virtual NICs (always)
VLANs, VPNs (in large installations and clouds)
undefined
7
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
Motivation for virtualization
Multi-tenant environments
8
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
Tenant – a person/corporation using a set of services
Different from the owner of the hardware
A completely different (legal) person (a customer), or
An organizational unit using services supplied by an IT department, etc.
Multi-tenant environments
Hardware resources shared among multiple tenants
Tenants are not able to share resources voluntarily
They usually do not know each other
They don’t want to negotiate on resources
Their software cannot be sufficiently customized to share resources
Granularity of multi-tenant sharing
A physical computer is often too big
Load balancing may require fragments of the power of a physical computer
It is too difficult to reassign a physical computer to a different tenant
Even if automated, such a reassignment may take hours
Dependency hell
9
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
A piece of software is not a single file or folder
Executables are linked to dynamically-loaded libraries
Referenced by a short name like “libcrt.so”
An application is often divided into communicating processes
Often because some parts of code cannot coexist inside the same executable
Linked by named pipes or IP sockets, identified by file names, port numbers
There are resources, configurations, data, multimedia, ...
Stored as files somewhere, identified by relative/absolute file names
Different systems have conflicting conventions
All the constituents must have the same or compatible version
Coexistence of two versions of the same software
Needed if software A and B require different versions of software C
A and B shall be configured so that they find different versions of C under the same
name
Preparing such configurations is difficult
Such configurations would deviate from system conventions (like /etc/*)
Complex configurations may degrade performance (copying of large environments)
There is often no configuration option at all
Motivation for virtualization
10
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
Problems
Multi-tenancy
Different tenants cannot share the same machine
Dependency hell
Often, different software of the same tenant cannot share the same machine
At the same time, load-balancing requires sharing the same
machine between different tenants and/or software
Solution: Virtualization
Disconnect the notion of machine from the physical hardware
A hardware machine may host multiple virtual machines
Virtual machines may migrate across hardware machines
Virtual machines may be easily stopped, created, destroyed, ...
Virtualization granularity
11
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
In the plain non-virtualized world, people think about machines
(physical computers)
"I want to log into computer X"
"I want to install software Y at computer X"
The naming, addressing, configuration is mostly machine-centric
machine:port addressing in TCP/UDP
/usr/bin or "c:\Program Files" installations of software
/etc/* or HKEY_LOCAL_MACHINE registry configurations of software
machine-wide scope of "ps", /proc/*, ...
This could have been done differently, but it was not
Nobody is going to modify all the software built in the machine-centric era
The people will not change either
Result: we want to virtualize machines
Creating an illusion of a complete computer
undefined
Process 1
O
S
 kernel
Naïve picture
In reality
Processes directly
interact with CPU
and memory
I/O devices may
directly interact with
memory
There may be more
than one CPU in the
system
Plain Old Execution Environment
12
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
CPU
I/O devices
outer world
Process 2
software
hardware
Process 1
O
S
 kernel
Plain Old Execution Environment
13
Without virtualization, the separation
between processes is deemed insufficient
Operating systems (since Unix) are built to
facilitate inter-process communication
Processes on the same machine compete
for resources (memory, CPUs)
Processes share global name spaces (file
names, port numbers, UIDs, …)
In theory, communication, competition
and access are limited by priority,
environment, and access-rights
mechanisms
Nobody believes that these old
mechanisms are sufficient against modern
risks
Access rights cannot solve naming conflicts
Cannot have two web servers on port 80
Cannot have two gcc versions with the same
/usr/include
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
CPU
I/O devices
outer world
Process 2
undefined
14
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
Flavors of virtualization
Process
O
S
 kernel
Virtualization at different layers
15
Containerization
OS kernel improved so that it now offers
different views (via the same interface) for
different processes
Para-virtualization
Lower layers of OS kernel modified so that
multiple kernels may coexist on the same
CPU
(True) virtualization
Hardware support in CPU and/or emulation
by software enables coexistence of multiple
unmodified OS kernels on the same CPU
Originally, these were three independent
approaches
Today, the three approaches may share
some underlying hardware and/or
software technology
They may coexist on the same machine
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
CPU
(true) virtualization
para-virtualization
containerization
P1
O
S
 kernel
Virtualization at different layers
16
Outcome of virtualization
A set of processes lives in an illusion that
they are alone at a hardware machine
In containerization, this illusion is created
by the OS kernel
The same kernel may be shared by several
such sets of processes
In para- and true virtualization, also the OS
kernel lives in this illusion
OS kernels always need to feel alone
In para-virtualization, this applies only to the
upper, unmodified majority of the kernel
Each such set of processes has its own kernel
For software developers, the outcome is
almost identical for the three approaches
For system maintenance, there is huge
difference between containerization and
virtualization
Think about updates to the kernel(s)
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
CPU
(true) virtualization
para-virtualization
containerization
P2
P1
O
S
 kernel
Virtualization at different layers
17
Containers vs. virtual machines
Originally, containerization and
virtualization were completely independent
techniques
Now, they often share parts of the
underlying technology
Some container systems use hardware-based
isolation developed for virtual machines
Some virtual machine systems use software
tricks developed for containers
There are interfaces/libraries/apps capable of
controlling both containers and virtual
machines
There is still a fundamental difference:
Containers
Only one instance of OS kernel per hw
machine
Shared among all containers
Virtual machines
Each virtual machine has its own instance of
OS kernel
More memory required
In addition, there may be a 
host 
OS kernel
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
CPU
(true) virtualization
para-virtualization
containerization
P2
Virtual Machine A
Virtual Machine B
Type 1 (Bare Metal) Hypervisor
Example: VMWare ESXi
Type 2 (Hosted) Hypervisor
Example: VMWare Workstation Player
Hypervisor on bare metal
Hypervisor directly performs all
hardware access (CPU
configuration, I/O)
Requires device drivers
Complex but fast
Hypervisor above an host OS
Hypervisor is a (privileged) process
Often one per VM
I/O access performed by host kernel
CPU control requires support from
the host kernel (debugging services)
Types of Virtual Machine Systems
18
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
Process
Process
Process
Process
Kernel A
Kernel B
VMM
 (Virtual Machine Manager)
a.k.a. Hypervisor
CPU, I/O hardware
VM 
A
VM B
Process
Process
Process
Process
Kernel A
Kernel B
CPU, I/O hardware
Host Kernel
Hypervisor
Process
Hypervisor
Beware
19
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
Pictures like this are misleading
VM 
A
VM B
Process
Process
Process
Process
Kernel A
Kernel B
CPU, I/O hardware
Host Kernel
Hypervisor
Process
Hypervisor
Beware
20
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
The host kernel actually sees
this:
VM 
A
Process
Process
Kernel A
CPU, I/O hardware
Process
Hyper
visor
VM 
B
Process
Process
Kernel B
The CPU sees this:
Process
Process
Kernel A
Host
Kernel
Process
Process
Process
Kernel B
Hyper
visor
Hyper
visor
Hyper
visor
CPU, I/O hardware
Host Kernel
VM 0
Virtual Machine A
Virtual Machine B
Traditional
Example: VMWare ESXi
With root partition 
(Microsoft terminology)
Example: Microsoft Windows + Hyper-V
Hypervisor performs I/O
Requires device drivers tailored for
the hypervisor
Too costly development
Hypervisor only controls CPU
VM 0 aka Root partition
Allowed to directly access I/O
hardware
Standard OS with device drivers
Hypervisor forwards I/O requests
Flavors of Type 1 Hypervisors
21
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
Process
Process
Process
Process
Kernel A
Kernel B
VMM
 (Virtual Machine Manager)
a.k.a. Hypervisor
CPU, I/O hardware
VM 
A
VM B
Proc
Proc
Kernel B
VMM
 (Virtual Machine Manager)
a.k.a. Hypervisor
Proc
Proc
Kernel 
A
Kernel 
0
VM
ctrl
Proc
Proc
CPU, I/O hardware
Implemented in user-space
Example: VMWare Workstation Player
Implemented in a kernel
Example: Linux KVM
Hypervisor integrated in kernel
Fast
No need to indirect CPU control via
kernel service
Complex and dangerous
Kernels were not designed for this
Flavors of Type 2 Hypervisors
22
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
VM 
A
VM B
Proc
Proc
Proc
Proc
Kernel A
Kernel B
CPU, I/O hardware
Host Kernel (includes Hypervisor)
Proc
Hypervisor above an host OS
Hypervisor is a (privileged) process
Often one per VM
I/O access performed by host kernel
CPU control requires support from
the host kernel (debugging services)
VM 
A
VM B
Process
Process
Process
Process
Kernel A
Kernel B
CPU, I/O hardware
Host Kernel
Hypervisor
Process
Hypervisor
VM
Ctrl
Proc
Traditional type 1 hypervisor
Example: VMWare ESXi
Type 2 implemented in a kernel
Example: Linux KVM
Hypervisor implanted in kernel
CPU control, time sharing, and I/O
in the same project
Complex and dangerous
Where is the difference? Only in the history.
23
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
VM 
A
VM B
Proc
Proc
Proc
Proc
Kernel A
Kernel B
CPU, I/O hardware
Host Kernel (includes Hypervisor)
Proc
VM
Ctrl
Proc
Virtual Machine A
Virtual Machine B
Hypervisor does everything
CPU control, time sharing, and I/O
in the same project
Complex and dangerous
Process
Process
Process
Process
Kernel A
Kernel B
VMM
 (Virtual Machine Manager)
a.k.a. Hypervisor
CPU, I/O hardware
Virtual Machines
Containers
Inherent safety
Kernel-HW interface was not
designed for Kernel-Kernel
communication
VMM adds well-controled holes
into a natural barrier
Limited safety
Process-Kernel interface was
designed for Process-Process
communication
Containerization requires blocking
existing communication channels
Virtual Machines vs. Containers
24
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
Process
A1
Process
A2
Process
B1
Virtual Machine A
Process
B2
Kernel A
Virtual Machine B
Kernel B
VMM
 (Virtual Machine Manager)
a.k.a. Hypervisor
Process
A1
Process
A2
Process
B1
Container A
Process
B2
Kernel
Container B
Container B
Container A
Virtual Machine B
Virtual Machine A
Virtual Machines
Containers
Each VM is a complete OS
Each VM runs its services in specific
settings
User (admin) processes (e.g. install
scripts) can control services (edit
/etc/..., run systemctl, ...)
Container is not a complete OS
Services shared among containers
Dependency hell still present
Processes inside containers usually
cannot control services outside
containers - their install scripts
cannot run inside containers
Virtual Machines vs. Containers
25
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
init
serv
Kernel A
Kernel B
VMM
 (Virtual Machine Manager)
a.k.a. Hypervisor
Kernel
ices
proc
esses
init
serv
ices
proc
esses
init
serv
ices
proc
esses
proc
esses
Container B
Container A
Plain Containers
System 
Containers
System container resembles a
complete OS
Each container contains its service
manager (init)
Install scripts work inside containers
The illusion is not yet complete
Certain privileges/capabilities/roles
are hardwired in Linux kernel and
denied for containers
Plain 
vs. 
System 
Containers
26
NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bednárek
Kernel
init
serv
proc
esses
proc
esses
Container B
Container A
Container is not a complete OS
Services shared among containers
Dependency hell still present
Processes inside containers usually
cannot control services outside
containers - install scripts cannot
run inside containers
Kernel
init
serv
ices
proc
esses
proc
esses
init
serv
init
serv
Slide Note
Embed
Share

Virtual environments in computing encompass a range of technologies, from virtual memory to virtual machines and virtual execution environments. These environments allow software to run in a different setting than originally designed, minimizing complexities. Key components include virtual memory, machines, disks, NICs, and execution environments. Understanding these concepts is crucial in the realm of virtualization and cloud computing.

  • Virtualization
  • Computing
  • Virtual Environments
  • Cloud Computing
  • Technology

Uploaded on Oct 01, 2024 | 1 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. David Bednrek Computing in virtual environments NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 1

  2. virtual virtual Merriam-Webster dictionary very close to being something without actually being it existing or occurring on computers or on the Internet from Latin virtus - strength, virtue from vir - man NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 2

  3. Virtual examples outside computing (2009) NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 3

  4. Virtual elements in computing NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 4

  5. Virtual elements in computing infrastructure Virtual memory 1962; in daily use since 1970s (IBM S/370 and many others) Always implemented in hardware, controlled by OS Virtual machines 1972 (IBM S/370), abandoned before 1990 Revived in 1999 (VMWare at Intel/AMD x86) Originally implemented purely in software But co-developed with hardware in IBM S/370 Specific hardware support in Intel/AMD CPUs since 2005 Virtual disks 1974 (Unix) Originally implemented as block-device drivers (RAM-disks etc.) High-performance versions implemented in dedicated HW (RAID controllers) Virtual NICs, VLANs, VPNs, NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 5

  6. Virtual execution environments Virtual execution environment An environment in which a piece of software runs Different from the native environment for which the software was designed Even if the software developers know that they are developing for a virtual environment, they want to ignore the complexity of the target environment, pretending that they develop for the plain old physical world Built upon some or all of the previously existing virtual technologies: Virtual memory (always) Virtual machines (sometimes; always in clouds) and/or containers Virtual disks or virtual file systems Virtual NICs (always) VLANs, VPNs (in large installations and clouds) NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 6

  7. Motivation for virtualization NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 7

  8. Multi-tenant environments Tenant a person/corporation using a set of services Different from the owner of the hardware A completely different (legal) person (a customer), or An organizational unit using services supplied by an IT department, etc. Multi-tenant environments Hardware resources shared among multiple tenants Tenants are not able to share resources voluntarily They usually do not know each other They don t want to negotiate on resources Their software cannot be sufficiently customized to share resources Granularity of multi-tenant sharing A physical computer is often too big Load balancing may require fragments of the power of a physical computer It is too difficult to reassign a physical computer to a different tenant Even if automated, such a reassignment may take hours NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 8

  9. Dependency hell A piece of software is not a single file or folder Executables are linked to dynamically-loaded libraries Referenced by a short name like libcrt.so An application is often divided into communicating processes Often because some parts of code cannot coexist inside the same executable Linked by named pipes or IP sockets, identified by file names, port numbers There are resources, configurations, data, multimedia, ... Stored as files somewhere, identified by relative/absolute file names Different systems have conflicting conventions All the constituents must have the same or compatible version Coexistence of two versions of the same software Needed if software A and B require different versions of software C A and B shall be configured so that they find different versions of C under the same name Preparing such configurations is difficult Such configurations would deviate from system conventions (like /etc/*) Complex configurations may degrade performance (copying of large environments) There is often no configuration option at all NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 9

  10. Motivation for virtualization Problems Multi-tenancy Different tenants cannot share the same machine Dependency hell Often, different software of the same tenant cannot share the same machine At the same time, load-balancing requires sharing the same machine between different tenants and/or software Solution: Virtualization Disconnect the notion of machine from the physical hardware A hardware machine may host multiple virtual machines Virtual machines may migrate across hardware machines Virtual machines may be easily stopped, created, destroyed, ... NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 10

  11. Virtualization granularity In the plain non-virtualized world, people think about machines (physical computers) "I want to log into computer X" "I want to install software Y at computer X" The naming, addressing, configuration is mostly machine-centric machine:port addressing in TCP/UDP /usr/bin or "c:\Program Files" installations of software /etc/* or HKEY_LOCAL_MACHINE registry configurations of software machine-wide scope of "ps", /proc/*, ... This could have been done differently, but it was not Nobody is going to modify all the software built in the machine-centric era The people will not change either Result: we want to virtualize machines Creating an illusion of a complete computer NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 11

  12. Plain Old Execution Environment Na ve picture In reality Processes directly interact with CPU and memory Process 1 Process 2 software I/O devices may directly interact with memory OS kernel There may be more than one CPU in the system CPU hardware I/O devices outer world NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 12

  13. Plain Old Execution Environment Without virtualization, the separation between processes is deemed insufficient Process 1 Process 2 Operating systems (since Unix) are built to facilitate inter-process communication Processes on the same machine compete for resources (memory, CPUs) OS kernel Processes share global name spaces (file names, port numbers, UIDs, ) In theory, communication, competition and access are limited by priority, environment, and access-rights mechanisms CPU Nobody believes that these old mechanisms are sufficient against modern risks I/O devices Access rights cannot solve naming conflicts outer world Cannot have two web servers on port 80 Cannot have two gcc versions with the same /usr/include NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 13

  14. Flavors of virtualization NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 14

  15. Virtualization at different layers Containerization OS kernel improved so that it now offers different views (via the same interface) for different processes Process containerization Para-virtualization Lower layers of OS kernel modified so that multiple kernels may coexist on the same CPU OS kernel (True) virtualization para-virtualization Hardware support in CPU and/or emulation by software enables coexistence of multiple unmodified OS kernels on the same CPU (true) virtualization Originally, these were three independent approaches CPU Today, the three approaches may share some underlying hardware and/or software technology They may coexist on the same machine NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 15

  16. Virtualization at different layers Outcome of virtualization A set of processes lives in an illusion that they are alone at a hardware machine P1 P2 In containerization, this illusion is created by the OS kernel containerization The same kernel may be shared by several such sets of processes In para- and true virtualization, also the OS kernel lives in this illusion OS kernel OS kernels always need to feel alone para-virtualization In para-virtualization, this applies only to the upper, unmodified majority of the kernel Each such set of processes has its own kernel (true) virtualization For software developers, the outcome is almost identical for the three approaches CPU For system maintenance, there is huge difference between containerization and virtualization Think about updates to the kernel(s) NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 16

  17. Virtualization at different layers Containers vs. virtual machines Originally, containerization and virtualization were completely independent techniques P1 P2 Now, they often share parts of the underlying technology containerization Some container systems use hardware-based isolation developed for virtual machines Some virtual machine systems use software tricks developed for containers OS kernel There are interfaces/libraries/apps capable of controlling both containers and virtual machines para-virtualization There is still a fundamental difference: Containers (true) virtualization Only one instance of OS kernel per hw machine Shared among all containers CPU Virtual machines Each virtual machine has its own instance of OS kernel More memory required In addition, there may be a host OS kernel NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 17

  18. Types of Virtual Machine Systems Type 1 (Bare Metal) Hypervisor Example: VMWare ESXi Type 2 (Hosted) Hypervisor Example: VMWare Workstation Player Virtual Machine A Virtual Machine B VM A VM B Process Process Process Process Process Process Process Process Kernel A Kernel B Kernel A Kernel B Process Hypervisor Hypervisor VMM (Virtual Machine Manager) a.k.a. Hypervisor Host Kernel CPU, I/O hardware CPU, I/O hardware Hypervisor on bare metal Hypervisor above an host OS Hypervisor directly performs all hardware access (CPU configuration, I/O) Hypervisor is a (privileged) process Often one per VM I/O access performed by host kernel Requires device drivers CPU control requires support from the host kernel (debugging services) Complex but fast NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 18

  19. Beware Pictures like this are misleading VM A VM B Process Process Process Process Kernel A Kernel B Process Hypervisor Hypervisor Host Kernel CPU, I/O hardware NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 19

  20. Beware The host kernel actually sees this: VM B VM A Hyper visor Hyper visor Kernel B Process Process Process Kernel A Process Process Host Kernel CPU, I/O hardware The CPU sees this: Hyper visor Hyper visor Host Kernel Kernel A Process Process Kernel B Process Process Process CPU, I/O hardware NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 20

  21. Flavors of Type 1 Hypervisors Traditional With root partition (Microsoft terminology) Example: Microsoft Windows + Hyper-V Example: VMWare ESXi Virtual Machine A Virtual Machine B VM 0 Process Process Process Process VM ctrl VM A VM B Proc Proc Kernel A Kernel B Proc Proc Proc Proc Kernel 0 Kernel A Kernel B VMM (Virtual Machine Manager) a.k.a. Hypervisor VMM (Virtual Machine Manager) a.k.a. Hypervisor CPU, I/O hardware CPU, I/O hardware Hypervisor performs I/O Hypervisor only controls CPU Requires device drivers tailored for the hypervisor VM 0 aka Root partition Allowed to directly access I/O hardware Too costly development Standard OS with device drivers Hypervisor forwards I/O requests NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 21

  22. Flavors of Type 2 Hypervisors Implemented in user-space Example: VMWare Workstation Player VM A Implemented in a kernel Example: Linux KVM VM B VM A VM B Process Process Process Process Proc Proc Proc Proc VM Ctrl Proc Proc Kernel A Kernel B Kernel A Kernel B Process Hypervisor Hypervisor Host Kernel (includes Hypervisor) Host Kernel CPU, I/O hardware CPU, I/O hardware Hypervisor above an host OS Hypervisor is a (privileged) process Often one per VM I/O access performed by host kernel CPU control requires support from the host kernel (debugging services) Hypervisor integrated in kernel Fast No need to indirect CPU control via kernel service Complex and dangerous Kernels were not designed for this NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 22

  23. Where is the difference? Only in the history. Traditional type 1 hypervisor Example: VMWare ESXi Type 2 implemented in a kernel Example: Linux KVM Virtual Machine A Virtual Machine B VM A VM B Process Process Process Process Proc Proc Proc Proc VM Ctrl Proc Proc Kernel A Kernel B Kernel A Kernel B VMM (Virtual Machine Manager) a.k.a. Hypervisor Host Kernel (includes Hypervisor) CPU, I/O hardware CPU, I/O hardware Hypervisor does everything Hypervisor implanted in kernel CPU control, time sharing, and I/O in the same project CPU control, time sharing, and I/O in the same project Complex and dangerous Complex and dangerous NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 23

  24. Virtual Machines vs. Containers Virtual Machines Containers Virtual Machine A Virtual Machine B Container A Container B Process A1 Process A2 Process B1 Process B2 Process A1 Process A2 Process B1 Process B2 Kernel A Kernel B Kernel VMM (Virtual Machine Manager) a.k.a. Hypervisor Inherent safety Limited safety Kernel-HW interface was not designed for Kernel-Kernel communication Process-Kernel interface was designed for Process-Process communication VMM adds well-controled holes into a natural barrier Containerization requires blocking existing communication channels NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 24

  25. Virtual Machines vs. Containers Virtual Machines Containers Virtual Machine A Virtual Machine B Container A Container B init serv ices proc esses init serv ices proc esses init serv ices proc esses proc esses Kernel A Kernel B Kernel Container is not a complete OS VMM (Virtual Machine Manager) a.k.a. Hypervisor Services shared among containers Dependency hell still present Each VM is a complete OS Processes inside containers usually cannot control services outside containers - their install scripts cannot run inside containers Each VM runs its services in specific settings User (admin) processes (e.g. install scripts) can control services (edit /etc/..., run systemctl, ...) NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 25

  26. Plain vs. System Containers Plain Containers System Containers Container A Container B Container A Container B serv init init serv proc esses init serv proc esses init serv ices proc esses proc esses Kernel Kernel System container resembles a complete OS Container is not a complete OS Services shared among containers Dependency hell still present Each container contains its service manager (init) Processes inside containers usually cannot control services outside containers - install scripts cannot run inside containers Install scripts work inside containers The illusion is not yet complete Certain privileges/capabilities/roles are hardwired in Linux kernel and denied for containers NSWI150 Virtualizace a Cloud Computing - 2019/2020 David Bedn rek 26

Related


More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#