BACSE106: OPERATING SYSTEMS

Module 5:

Managing Devices, Security and

Protection and Virtualization

1
 MODULE 5 - OBJECTIVE

• To introduce modern developments like

virtualization, distributed operating
systems, and cloud-based systems.
 MODULE 5 - OUTCOME

• Analyze device management, protection

mechanisms, and virtualization
techniques in operating systems.
 MODULE 5: MANAGING DEVICES, SECURITY AND
PROTECTION AND VIRTUALIZATION

I/O device management basics: RAID structure, Disk structure, Disk

Scheduling Algorithms (FCFS, SSTF, SCAN, C-SCAN, LOOK, C-LOOK),
Program and network threats – Cryptography as a security tool – Domains of
protection – Access matrix – Capability based systems - Need for
virtualization - Virtual machines and architectures – Hypervisors -
Virtualization Technologies: Para Virtualization, Full Virtualization - OS-
Level Virtualization: Containers, Docker Basics, Containers vs Virtual
Machines.
RAID ARCHITECTURE
RAID (REDUNDANT ARRAY OF INDEPENDENT DISKS)

 Redundant array of inexpensive disks

 Multiple disk database design
 Set of physical disk drives viewed by the OS as a single
logical drive
 Data are distributed across the physical drives of an array
 Improve access time and improve reliability
 large storage capacity
 redundant data
 7 levels (6 levels in common use)
- differing levels of redundancy, error checking, capacity, and cost
STRIPING

 Take file data and map it to different disks

 Allows for reading data in parallel

file data block 0 block 1 block 2 block 3

Disk 0 Disk 1 Disk 2 Disk 3

PARITY

 Way to do error checking and correction

 Add up all the bits that are 1
 if even number, set parity bit to 0
 if odd number, set parity bit to 1
 To actually implement this, do an exclusive OR of
all the bits being considered
 Consider the following 2 bytes
byte parity
10110011 1
01101010 0
 If a single bit is bad, it is possible to correct it
MIRRORING

 Keep to copies of data on two separate disks

 Gives good error recovery
 if some data is lost, get it from the other source
 Expensive
 requires twice as many disks
 Write performance can be slow
 have to write data to two different spots
 Read performance is enhanced
 can read data from file in parallel
RAID LEVEL 0

 Not a true member of the RAID family - does not include

redundancy to improve performance.
 User and system data distributed across all disks in the array in
strips.
 Imagine a large logical disk containing ALL data. This is divided
into strips (physical blocks or sectors) that are mapped ‘round
robin’ to the strips in the array.
 A set of logically consecutive strips that maps exactly one strip to
each array member is referred to as a stripe.
+ If two different I/O requests are pending for two different
blocks of data – then there is a good chance that the data will be
on different disks and can be serviced in parallel.
+ If a single I/O request is for multiple logically continuous
strips – up to n strips can be handled in parallel.
DATA MAPPING FOR RAID LEVEL 0
 Thissoftware may execute either in the disk sub system or in a
host computer
RAID -0
 Recommended Applications
Very good performance, but at a price…
 Video Production and Editing
 Image Editing
 Any application requiring high bandwidth
 RAID LEVEL 1
 Redundancy achieved through duplicating complete file on disks.
 Data stripping is similar to RAID level 0.
 Each logic strip is mapped to two physical disks.
 Read request can be serviced from either of available 2 disks, which ever
involves the minimum seek time and rotational latency
 Write request requires both disks to be updated – but this can be done
