introduction to virtualization (part 4)

Big Reveal (finally discussing OS Virtualization)

plus Some Taxonomy and Vernacular of the Field,

Some intro into CPU Virtualization

As Needed to Understand OS Virtualization

Culmination of Last Talk(remember, we know nothing about OS

Virtualization from previous talks)

• Operating systems schedule software threads onto logical cores (usually there are 2 logical cores per physical core, but in general there can be N logical cores per physical core)

• A “process” is a group of software threads that share the same virtual memory (and thus it is easier to context switch between software threads of same process)

Mental fuzzy picture that should feel warm inside now:

Thread 2 of

Process 1

Single thread of Process 2

Thread 1 of

Process N

Thread 2 of

Process N

Operating System Kernel

Thread 1 of

Process 1

System Call Interface

Process 1 Process NProcess 2

…

Hardware stuff (not directly visible/accessible by applications)

Recap: Evolution of Computing Systems Along Two Axes

Hardware

Softw

are

Pre-historic times (e.g., Intel 386 with DOS):1 CPU/core, running 1 process at a time (and only program loaded into RAM)No virtual memory. A running program would “give up CPU” on its own.

Hardware and software evolved together

Multi-processing, Simultaneous multi-threading, smarter/faster cache/TLB

Mul

ti-pr

ogra

mm

ing,

virt

ual

mem

ory,

mul

ti-th

read

ing

Early 2000s:Several logical cores, many software threads running concurrently (context switched pre-emptively), with everything living in virtual memory at same time.


Process 1

Does an application care how the hardware resources are arranged? Usually not…

Thread 2 of

Process 1

Single thread of Process

M

Thread 1 of

Process N

Thread 2 of

Process N


Thread 1 of

Process 1


Process 1 Process NProcess M



Hardware stuff (not directly visible/accessible by applications) Someone asked the question: Why not run these two kernels on the same host?

… …

Multiple servers: Realized with Multiple Physical Hosts


Process 1

Thread 2 of

Process 1


M

Thread 1 of

Process N

Thread 2 of

Process N

Operating System Kernel 1

Thread 1 of

Process 1



Operating System Kernel K


Hardware (CPU, MEM, IO) Hardware (CPU, MEM, IO)

… …

…

Multiple servers: On 1 Physical Host(OS Virtualization … done !!?!?!)


Process 1

Thread 2 of

Process 1


M

Thread 1 of

Process N

Thread 2 of

Process N


Thread 1 of

Process 1





Hardware (CPU, MEM, IO)

… …

…

Problem With Previous Scheme• Sometimes, like in this case, when you have

“…” in an abstraction layer it means you are juggling multiple things

• What is doing this juggling/multiplexing? • Surely, we cannot simply install multiple OSes

directly on your host and expect all this to work.

Operating System Kernel Operating System Kernel


…

We need a new abstraction layer: The Virtualization Layer

to multiplex multiple operating systems onto same hardware:


Process 1

Thread 2 of

Process 1


M

Thread 1 of

Process N

Thread 2 of

Process N

Operating System Kernel 1(Called Guest OS 1)

Thread 1 of

Process 1



Operating System Kernel K(Called Guest OS K)



… …

…

Virtualization Layer (Software that time multiplexes guest operating systems)

One way of realizing The Virtualization Layer:

• Install a base operating system on hardware• Then install another special software on that

operating system which allows for the multiplexing of virtual machines

• Thus, the virtualization layer itself can have 2 distinct layers:

i.e., above is realized as:Virtualization Layer

Base Operating system

Special VM enabling software

The Special Virtualization Software:Type 2 Hypervisor

• Why number “2”? Good way to remember this arbitrary numbering scheme- Type 2 hypervisors are part of a 2 layered virtualization layer design:






…

Base Operating system

Type 2 Hypervisor, a.k.a. “hosted hypervisor”

…

…

Examples of Type 2 Hypervisors• Cheaper VMWare hypervisors : VMWare fusion,

VMWare workstation, …• Oracle Virtual Box• Usually run Type 2 hypervisors on our desktop PCs• Some of us use these to run a single or 2 VMs of a

“different OS” type from base OS on our PCs because we do not want to dual boot :P

• HOW: We already have a base OS installed, then we “install” the type 2 hypervisor, then we add VMs for it to manage (i.e., 2 installs needed, base OS, then the hypervisor to bootstrap virtualization layer)

• Perf?? Can we run high perf DPI solutions on these?

Alternative: Type 1 Hypervisors






… …

…

Type 1 Hypervisor (a.ka. Bare-metal hypervisor)

Full-blown operating system or a stripped down operating system installed directly on hardware which and act as a VM multiplexer…. 1 layer architecture

• A.k.a. “bare metal hypervisors” or “native hypervisors”( “bare metal” alone does not mean this, one must say “bare metal hypervisor” to mean this)

• Examples– Microsoft Hyper-V (part of MS Windows)– Citrix Xenserver (part of Linux)– KVM, kernel virtual machine (part of Linux)– VMWare ESX/ESXi (previously sort of used Linux, but developed

their own operating system – vmkernel)

Examples of Type 1 Hypervisors

Some people call KVM a Type 1.5 hypervisor (and some other people incorrectly call it type 2 hypervisor) because one still might need to install the KVM loadable kernel modules into OS kernel. Regardless, these modules are “inside” the kernel itself, so it’s not appropriate to call it a separate “layer” (i.e., KVM is not a type 2 hypervisor)

