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
positive of second gen model of virtualisation
efficient and lightweight
negative of second gen model of virtualisation
the hypervisor has its own provider therefore the device drivers arent written for it so wed usually use a generic driver
however most of the additional features and performance for devices is only available if you use the driver made for it
third gen model of virtualisation (hybrid vmm)
service vm with a device driver on it which provides a host for the drivers
everything is then on top of the micro-hypervisor
positive of third gen model of virtualisation
lightweight with driver support
how do we access memory in a vm
request go through a mapping with the guest then another with the host
creating a 4 level nested page table
what is the layout of a pci address
1st part = the bus the device is on
2 = which device on the bus
3 = which function on the device
why do we use the pci address (+)
allows us to add protection domains
how do protection domains work
one domain per function
each domain has its own IO-MMU page table
how do we access memory through the shadow tables
the bus = page directory
the device and function number is the index in the table which stores the mapping for the address in memory
what is the role of the IO-MMU
provides vm level protected dma
how does intel VT-d IO-MMU work
allows a shadow copy of the page tables being used by the processors for the devices in the system
we can define the tables based on which devices are talking to which parts of memory
how does single root io virtualisation (SR-IOV) work
the host os can access a devices physical function and configure the device to instaciate a number of virtual functions and each vm binds to one of the virtual interfaces
virtual function
an instance of a function of a device that is individually addressable