in parallel. (Slower write dictates overall speed).
 Recover from failure is simple! (data may still be accessed from the
second drive
 Disadvantage:
 Cost
requires twice the disk space

Configuration is limited, so used only for system software and other

highly critical files.
 Improvement occurs if the application can split each read request so that
both disk members participate
RAID - 1
 Recommended Applications
 Accounting
 Payroll
 Financial
 Any application requiring very high availability
RAID Level 1 (Mirroring)
 RAID LEVEL 2
 Utilizes parallel access techniques - All disks participate in the execution of every I/O
request.
 Spindles of individual drives are synchronized so that each disk head is in the same
position on each disk at any given time.
 Data striping – very small strips (bit level striping).
 Error correcting code is calculated across corresponding bits on each disk, and the code
bits are stored in corresponding bit positions on multiple parity disks.
 For Hamming Code – number of parity (redundant) disks is proportionate to the log
of the number of data disks.
 On a single read, all disks are simultaneously accessed. The requested data and the
associated error correcting code are delivered to the array controller. Array controller
can detect and fix single bit errors.
 For write – all disks must be accessed.
 Adv: Requires fewer disks than level 1
 Big problem is performance
 must read data plus ECC code from other disks
 for a write, have to modify data, ECC, and parity disks

 RAID LEVEL 3
Byte level striping with parity
Similar to RAID 2 – parallel access with data distributed in small strips.
Requires only a single redundant disk because it uses a single parity bit for the set of
individual bits in the same position on all of the data disks.
If drives X0-X3 contain data, and X4 contains parity bits.
X4(i) = X3(i)  X2(i)  X1(i)  X0(i)
Redundancy – in the case of disk failure, the data can be reconstructed.
If drive X1 fails – it can be reconstructed as:
X1(i) = X4(i)  X3(i)  X2(i)  X0(i)
Performance – can achieve high transfer rates, but only one I/O request can be executed
at one time. (Better for large data transfers in non transaction-oriented environments).
 RAID LEVEL 4
 Each disk operates independently - Separate I/O requests satisfied in parallel.
 Suitable for applications with high I/O request rates and NOT well suited for those requiring high
data transfer rates.
 Data striping – Block level. (Strips are larger than in lower RAIDs) .
 Bit-by-bit parity strip is calculated across corresponding strips on each data disk, and stored in
corresponding strip on the parity disk.
 Performance – write penalty when I/O request is small size. Write must update user data +
corresponding parity bits.
 X4(i) = X3(i)  X2(i)  X1(i)  X0(i)
 If X1(i) is changed to X1’(i)
 X4(i) = X3(i)  X2(i)  X1’(i)  X0(i) = X4(i)  X1(i)  X1’(i)
 To calculate new parity, the old user and old parity strips must be read. Then it can update these
two strips with the new data and the newly calculated parity. Thus each strip write involves two
reads and two writes.
 Adv: Level-4 interleaves file blocks
 RAID LEVEL 5
 Same as RAID 4 – but parity strips are distributed across all disks.
 Typical allocation uses round-robin.

 For an n-disk array, the parity strip is on a different disk for the first
n strips and the pattern then repeats.
 Avoids potential bottleneck found in RAID 4.
RAID - 5

Recommended Applications
 File and Application servers
 Database servers
 WWW, E-mail, and News servers
 Intranet servers
 Most versatile RAID level
RAID LEVEL 6
 Two different parity calculations are carried out and stored in
separate blocks on different disks.
 Example: XOR and an independent data check algorithm => makes it
possible to regenerate data even if two disks containing user data fail.
 No. of disks required = N + 2 (where N = number of disks
required for data).
 Provides HIGH data availability.
 Incurs substantial write penalty as each write affects two parity
blocks.
 Three disks would have to fail within MTTR (mean time to repair)
interval to cause data to be lost
COMPARISON OF RAID LEVELS
Data Transfer
I/O request rate
Category Level Description Rate Typical application
(Read/Write)
(Read/Write)

applications
large strips: small strips: requiring high
Stripping 0 Nonredundant
excellent excellent performance for
non-critical data
System drives;
Mirroring 1 Mirrored Good/Fair Fair/fair
critical files
Bit-level striping
2 with hamming poor excellent
code parity

Parallel access large I/O request

Byte-level striping size
3 with dedicated poor excellent applications,
parity such as
imaging, CAD
Block level striping
4 with dedicated excellent/fair fair/poor
parity
Block-level striping
high request rate,
with
independent 5 excellent/fair fair/poor read intensive,
distributed
access data lookup
parity
block-level striping applications
with double requiring
6 excellent/poor fair/poor
distributed extreamly high
parity availability
COMPARISON OF RAID LEVELS
 Overview of Mass Storage Structure
• Magnetic disks provide bulk of secondary storage of modern computers
• Drives rotate at 60 to 250 times per second
• Transfer rate is rate at which data flow between drive and computer
• Positioning time (random-access time) is time to move disk arm to
desired cylinder (seek time) and time for desired sector to rotate under
the disk head (rotational latency)
• Head crash results from disk head making contact with the disk surface -
- That’s bad
• Disks can be removable
• Drive attached to computer via I/O bus
• Busses vary, including EIDE, ATA, SATA, USB, Fibre Channel, SCSI,
SAS, Firewire
• Host controller in computer uses bus to talk to disk controller built into
drive or storage array
24
 Hard Disks

• Platters range from .85” to 14” (historically)

• Commonly 3.5”, 2.5”, and 1.8”
• Range from 30GB to 3TB per drive
• Performance
• Transfer Rate – theoretical – 6 Gb/sec
• Effective Transfer Rate – real – 1Gb/sec
• Seek time from 3ms to 12ms – 9ms common for desktop drives
• Average seek time measured or calculated based on 1/3 of tracks
• Latency based on spindle speed
• 1 / (RPM / 60) = 60 / RPM
• Average latency = ½ latency

25
 Hard Disk Performance

• Access Latency = Average access time = average seek time + average latency
• For fastest disk 3ms + 2ms = 5ms
• For slow disk 9ms + 5.56ms = 14.56ms
• Average I/O time = average access time + (amount to transfer / transfer rate) +
controller overhead
• For example to transfer a 4KB block on a 7200 RPM disk with a 5ms average
seek time, 1Gb/sec transfer rate with a .1ms controller overhead =
• 5ms + 4.17ms + 0.1ms + transfer time =
• Transfer time = 4KB / 1Gb/s * 8Gb / GB * 1GB / 1024 2KB = 32 /
(10242) = 0.031 ms
• Average I/O time for 4KB block = 9.27ms + .031ms = 9.301ms

26
 Disk Scheduling
• The operating system is responsible for using hardware efficiently — for
the disk drives, this means having a fast access time and disk bandwidth
• Minimize seek time
• Seek time  seek distance
• Disk bandwidth is the total number of bytes transferred, divided by the
total time between the first request for service and the completion of the
last transfer

27
 Disk Scheduling (Cont.)
• There are many sources of disk I/O request
• OS
• System processes
• Users processes
• I/O request includes input or output mode, disk address, memory address,
number of sectors to transfer
• OS maintains queue of requests, per disk or device
• Idle disk can immediately work on I/O request, busy disk means work
must queue
• Optimization algorithms only make sense when a queue exists

28
 Disk Scheduling (Cont.)
• Note that drive controllers have small buffers and can manage a
queue of I/O requests (of varying “depth”)
• Several algorithms exist to schedule the servicing of disk I/O requests
• The analysis is true for one or many platters
• We illustrate scheduling algorithms with a request queue (0-199)
•
98, 183, 37, 122, 14, 124, 65, 67
• Head pointer 53

29
 FCFS
Illustration shows total head movement of 640 cylinders

30
 SSTF
• Shortest Seek Time First selects
the request with the minimum
seek time from the current head
position
• SSTF scheduling is a form of
SJF scheduling; may cause
starvation of some requests
• Illustration shows total head
movement of 236 cylinders

31
 SCAN
• The disk arm starts at one end of the disk, and moves toward the other
end, servicing requests until it gets to the other end of the disk, where
the head movement is reversed and servicing continues.
• SCAN algorithm Sometimes called the elevator algorithm
• Illustration shows total head movement of 208 cylinders
• But note that if requests are uniformly dense, largest density at other
end of disk and those wait the longest

32
SCAN (Cont..)

33
 Disk Scheduling: C-SCAN
• Provides a more uniform wait time than SCAN
• The head moves from one end of the disk to the other, servicing
requests as it goes
• When it reaches the other end, however, it immediately
returns to the beginning of the disk, without servicing any
requests on the return trip
• Treats the cylinders as a circular list that wraps around from the
last cylinder to the first one
• Total number of cylinders?

34
Disk Scheduling: C-SCAN

35
 C-LOOK

• LOOK a version of SCAN, C-

LOOK a version of C-SCAN
• Arm only goes as far as the last
request in each direction, then
reverses direction immediately,
without first going all the way to
the end of the disk
• Total number of cylinders?

36
 Selecting a Disk-Scheduling Algorithm
• SSTF is common and has a natural appeal
• SCAN and C-SCAN perform better for systems that place a heavy load on the
disk
• Less starvation
• Performance depends on the number and types of requests
• Requests for disk service can be influenced by the file-allocation method
• And metadata layout
• The disk-scheduling algorithm should be written as a separate module of the
operating system, allowing it to be replaced with a different algorithm if
necessary
• Either SSTF or LOOK is a reasonable choice for the default algorithm
• What about rotational latency?
• Difficult for OS to calculate 37
• How does disk-based queueing effect OS queue ordering efforts?
Protection and Security win-2025
38
PROTECTION AND SECURITY
CONCEPTS

 Protection:
 Mechanisms and policy to keep programs and users from accessing or
changing stuff they should not do
 Internal to OS

 Chapter 14 in Silbershatz

 Security:
 Issues external to OS

 Authentication of user, validation of messages, malicious or

accidental introduction of flaws, etc.

 Chapter 15 of Silbershatz

Protection and Security 39

GOALS OF PROTECTION

Operating system consists of a collection of

objects (hardware or software)

Each object has a unique name and can be

accessed through a well-defined set of
operations.

Protection problem – to ensure that each

object is accessed correctly and only by
those processes that are allowed to do so.
Protection and Security 40
GUIDING PRINCIPLES OF PROTECTION

 Principle of least privilege

 Programs, users and systems should be given just enough
privileges to perform their tasks

 Separate policy from mechanism

 Mechanism: the stuff built into the OS to make protection work
 Policy: the data that says who can do what to whom

Protection and Security 41

DOMAIN STRUCTURE

Access-right = <object-name, rights-set>

where rights-set is a subset of all valid
operations that can be performed on the object.

Domain = set of access-rights

42
CONCEPTUAL REPRESENTATION –
ACCESS MATRIX
 View protection as a matrix (access matrix)

 Rows represent domains

 Columns represent objects

 Access(i,
j) is set of operations that process
executing in Domaini can invoke on Objectj

Protection and Security 43

TEXTBOOK ACCESS MATRIX

 Columns are access control lists (ACLs)

 Associated with each object
 Rows are capabilities
 Associated with each user, group, or domain 44
UNIX & LINUX

 System comprises many domains:–

 Each user
 Each group
 Kernel/System

 (Windows has even more domains than this!)

Protection and Security 45

UNIX/LINUX MATRIX

file1 file 2 file 3 device domain

User/Domain 1 r rx rwx – enter

User/Domain 2 r x rx rwx –

User/Domain 3 rw – – – –

Columns are access control lists (ACLs)

 Associated with each object
Rows are capabilities
 Associated with each user or each domain 46
CHANGING DOMAINS (UNIX)

Domain = uid or gid

Domain switch via file access controls
 Each file has associated with it a domain bit
(setuid bit).
 rwS instead of rwx
 When executed with setuid = on, then uid or gid
is temporarily set to owner or group of file.
 When execution completes uid or gid is reset.

Separate mechanism for entering kernel

domain
 System call interface
Protection and Security 47
GENERAL (TEXTBOOK) REPRESENTATION

Domains as objects added to Access Matrix

48
PRACTICALITIES

At run-time…
 What does the OS know about the user?
 What does the OS know about the resources?

What is the cost of checking and enforcing?

 Access to the data
 Cost of searching for a match

Impractical to implement full Access Matrix

 Size
 Access controls disjoint from both objects and
domains
Protection and Security 49
ACLS VS. CAPABILITIES

Access Control List: Focus on resources

 Good if resources greatly outnumber users
 Can be implemented with minimal caching
 Can be attached to objects (e.g., file metadata)
 Good when the user who creates a resource has
authority over it
Capability System: Focus on users
 Good if users greatly outnumber resources
 Lots of information caching is needed
 Good when a system manager has control over
all resources
Protection and Security 50
BOTH ARE NEEDED

ACLs for files and other proliferating

resources
Capabilities for major system functions

The common OSs offer BOTH

 Linux emphasizes an ACL model
provides good control over files and resources that are
file-like
 Windows 2000/XP emphasize Capabilities
provides good control over access to system functions
(e.g. creating a new user, or doing a system backup…)
Access control lists for files

Protection and Security 51

…AND GOOD MANAGEMENT, TOO!

 What do we need to know to set up a new user or

to change their rights?
 …to set up a new resource or to change the rights
of its users?
 …Who has the right to set/change access rights?

 No OS allows you to implement all the possible

policies easily.

Protection and Security 52

ENFORCING ACCESS CONTROL

User level privileges must always be less

than OS privileges!
 For example, a user should not be allowed to
grab exclusive control of a critical device
 or write to OS memory space
…and the user cannot be allowed to raise
his privilege level!
The OS must enforce it…and the user
must not be able to bypass the controls
In most modern operating systems, the
code which manages the resource enforces
the policy Protection and Security 53
(TRADITIONAL) REQUIREMENTS–
SYSTEM CALL CODE
 No user can interrupt it while it is running
 No user can feed it data to make it
 violate access control policies
 stop serving other users
 No user can replace or alter any system call code
 No user can add functionality to the OS!

 Data must NEVER be treated as code!

Protection and Security 54

Virtual Machines

55
VIRTUAL MACHINES

 Overview

 History

 Benefits and Features

 Building Blocks

 Types of Virtual Machines and Their

Implementations
 Virtualization and Operating-System
Components
 Examples
CHAPTER OBJECTIVES

 Explore the history and benefits of virtual machines

 Discuss the various virtual machine technologies

 Describe the methods used to implement

virtualization
 Show the most common hardware features that
support virtualization and explain how they are used
by operating-system modules
 Discuss current virtualization research areas
OVERVIEW

 Fundamental idea – abstract hardware of a single

computer into several different execution environments
 Similar to layered approach
 But layer creates virtual system (virtual machine, or VM) on which
operation systems or applications can run
 Several components
 Host – underlying hardware system
 Virtual machine manager (VMM) or hypervisor – creates and runs
virtual machines by providing interface that is identical to the host
 (Except in the case of paravirtualization)
 Guest – process provided with virtual copy of the host
 Usually an operating system
 Single
physical machine can run multiple operating
systems concurrently, each in its own virtual machine
SYSTEM MODELS

Non-virtual machine Virtual machine

 IMPLEMENTATION OF VMMS

 Vary greatly, with options including:

 Type 0 hypervisors - Hardware-based solutions that provide support
for virtual machine creation and management via firmware
 IBM LPARs and Oracle LDOMs are examples
 Type 1 hypervisors - Operating-system-like software built to provide
virtualization
 Including VMware ESX, Joyent SmartOS, and Citrix XenServer
 Type 1 hypervisors – Also includes general-purpose operating
systems that provide standard functions as well as VMM functions
 Including Microsoft Windows Server with HyperV and RedHat Linux with
KVM
 Type 2 hypervisors - Applications that run on standard operating
systems but provide VMM features to guest operating systems
 Including VMware Workstation and Fusion, Parallels Desktop, and Oracle
VirtualBox
 IMPLEMENTATION OF VMMS (CONT.)

Other variations include:

 Paravirtualization - Technique in which the guest operating
system is modified to work in cooperation with the VMM to
optimize performance
 Programming-environment virtualization - VMMs do not
virtualize real hardware but instead create an optimized virtual
system
 Used by Oracle Java and [Link]
 Emulators – Allow applications written for one hardware
environment to run on a very different hardware environment,
such as a different type of CPU
 IMPLEMENTATION OF VMMS (CONT.)

 Application containment - Not virtualization at

all but rather provides virtualization-like features
by segregating applications from the operating
system, making them more secure, manageable
 Including Oracle Solaris Zones, BSD Jails, and IBM AIX
WPARs

Much variation due to breadth, depth

and importance of virtualization in
modern computing
HISTORY

 Firstappeared in IBM mainframes in 1972

 Allowed multiple users to share a batch-oriented
system
 Formal definition of virtualization helped move it
beyond IBM
1. A VMM provides an environment for programs that is essentially
identical to the original machine
2. Programs running within that environment show only minor
performance decreases
3. The VMM is in complete control of system resources
 Inlate 1990s Intel CPUs fast enough for researchers to
try virtualizing on general purpose PCs
 Xen and VMware created technologies, still used today
 Virtualization has expanded to many OSes, CPUs, VMMs
BENEFITS AND FEATURES

 Hostsystem protected from VMs, VMs protected from

each other
 i.e., A virus less likely to spread
 Sharing is provided though via shared file system volume, network
communication
 Freeze, suspend, running VM
 Then can move or copy somewhere else and resume
 Snapshot of a given state, able to restore back to that state
 Some VMMs allow multiple snapshots per VM
 Clone by creating copy and running both original and copy
 Great for OS research, better system development
efficiency
 Run multiple, different OSes on a single machine
 Consolidation, app dev, …
 BENEFITS AND FEATURES (CONT.)

Templating – create an OS + application VM,

provide it to customers, use it to create
multiple instances of that combination
Live migration – move a running VM from
one host to another!
 No interruption of user access
Allthose features taken together -> cloud
computing
 Using APIs, programs tell cloud infrastructure (servers,
networking, storage) to create new guests, VMs, virtual
desktops
 BUILDING BLOCKS

Generally difficult to provide an exact

duplicate of underlying machine
 Especially if only dual-mode operation available on CPU
 But getting easier over time as CPU features and support for
VMM improves
 Most VMMs implement virtual CPU (VCPU) to represent
state of CPU per guest as guest believes it to be
When guest context switched onto CPU by VMM, information from
VCPU loaded and stored
 Several techniques, as described in next slides
 BUILDING BLOCK – TRAP AND EMULATE

Dual mode CPU means guest executes in user

mode
 Kernel runs in kernel mode
 Not safe to let guest kernel run in kernel mode too
 So VM needs two modes – virtual user mode and virtual
kernel mode
 Both of which run in real user mode
 Actions in guest that usually cause switch to kernel mode
must cause switch to virtual kernel mode
TRAP-AND-EMULATE (CONT.)

 How does switch from virtual user mode to virtual kernel mode
occur?
 Attempting a privileged instruction in user mode causes an error -> trap
 VMM gains control, analyzes error, executes operation as attempted by guest
 Returns control to guest in user mode
 Known as trap-and-emulate
 Most virtualization products use this at least in part
 User mode code in guest runs at same speed as if not a guest
 But kernel mode privilege mode code runs slower due to trap-
and-emulate
 Especially a problem when multiple guests running, each needing trap-and-
emulate
 CPUs adding hardware support, mode CPU modes to improve
virtualization performance
TRAP-AND-EMULATE
VIRTUALIZATION IMPLEMENTATION
 BUILDING BLOCK – BINARY TRANSLATION

 Some CPUs don’t have clean separation between

privileged and nonprivileged instructions
 Earlier Intel x86 CPUs are among them
 Earliest Intel CPU designed for a calculator
 Backward compatibility means difficult to improve
 Consider Intel x86 popf instruction
 Loads CPU flags register from contents of the stack
 If CPU in privileged mode -> all flags replaced

 If CPU in user mode -> only some flags replaced

 No trap is generated
 BINARY TRANSLATION (CONT.)

 Othersimilar problem instructions we will call

special instructions
 Caused trap-and-emulate method considered impossible until 1998
 Binary translation solves the problem
1. Basics are simple, but implementation very complex
2. If guest VCPU is in user mode, guest can run instructions natively
3. If guest VCPU in kernel mode (guest believes it is in kernel mode)
a) VMM examines every instruction guest is about to execute by reading a
few instructions ahead of program counter
b) Non-special-instructions run natively
c) Special instructions translated into new set of instructions that perform
equivalent task (for example changing the flags in the VCPU)
 BINARY TRANSLATION (CONT.)

 Implemented by translation of code within VMM

 Code reads native instructions dynamically from guest,
