virtualisation Flashcards
why do we use virtualisation
makes better use of machine resources
allows platforms to appear as completely independent
what are some of the features of virtualisation
base images/templates
snapshots
clone
live migration
clone
copy the snapshot
base images/templates
pre-canned installations that can be modified or replicated
snapshots
capture and preserve the entire state of the machine which can then be resurrected or moved to a different machine
live migration
stop the os and reload/resume on another machine
type 0 virtualisation
e.g. mainframe
hardware support allows hardware partitioning
groups of resources can be under the control of different os
type 1 virtualisation
e.g. linux
os based virtualisation
type 2 virtualisation
e.g. vmware virtual box
user space virtualisation therefore it doesnt require support from the underlying system
what are the two alternative types of virtualisation
containers
emulations
containers
e.g. docker
replicates some of the internal data structures of an existing os and makes it appear that there are multiple instances of it
emulations
e.g. qemu
emulates the underlying system and can load another os on top of it
what are some of the low level elements of a system that the os needs to control
processors
interrupt and timer systems
memory management system
direct access to all io subsystems
how does unsupported virtualisation work
the host os runs as normal in the kernel/supervisor space, protecting components
the guest os runs in the user space so its seen as a regular application level process
all apps run in user space
unsupported virtualisation
type 2: no assistance from the underlying platform
how does “unsupported” virtualisation work on the x86
host = ring level 0
guest = ring level 1
apps = ring level 3
the apps dont impact the guest while it still has more rights than the user
the host stays the most privileged
what are two issues with implementing “unsupported” virtualisation work on the x86 and how would we go around them
not portable: usually only supports user and kernel space
some instructions work differently in different levels and some dont work at all so we must either emulate what the instruction would do or dynamically rewrite the instructions to emulate what its meant to do
para-virtualisation
the os understands that they could be running as the host or guest
how does para-virtualisation work
if the os is running as a host then it acts as normal
if running as the guest theyll make calls to the host to carry out functions on its behalf
if the host gets events meant for the guest then itll do an up-call to it to signal that an io event has occurred instead of normal interrupt handling
what are the dangers of para-virtualisation
we dont want the kernel to be overly dependant on one os
dont want different kernels
dont want the difference between the host and guest to be visible to other apps and services
first gen model of virtualisation (os hosted vm monitor)
guest os is on top of the os and drivers
to access a device you go through the underlying os and the request is managed and passed to the appropriate device driver
positive of first gen model of virtualisation
flexible: well established set of drivers
negative of first gen model of virtualisation
inefficient: fine granularity access to drivers
second gen model of virtualisation (standalone hypervisor)
guest os on top of the minimal hypervisor
guest can go into the hypervisor and make direct use of device drivers
