Virtualization — type 1 and type 2 hypervisors: Exercises

4.2.40 · D4 · Coding › Operating Systems › Virtualization — type 1 and type 2 hypervisors

Shuru karne se pehle, ek picture poore page ko ek saath tie karti hai — layer stack. Neeche jo bhi grade karte hain woh sab actually ek hi sawaal hai: guest aur silicon ke beech kitne boxes baithe hain. Abhi ise study karo; almost har solution isi par point karta hai.

Figure — Virtualization — type 1 and type 2 hypervisors

Intuition Figure padhna (poora text description, koi colour ki zaroorat nahi)

Figure mein do vertical stacks of labelled boxes hain, side by side bane hain. Har stack ko upar se neeche padho; box ke names har box ke andar print hain, isliye tumhe kabhi colour par rely nahi karna padega.

Left stack — "TYPE 1 (bare-metal)", teen boxes:

top box labelled Guest OS (VM)
middle box labelled Hypervisor
bottom box labelled Hardware (metal) Ek downward arrow Guest OS box se, Hypervisor box se hote hue, Hardware box tak jaata hai. Uske paas text likha hai "1 arrow below guest".

Right stack — "TYPE 2 (hosted)", chaar boxes:

top box labelled Guest OS (VM)
box labelled Hypervisor (app)
box labelled Host OS ← woh extra box jo Type 1 mein nahi hai
bottom box labelled Hardware (metal) Do downward arrows ("crossing 1", "crossing 2") ek request ko Guest OS se Hypervisor ke through, phir Host OS ke through, Hardware tak le jaate hain. Uske paas text likha hai "2 arrows below guest (+1 host hop)".

Ek idea: Type 2 mein sirf ek extra Host OS box hai, yehi structural difference hai, jo hardware tak jaane wale path par exactly ek aur downward arrow add karta hai. Woh ek extra arrow hi is poore page ki performance story hai.

Definition Arrows kis direction mein point karte hain? (yeh ek baar define karo, har jagah use karo)

Ek down-arrow (guest → hypervisor → … → hardware) ek request hai jo metal ki taraf travel kar rahi hai — "main real hardware par kuch karna chahta hoon." Is page par gine jaane wale har layer crossing mein ek down-arrow hota hai; figure mein yeh explicitly draw kiye gaye hain.
Ek up-arrow woh hai jo ek trap karta hai: ek demoted guest ek privileged instruction run karta hai, aur CPU control ko upar jump karta hai zyada-privileged supervisor (hypervisor) ke paas. Hum kehte hain guest hypervisor mein "trap up" karta hai. Up-arrows figure mein draw nahi hain — inhe yaad rakho ki CPU momentarily control ko ek box upar lift karta hai taaki hypervisor result ko fake kar sake. Toh: crossings = down-arrows (requests going down); traps = up-arrows (control jumping up).

Definition Teen words jo question 1 se pehle tumhare paas hone chahiye

Bare metal — raw physical hardware (CPU, RAM, disk) jisme kuch bhi install nahi hai. Socho "ek nayi empty PC jise kabhi switch on nahi kiya gaya." Yeh figure ke dono stacks ka bottom box hai (labelled Hardware (metal)).
Host OS — ek normal, general-purpose operating system (Windows, macOS, desktop Linux) jo hardware ka maalik hai aur ordinary programs chalata hai. Yeh woh extra box labelled Host OS hai jo sirf Type 2 (right) stack mein appear karta hai.
Trap — jab ek guest ek privileged instruction (jo sirf kernel hi run kar sakta hai) try karta hai, CPU guest ko freeze karta hai aur control upward jump karta hai (ek up-arrow) ek zyada privileged supervisor ke paas. Dekho System Calls and Traps. Hypervisor is jump ko use karta hai result ko safely fake karne ke liye.

Level 1 — Recognition

Recall Solution L1.1

ESXi ne machine ko khud boot kiya — yeh metal par base software hai. Uske neeche koi general-purpose host OS nahi hai. Answer: Type 1 (bare-metal). ESXi metal par baitha hai. Figure mein yeh left (Type 1) stack hai: Hypervisor box seedha Hardware (metal) box par baitha hai, beech mein koi Host OS box nahi hai. Guest ke neeche down-arrows count karo: guest → ESXi → hardware = 1 crossing.

Recall Solution L1.2