on demand, generates native binary code that executes
in place of original code
 Performance of this method would be poor without
optimizations
 Products like VMware use caching
 Translate once, and when guest executes code containing special instruction
cached translation used instead of translating again
 Testing showed booting Windows XP as guest caused 950,000 translations, at
3 microseconds each, or 3 second (5 %) slowdown over native
BINARY TRANSLATION
VIRTUALIZATION IMPLEMENTATION
NESTED PAGE TABLES

 Memory management another general challenge to VMM

implementations
 How can VMM keep page-table state for both guests believing
they control the page tables and VMM that does control the
tables?
 Common method (for trap-and-emulate and binary translation) is
nested page tables (NPTs)
 Each guest maintains page tables to translate virtual to physical addresses
 VMM maintains per guest NPTs to represent guest’s page-table state
 Just as VCPU stores guest CPU state
 When guest on CPU -> VMM makes that guest’s NPTs the active system page
tables
 Guest tries to change page table -> VMM makes equivalent change to NPTs
and its own page tables
 Can cause many more TLB misses -> much slower performance
 BUILDING BLOCKS – HARDWARE ASSISTANCE

 All virtualization needs some HW support

 More support -> more feature rich, stable, better performance of
guests
 Intel added new VT-x instructions in 2005 and AMD the AMD-V
