Xen (Virtual Machine Monitor)

Operating systems laboratory

Esmail asyabi- April 2015

Cloud Computing environments

Virtualization technology

• Consolidation• Isolation• Migration

• virtual machines running on a Xen Project Hypervisor are known

as “domains”

• special domain known as dom0 is responsible for controlling the

hypervisor and starting other guest operating systems. These

• other guest operating systems are called domUs, this is because

these domains are “unprivileged” in the sense they cannot control

the hypervisor or start/stop other domains.

Consolidation

Virtual machine monitors enable server consolidation

Consolidated domains have wildly different workloads

Streaming Media Server

Voice-over-IP Server

Application Server

Web Server

Database Server

. . .

Virtualized Host

Guest Domain 1

Guest Domain 2

Guest Domain 3

Guest Domain 4

. . .

consolidation

Hypervisor – thin virtualization layer Driver Domain – hardware control Guest domains given restricted access

Xen Architecture

Hardware

DriverDomain

Xen ControlSoftware

Guest Domain

UserSoftware

GuestDomain

UserSoftware

GuestDomain

UserSoftware

Xen Hypervisor

Xen Architecture

Xen Architecture

Receiving a Network Packet

time

Hardware

DriverDomain

Xen ControlSoftware

Guest Domain

UserSoftware

GuestDomain

UserSoftware

GuestDomain

UserSoftware

Xen Hypervisor

Har

dwar

eIn

terr

upt

Virt

ual

Inte

rrup

t

Driv

er D

omai

n

Targ

et D

omai

n

Sche

dule

r

Sche

dule

r

Virt

ual

Inte

rrup

t

Pack

et A

rriv

es

VM life cycle

Scheduler Fairness Virtual machine monitors must fairly support

both computation and I/O domains Xen supports computation domains well, but has

mixed results with I/O domains

The scheduler plays a significant role in I/O performance Improvements for I/O are not obvious Some of Xen’s current scheduler optimizations for

I/O are beneficial, others are not

Credits are assigned to each domain Approximate the fraction of processor resources

each domain will receive Do not indicate when each domain will receive its

fraction

Scheduler increments/decrements credits Periodically deducts credits from running domain Adds credits when majority of credits in the

system have been consumed

Xen’s Credit Scheduler

Scheduler Operation Domain states

Under – domain has credits remaining Over – domain is over its credit allowance

Domains are run in FIFO order by state Over domains only run if no under domains A domain may run for up to 30ms if it has enough credits

After running, return to the run queue by state Behind all other domains in the same state Regardless of runtime or remaining credits

This approach is biased against I/O

O2 O1

Run Queue

U4 U2U3Next domain

to runU1

Scheduler “Optimizations” for I/O I/O Domain Requirements

Low latency High bandwidth Independent of other domains’ workloads

“Optimizations” Boosting idle domains

Included in Xen Ordering the run queue by credits

Proposed for Xen Tickling the scheduler

Included in Xen

Boosting Idle Domains Initially, scheduler had no special features for

I/O domains

Additional scheduling state: boost Higher priority than under Used when an idle domain is sent a virtual interrupt

With boost

O2 O1 U1U4 U2U3

I1U5

O2 O1 U1U4 U2U3

I1B1

Next domainto run

Next domainto run

Impact of Boost Boost improves latency for I/O domains

0

50

100

150

200

250

300

350

400

Time

La

ten

cy

(m

s)

No Boost Boost

Ordering the Run Queue

• I/O domains tend to quickly block

• Within each state, sorts domains by credits remaining

• Short-running I/O domains are re-inserted near the head of the run queue

Impact of Ordering the Run Queue Ordering the run queue can reduce latency for

I/O domains under larger loads Surprisingly, often complements boost

• Project1

• Disable Boost mechanism

• Define a QoS strategy

• Modify the scheduler in such a way it can support your

Predefined fairness strategy.

• http://webpages.iust.ac.ir/e_asyabi/osl