Path: Ubuntu guest → VirtualBox hypervisor → Windows 11 host OS → CPU. Yeh figure mein right (Type 2) stack hai — Host OS box present hai. Guest ke neeche do down-arrows hain, toh 2 crossings (hypervisor + host OS). Answer: Type 2 (hosted), 2 layers.

Recall Solution L1.3

Type 1 (bare-metal, left stack — koi Host OS box nahi): Xen, Hyper-V, VMware ESXi.
Type 2 (hosted, right stack — ek Host OS box hai): VirtualBox, VMware Workstation, Parallels. Pehchaan: Type 1 names woh cheezein hain jo tum machine ka base banane ke liye install karte ho; Type 2 names woh hain jinhe tum desktop OS ke andar double-click karte ho.

Level 2 — Application

Recall Solution L2.1

KVM ek kernel module hai jo running Linux kernel ko hi hypervisor mein badal deta hai. Linux kernel dono hai — bare-metal OS bhi aur VMM bhi — hypervisor aur metal ke beech koi alag host-OS application layer nahi hai. Figure terms mein, Hypervisor box aur (jo hota) Host OS box ek box mein fuse ho jaate hain jo metal par baitha hai, jisse left (Type 1) stack ki shape milti hai. Toh guest seedha ek privileged hypervisor se baat karta hai. Answer: effectively Type 1 (the classic "hybrid"). Exam-safe phrasing: "Type 1 hybrid — the kernel is the hypervisor."

Recall Solution L2.2

Guest B ke I/O path mein ek extra host-OS hop hai — figure ke right stack mein woh extra Host OS down-arrow: B → hypervisor → Windows → hardware, jabki A ka path hai A → Hyper-V → hardware. Ek kam down-arrow = ek kam crossing = kam per-request latency, aur I/O woh jagah hai jahan woh overhead concentrate hota hai. Answer: Guest A (Hyper-V, Type 1) faster hai.

Recall Solution L2.3

Woh poora laptop dedicate nahi kar sakte, aur unhe raw speed se zyada convenience chahiye. Answer: Type 2 (hosted) — e.g. VirtualBox ya VMware Workstation Player. Yeh Windows ke upar kisi bhi app ki tarah install hota hai (figure mein Host OS box bana rehta hai) aur uske saath coexist karta hai. Yeh exactly dev/test use case hai.

Level 3 — Analysis

Recall Solution L3.1

Har down-arrow $δ$ add karta hai; figure mein guest ke neeche down-arrows count karo. $T_{1} = t_{h w} + 1 \cdot δ = 1 + 0.2 = 1.2 μ s (1 arrow)$ $T_{2} = t_{h w} + 2 \cdot δ = 1 + 0.4 = 1.4 μ s (2 arrows)$ Kyun percent-extra aur raw $0.2 μ s$ gap nahi? Raw gap apne aap mein meaningless hai — $0.2 μ s$ ek $1 μ s$ op ke next huge hai lekin ek $1 s$ op ke next negligible. The fraction $\frac{T _{2} - T _{1}}{T _{1}}$ normalise karta hai extra cost ko us kaam ke against jo tum anyway pay karne wale the, toh yeh physically meaningful sawaal ka jawab deta hai: "Type 1 ke time ki per unit, Type 2 kitna zyada charge karta hai?" — ek scale-free number jo tum workloads ke across compare kar sakte ho. $\frac{T _{2} - T _{1}}{T _{1}} = \frac{1.4 - 1.2}{1.2} = \frac{0.2}{1.2} \approx 0.1667 = 16.67%$ Type 2 is modelled op par ≈ 16.7% slower hai. Extra 0.2 μs literally figure mein us ek extra Host OS down-arrow ki price hai — poori story yehi hai.

Recall Solution L3.2

Yahan $n$ exactly guest ke neeche down-arrows count karta hai — wahi crossings jo humne page ke upar define ki thi. Ek arrow per crossing, toh $n$ crossings cost karte hain $n δ$ : $T (n) = t_{h w} + n δ$ Type 2 ( $n = 2$ ) ka extra fraction Type 1 ( $n = 1$ ) par:

=\frac{\delta}{t_{hw}+\delta}$$ Jab $\delta \to \infty$, $f \to 1$, yaani **100\%**. Physically: jab ek arrow cross karna actual hardware work se far zyada cost kare *Hardware* box mein, toh woh ek extra *Host OS* arrow *double* kar deta hai time ko — Type 2 twice as slow ho jaata hai. **Isliye I/O-heavy, crossing-dominated workloads Type 2 ko sabse zyada punish karte hain** (I/O poore stack par bahut saare trips force karta hai neeche aur wapas upar).