instructions in 2006
 CPUs with these instructions remove need for binary translation
 Generally define more CPU modes – “guest” and “host”
 VMM can enable host mode, define characteristics of each guest VM,
switch to guest mode and guest(s) on CPU(s)
 In guest mode, guest OS thinks it is running natively, sees devices (as
defined by VMM for that guest)
 Access to virtualized device, priv instructions cause trap to VMM

 CPU maintains VCPU, context switches it as needed

 HW support for Nested Page Tables, DMA, interrupts as well

over time
NESTED PAGE TABLES
TYPES OF VIRTUAL MACHINES
AND IMPLEMENTATIONS

 Many variations as well as HW details

 Assume VMMs take advantage of HW features
 HW features can simplify implementation, improve performance
 Whatever the type, a VM has a lifecycle
 Created by VMM
 Resources assigned to it (number of cores, amount of memory,
networking details, storage details)
 In type 0 hypervisor, resources usually dedicated
 Other types dedicate or share resources, or a mix
 When no longer needed, VM can be deleted, freeing resources
 Steps simpler, faster than with a physical machine
install
 Can lead to virtual machine sprawl with lots of VMs, history and
state difficult to track
 TYPES OF VMS – TYPE 0 HYPERVISOR

 Old idea, under many names by HW manufacturers

 “partitions”, “domains”
 A HW feature implemented by firmware
 OS need to nothing special, VMM is in firmware
 Smaller feature set than other types
 Each guest has dedicated HW

 I/O a challenge as difficult to have enough devices,