For now let’s stick with Type 1 Kernels• 1 extra abstraction layer, easier to reason with (and easier to

peek at internals of design)• If hypervisor is essentially another operating system, then how

does this hypervisor “see” and “manage” the guest operating systems? Answer: Processes.






… …

…

Type 1 Hypervisor Operating System Kernel

Process in Hypervisor Kernel Process in Hypervisor Kernel

VM 2 / Guest OSVM 1 / Guest OS


…


Process in Hypervisor Kernel Process in Hypervisor Kernel

It does not necessarily know or need to know about internal details/state, i.e., the programs running within the Guest OSes. Thus, hypervisor’s perspective:

Hypervisor manages and sees the GUEST VMs systems as its own processes

VM / Guest OS

Side note: Regular processes usually run alongside the VM processes.

VM / Guest OS

VM 1 / Guest OS


…


…

This is a detail that should be kept in back of your head, butneed not be mentioned on every slide (makes picturesunnecessarily complex for topics being introduced per slide)

So back to this abstract Type 1 Hypervisor…

VM / Guest OS

VM / Guest OS

VM 1 / Guest OS


…


Questions: • Are these VM processes made up of single thread each?• If they are made up of multiple threads, what does each

thread represent? Wait for it…Ye

s, ye

s, th

e war

m an

d fu

zzy f

eelin

g is b

uild

ing

within

me.

A vi

rtual

mac

hine

is ju

st a p

roce

ss in

the T

ype 1

kern

el! I

get i

t!

CPU Virtualization• We learned in the first part of this series that

computing systems are made up of 3 main types of hardware: {CPU, MEM, IO}

• We also learned that each of these have to be virtualized (in somewhat separate ways)

• The most important of these to understand is the virtualization of the actual CPUs (lcores)

• Each GUEST MACHINE/OS has to be provided with “virtual” logical cores by the hypervisor(i.e., real logical cores have to be shared and exposed as “virtual CPUs” to GUEST OSes)

• How????

CPU Virtualization• One ore more ‘vCPU’s are exposed to the Guest OS (as

real logical cores from VM’s perspective)• Let’s go through the scheduling of a software thread

BY THE GUEST OS:– The GUEST OS schedules software threads it manages onto

the lcores it sees (which are really vCPUs provided by hypervisor OS)

– When a software thread actually runs on an lcore within GUEST OS, from the HYPERVISOR OS’s perspective, this is really running as part of a software thread within the VM Process that is intended to emulate the vCPU

– Thus: lcore inside VM == vCPU provided by hypervisor == software thread in the VM process managed by hypervisor

CPU Virtualization (try 2)Assume a guest OS was allocated 2 vCPUs by the person who created it (i.e., sysadmin).

From a virtualization perspective, since a guest OS is really is being lied to (i.e., vCPUs),the organization of sockets/cores-per-socket/lcores-per-socket does not really matter.

It’s typical in KVM/libvirt to actually expose a layout like this to a 2vCPU guest OS:

[sandvine@demo-stack-1-pts ~]$ ./cpu_layout.py============================================================Core and Socket Information (as reported by '/proc/cpuinfo')============================================================

cores = [0]sockets = [0, 1]

Socket 0 Socket 1 -------- --------Core 0 [0] [1]

In other words, from within the VM, its it sees 2 lcores corresponding to the 2vCPUsprovided to it by the sysadmin.

CPU Virtualization (try 2 cont…)

• So the GUEST OS has 2 lcores to schedule software threads onto:

• End of the day, only the lcores are important within a VM, so we can abstract out the socket/core/lcore organization and simply look at lcores:

2 x (1 lcore==1core==1socket) Logical Core

Logical Core

Logical Core

Logical Core

CPU Virtualization • Each vCPU (seen as real lcores in

guest) is really running WITHIN 1 software thread of the overall VM process on the host OS:

vCPU ==SoftwareThread

vCPU ==SoftwareThread


VM == Process

Zoomed out (from host perspective):

Zoomed in (inside guest OS):“I am a full fledged OS, and I seem to have 2 logical cores to use”:

lcore lcore

CPU Virtualization• (Assuming we have too much of MEM and IO(Disk) )

• What is stopping us from launching 100 VMs, each with 10vCPUs, even if our host has 20 total lcores?

• Nothing really. Hypervisor will create 100 VM processes (virtual machines), each with 10 vCPUs,which each guest sees as 10 lcores.

• The 100x10 vCPU threads will bounce around on the 20 “real” lcores on the host… hope your applications running in the VMs can handle small time slices of real compute time each :P

• The above example has a “CPU Oversubscription ratio of” == 1000 vCPUs / 20 lcores(on host) == 50

CPU/MEM/IO Virtualization• There will be a deeper dive on CPU, MEM, IO in

future…• For now, remember that (Type 1 hypervisor):– A VM/GuestOS in its entirety runs as a process in the

Type 1 kernel/HostOS– The lcores(vCPUs) seen from within VM (e.g. output

of grep processor /proc/cpuinfo or cpu_layout.py) correspond to software threads within VM process

– Side note: There might be “other” extra software threads within VM process too (an implementation/ hypervisor specific detail)

Enough Talking

• Prove some of this stuff… live demo.

introduction to virtualization (part 4)

Engineering