Recall Solution L3.3

Hypervisor (trap-and-emulate): $T_{h y p} = 999000 \cdot 1 ns + 1000 \cdot 500 ns = 999000 + 500000 = 1, 499, 000 ns$ Pure emulator: $T_{e m u} = 1000000 \cdot 500 ns = 500, 000, 000 ns$ Ratio $= \frac{500 , 000 , 000}{1 , 499 , 000} \approx 333.6 \times$ . Ek hypervisor yahan ≈ 334× faster hai pure emulator se, kyunki woh 99.9% safe instructions ko seedha metal par run karta hai aur sirf rare privileged ones ko trap karta hai. Yehi "trap-and-emulate" ka pura point hai.

Level 4 — Synthesis

Definition L4 ke liye do instruction

kinds (Popek & Goldberg, 1974), plus unka rule Do kinds of instruction jo tumhe naam se jaanne chahiye:

Privileged instruction — ek instruction jo traps (control ko upar supervisor ke paas hand karta hai) jab bhi woh kernel mode ke baahir run hoti hai. Figure terms mein, ek demoted guest box se ise run karna hypervisor mein ek up-arrow force karta hai. Example: page-table base register write karna.
Sensitive instruction — ek instruction jo machine state read ya change karti hai (interrupt flags, real vs virtual mode, etc.) — woh kind jise hypervisor zaroor intercept kare taaki illusion consistent rahe.

Woh rule jo dono kinds ko ek saath tie karta hai (yeh ek rule hai, instructions ki teesri kind nahi): trap-and-emulate cleanly tab kaam karta hai iff har sensitive instruction privileged bhi ho (toh woh hamesha trap up ho). Dangerous case woh sensitive instruction hai jo privileged nahi — woh state change karti hai lekin kabhi trap nahi karti, toh hypervisor kabhi usse dekhta hi nahi.

Recall Solution L4.1

(a) Kya break hota hai: guest kernel ko ek less-privileged ring mein demote kiya jaata hai (dekho CPU Privilege Rings). POPF sensitive hai (woh quietly interrupt flag read/write karta hai) lekin privileged nahi, toh woh trap nahi karta — koi up-arrow fire nahi hota; woh bas quietly wrong kaam karta hai. Yeh Popek & Goldberg rule "har sensitive instruction privileged honi chahiye" violate karta hai, toh hypervisor ko kabhi up-arrow intercept karne ko nahi milta, aur guest ka machine state ka view corrupt ho jaata hai. (b) Teen fixes:

Binary translation — hypervisor bad instruction sequences ko on the fly rewrite karta hai (early VMware). Kaun change karta hai: hypervisor ka execution engine.
Paravirtualization — guest OS ko modify kiya jaata hai taaki hypervisor ko explicitly "hypercalls" ke zariye call kare problematic instruction run karne ki jagah (Xen). Kaun change karta hai: guest.
Hardware-assisted (Intel VT-x / AMD-V) — CPU ek real guest mode add karta hai taaki nasty instructions bhi cleanly trap karein. Kaun change karta hai: silicon. Yeh modern default hai.

Recall Solution L4.2

(i) Cloud provider → Type 1 (e.g. VMware ESXi, Xen, ya KVM). Sabse strong reason: performance + smaller security surface — hot path par koi host-OS down-arrow nahi (left stack), aur ek thin hypervisor ek chhota trusted computing base hai defend karne ke liye hazaron tenants ke across. Dekho Cloud Computing. (ii) Solo developer → Type 2 (e.g. VirtualBox ya VMware Workstation). Sabse strong reason: convenience — developer ka laptop already ek primary desktop OS run kar raha hai jise woh wipe nahi kar sakte, aur Type 2 hypervisor uske upar ek ordinary app ki tarah install hota hai (figure mein right stack mein Host OS box bana rehta hai). VT-x/AMD-V ke under CPU-bound testing near-native speed par run hoti hai, toh single added down-arrow se thoda extra I/O overhead — dev/test ke liye irrelevant hai. Teen guest OSes ko seconds mein snapshot aur reset kar paana, apne familiar desktop se baahar gaye bina, yahan raw throughput se kahin zyada matter karta hai.

Recall Solution L4.3