controllers to dedicate to each guest
 Sometimes VMM implements a control partition
running daemons that other guests communicate with
for shared I/O
 Can provide virtualization-within-virtualization (guest
itself can be a VMM with guests
 Other types have difficulty doing this
TYPE 0 HYPERVISOR
 TYPES OF VMS – TYPE 1 HYPERVISOR

 Commonly found in company datacenters

 In a sense becoming “datacenter operating systems”
 Datacenter managers control and manage OSes in new, sophisticated
ways by controlling the Type 1 hypervisor
 Consolidation of multiple OSes and apps onto less HW

 Move guests between systems to balance performance

 Snapshots and cloning

 TYPES OF VMS – TYPE 1 HYPERVISOR (CONT.)

 Special purpose operating systems that run natively on

HW
 Rather than providing system call interface, create run and manage
guest OSes
 Can run on Type 0 hypervisors but not on other Type 1s
 Run in kernel mode
 Guests generally don’t know they are running in a VM
 Implement device drivers for host HW because no other component can
 Also provide other traditional OS services like CPU and memory
management
 TYPES OF VMS – TYPE 1 HYPERVISOR (CONT.)

 Another variation is a general purpose OS that also

provides VMM functionality
 RedHat Enterprise Linux with KVM, Windows with Hyper-V, Oracle
Solaris
 Perform normal duties as well as VMM duties
 Typically less feature rich than dedicated Type 1 hypervisors

 Inmany ways, treat guests OSes as just another

process
 Albeit with special handling when guest tries to execute special
instructions
 TYPES OF VMS – TYPE 2 HYPERVISOR

 Less interesting from an OS perspective

 Very little OS involvement in virtualization
 VMM is simply another process, run and managed by host
 Even the host doesn’t know they are a VMM running guests
 Tend to have poorer overall performance because can’t take advantage
of some HW features
 But also a benefit because require no changes to host OS
 Student could have Type 2 hypervisor on native host, run multiple guests, all
on standard host OS such as Windows, Linux, MacOS
 TYPES OF VMS – PARAVIRTUALIZATION

 Doesnot fit the definition of virtualization – VMM not

presenting an exact duplication of underlying
hardware
 But still useful!
 VMM provides services that guest must be modified to use
 Leads to increased performance
 Less needed as hardware support for VMs grows

 Xen,leader in paravirtualized space, adds several

techniques
 For example, clean and simple device abstractions
 Efficient I/O
 Good communication between guest and VMM about device I/O

 Each device has circular buffer shared by guest and VMM via shared memory
XEN I/O VIA SHARED CIRCULAR BUFFER
 TYPES OF VMS – PARAVIRTUALIZATION (CONT.)

 Xen,leader in paravirtualized space, adds several

techniques (Cont.)
 Memory management does not include nested page tables
 Each guest has own read-only tables
 Guest uses hypercall (call to hypervisor) when page-table changes needed

 Paravirtualization allowed virtualization of older x86

CPUs (and others) without binary translation
 Guest had to be modified to use run on paravirtualized
VMM
 But on modern CPUs Xen no longer requires guest
modification -> no longer paravirtualization
 TYPES OF VMS –
PROGRAMMING ENVIRONMENT VIRTUALIZATION

 Also not-really-virtualization but using same techniques,

providing similar features
 Programming language is designed to run within custom-built
virtualized environment
 For example Oracle Java has many features that depend on running in Java
Virtual Machine (JVM)
 In this case virtualization is defined as providing APIs that define
a set of features made available to a language and programs
written in that language to provide an improved execution
environment
 JVM compiled to run on many systems (including some smart
phones even)
 Programs written in Java run in the JVM no matter the
underlying system
 Similar to interpreted languages
 TYPES OF VMS – EMULATION

 Another (older) way for running one operating system on a different

operating system
 Virtualization requires underlying CPU to be same as guest was
compiled for
 Emulation allows guest to run on different CPU
 Necessary to translate all guest instructions from guest CPU to native
CPU
 Emulation, not virtualization
 Useful when host system has one architecture, guest compiled for other
architecture
 Company replacing outdated servers with new servers containing
different CPU architecture, but still want to run old applications
 Performance challenge – order of magnitude slower than native code

 New machines faster than older machines so can reduce slowdown

 Very popular – especially in gaming where old consoles emulated on new
 TYPES OF VMS –
APPLICATION CONTAINMENT

 Some goals of virtualization are segregation of apps,

performance and resource management, easy start,
stop, move, and management of them
 Can do those things without full-fledged virtualization
 If applications compiled for the host operating system, don’t need full
virtualization to meet these goals
 Oraclecontainers / zones for example create virtual
layer between OS and apps
 Only one kernel running – host OS
 OS and devices are virtualized, providing resources within zone with
impression that they are only processes on system
 Each zone has its own applications; networking stack, addresses, and
ports; user accounts, etc
 CPU and memory resources divided between zones
 Zone can have its own scheduler to use those resources
SOLARIS 10 WITH TWO ZONES
VIRTUALIZATION AND
OPERATING-SYSTEM COMPONENTS

Now look at operating system aspects of

virtualization
 CPU scheduling, memory management, I/O, storage, and
unique VM migration feature
How do VMMs schedule CPU use when guests believe they have
dedicated CPUs?
How can memory management work when many guests require

large amounts of memory?

 OS COMPONENT – CPU SCHEDULING

 Evensingle-CPU systems act like multiprocessor ones

when virtualized
 One or more virtual CPUs per guest
 Generally
VMM has one or more physical CPUs and
number of threads to run on them
 Guests configured with certain number of VCPUs
 Can be adjusted throughout life of VM
 When enough CPUs for all guests -> VMM can allocate dedicated
CPUs, each guest much like native operating system managing its
CPUs
 Usually not enough CPUs -> CPU overcommitment
 VMM can use standard scheduling algorithms to put threads on CPUs
 Some add fairness aspect
OS COMPONENT –
CPU SCHEDULING (CONT.)

Cycle stealing by VMM and oversubscription

of CPUs means guests don’t get CPU cycles
they expect
 Consider timesharing scheduler in a guest trying to schedule
100ms time slices -> each may take 100ms, 1 second, or longer
 Poor response times for users of guest
 Time-of-day clocks incorrect

 Some VMMs provide application to run in each guest to fix

time-of-day and provide other integration features
 OS COMPONENT – MEMORY MANAGEMENT

 Also suffers from oversubscription -> requires extra management

efficiency from VMM
 For example, VMware ESX guests have a configured amount of
physical memory, then ESX uses 3 methods of memory
management
1. Double-paging, in which the guest page table indicates a page is in a physical
frame but the VMM moves some of those pages to backing store
2. Install a pseudo-device driver in each guest (it looks like a device driver to
the guest kernel but really just adds kernel-mode code to the guest)
 Balloon memory manager communicates with VMM and is told to allocate or de-
allocate memory to decrease or increase physical memory use of guest, causing guest
OS to free or have more memory available
3. De-duplication by VMM determining if same page loaded more than once,
memory mapping the same page into multiple guests
 OS COMPONENT – I/O

 Easierfor VMMs to integrate with guests because I/O has lots of

variation
 Already somewhat segregated / flexible via device drivers
 VMM can provide new devices and device drivers
 But overall I/O is complicated for VMMs
 Many short paths for I/O in standard OSes for improved performance
 Less hypervisor needs to do for I/O for guests, the better
 Possibilities include direct device access, DMA pass-through, direct interrupt
delivery
 Again, HW support needed for these

 Networking also complex as VMM and guests all need network

access
 VMM can bridge guest to network (allowing direct access)
 And / or provide network address translation (NAT)
 NAT address local to machine on which guest is running, VMM provides address translation
to guest to hide its address
 OS COMPONENT – STORAGE MANAGEMENT

 Both boot disk and general data access need be provided by VMM
 Need to support potentially dozens of guests per VMM (so standard disk
partitioning not sufficient)
 Type 1 – storage guest root disks and config information within file
system provided by VMM as a disk image
 Type 2 – store as files in file system provided by host OS

 Duplicate file -> create new guest

 Move file to another system -> move guest

 Physical-to-virtual (P-to-V) convert native disk blocks into VMM

format
 Virtual-to-physical (V-to-P) convert from virtual format to native or
disk format
 VMM also needs to provide access to network attached storage (just
networking) and other disk images, disk partitions, disks, etc.
 OS COMPONENT – LIVE MIGRATION
 Taking advantage of VMM features leads to new functionality not found on
general operating systems such as live migration
 Running guest can be moved between systems, without interrupting user
access to the guest or its apps
 Very useful for resource management, maintenance downtime windows, etc.
1. The source VMM establishes a connection with the target VMM
2. The target creates a new guest by creating a new VCPU, etc.
3. The source sends all read-only guest memory pages to the target
4. The source sends all read-write pages to the target, marking them as clean
5. The source repeats step 4, as during that step some pages were probably
modified by the guest and are now dirty
6. When cycle of steps 4 and 5 becomes very short, source VMM freezes guest,
sends VCPU’s final state, sends other state details, sends final dirty pages,
and tells target to start running the guest
 Once target acknowledges that guest running, source terminates guest
LIVE MIGRATION OF GUEST BETWEEN SERVERS
 EXAMPLES - VMWARE

 VMware Workstation runs on x86, provides VMM for

guests
 Runs as application on other native, installed host
operating system -> Type 2
 Lots of guests possible, including Windows, Linux, etc.
all runnable concurrently (as resources allow)
 Virtualization layer abstracts underlying HW,
providing guest with is own virtual CPUs, memory,
disk drives, network interfaces, etc.
 Physical disks can be provided to guests, or virtual
physical disks (just files within host file system)
VMWARE WORKSTATION ARCHITECTURE
EXAMPLES – JAVA VIRTUAL MACHINE

 Example of programming-environment virtualization

 Very popular language / application environment invented by Sun
Microsystems in 1995
 Write once, run anywhere

 Includes language specification (Java), API library, Java virtual

machine (JVM)
 Java objects specified by class construct, Java program is one or
more objects
 Each Java object compiled into architecture-neutral bytecode
output (.class) which JVM class loader loads
 JVM compiled per architecture, reads bytecode and executes
 Includes garbage collection to reclaim memory no longer in use

 Made faster by just-in-time (JIT) compiler that turns bytecodes

into native code and caches them
THE JAVA VIRTUAL MACHINE
DOCKER
 Docker is a tool that simplifies the process of developing,
packaging, and deploying applications. By using containers,
Docker allows you to create lightweight, self-contained
environments that run consistently on any system,
minimising the time between writing code and deploying it
into production

103
CONTAINERS

 Containers virtualize the operating system for lightweight,

fast applications by sharing the host's kernel, while virtual
machines virtualize the hardware to create full, isolated OS
instances, requiring more resources and having slower
startup times. VMs are best for running different operating
systems and legacy applications with strong isolation,
whereas containers are ideal for microservices and cloud-
native applications due to their speed, efficiency, and
scalability.

104
CONTAINERS AND VIRTUAL MACHINES
 Containers are an abstraction at the app layer that packages code
and dependencies together. Multiple containers can run on the
same machine and share the OS kernel with other containers,
each running as isolated processes in user space. Containers take
up less space than VMs (container images are typically tens of
MBs in size), can handle more applications and require fewer VMs
and Operating systems
 Virtual machines (VMs) are an abstraction of physical hardware
turning one server into many servers. The hypervisor allows
multiple VMs to run on a single machine. Each VM includes a full
copy of an operating system, the application, necessary binaries
and libraries – taking up tens of GBs. VMs can also be slow to
boot.

105
CONTAINERS AND VIRTUAL MACHINES

106
107