Containers. Ek VM poora guest OS per instance ship karta hai (ek Guest OS box aur uska apna kernel) — 200 kernels ka RAM aur boot cost. Containers single host kernel share karte hain aur sirf user space ko isolate karte hain, toh 200 unke far lighter hain. Kyunki sabhi services same kernel accept karte hain, isolation trade-off acceptable hai. Dekho Containers vs Virtual Machines. (Agar services ko different kernels ya stronger isolation chahiye hoti, VMs jeette.)

Level 5 — Mastery

Recall Solution L5.1

Type 1 ka Type 2 par per-op saving hai $(t_{h w} + 2 δ) - (t_{h w} + δ) = δ$ (exactly ek extra arrow). $P$ ops par, Type 1 $P δ$ seconds runtime bachata hai, lekin Type 2 ne $S$ seconds setup bachaye the. Break-even woh jagah hai jahan runtime saving setup saving ke equal ho: $P_{b e} δ = S ⟹ P_{b e} = \frac{S}{δ}$ $P_{b e} = \frac{600}{2 \times 1 0 ^{- 7}} = 3 \times 1 0^{9} privileged ops$ Interpretation: 3 billion privileged ops se neeche, Type 2 ki ek-baar ki 600 s setup saving dominate karti hai → bas Type 2 use karo. Usse upar, Type 1 ki per-op speed setup cost wapas pay karti hai → bare-metal jao. Yeh "Type 2 for dev, Type 1 for production" ka quantitative heart hai.

Recall Solution L5.2

Lower bound $f (δ) \geq 0$ . Numerator hai $δ \geq 0$ assumption se. Denominator hai $t_{h w} + δ$ , jo $t_{h w} > 0$ aur $δ \geq 0$ ka sum hai, toh woh $> 0$ hai. Ek non-negative number ek positive number se divide karne par $\geq 0$ milta hai. Hence $f (δ) \geq 0$ . ∎

Upper bound $f (δ) < 1$ . Gap consider karo

= \frac{t_{hw}}{t_{hw}+\delta}.$$ Numerator $t_{hw}>0$ aur denominator $t_{hw}+\delta>0$ hai, toh $1-f(\delta) > 0$ hai, yaani $f(\delta) < 1$. ∎ Combine karke: $0 \le f(\delta) < 1$ sabhi $\delta\ge 0,\ t_{hw}>0$ ke liye. Kyunki $f<1$ ka matlab hai extra time $T_1$ ke $100\%$ se kam hai, **Type 2 is model mein kabhi Type 1 ke time ka twice se zyada nahi hota**. **Do limiting cases:** - $\delta \to 0$ (free crossings): $f \to 0$ — Type 1 aur Type 2 **tie** karte hain. Yeh CPU-bound kaam model karta hai VT-x/AMD-V ke under jahan ek guest instruction barely arrows cross karti hai aur near-native run hoti hai. - $\delta \to \infty$ (crossing hardware work ko dwarf kare): $f \to 1$ — Type 2 **twice** time approach karta hai (lekin kabhi reach nahi karta). Yeh pathological I/O model karta hai jahan har request extra *Host OS* down-arrow pay karta hai. Yeh dono har real case ko bracket karte hain.

Recall Solution L5.3

CPU mein privilege rings hote hain (CPU Privilege Rings); hypervisor sabse privileged mode mein baitha hai aur har guest kernel ko usse neeche demote karta hai. Jab ek demoted guest ek privileged instruction run karta hai, CPU trap up karta hai (System Calls and Traps) hypervisor mein, jo effect emulate karta hai — yeh "trap-and-emulate" woh shared engine hai jo dono Type 1 aur Type 2 ke peeche hai. Fark sirf layer count hai (figure mein down-arrows) hardware tak jaane ke raaste par: Type 1 ka guest hardware tak pohnchne ke liye ek down-arrow cross karta hai, jabki Type 2 ka guest do cross karta hai (hypervisor + host OS), toh Type 2 mein har privileged trap aur har I/O ek extra hop pay karta hai — jo exactly woh overhead hai jo humne upar quantify kiya.

Recall Ek-line self-test jaane se pehle

Kisi bhi setup ke baare mein poochho: "Metal ne kya boot kiya, aur ek guest CPU tak pohnchne ke liye kitne down-arrows cross karta hai?" Ek down-arrow aur koi host OS nahi → Type 1. Do down-arrows, neeche ek full host OS ke saath → Type 2.