Windows virtualization की गहराई (भाग 1) — आपका Windows वास्तव में कहाँ चल रहा है? Hypervisor और partitions

Windows 11 पर System Information (msinfo32) खोलें तो “Virtualization-based security” field में अक्सर “Running” दिखेगा — उस machine पर भी जहाँ आपने कभी VM नहीं बनाया।

उसका अर्थ यह तथ्य है। उस PC पर, host Windows खुद पहले से hypervisor के ऊपर चल रहा है। “Virtualization” अब केवल Hyper-V Manager में VM बनाने वालों की तकनीक नहीं रही। Windows 11 पर virtualization-based security (VBS) उन configurations पर default से enable होती है जो शर्तें पूरी करते हैं — उदाहरण के लिए compatible hardware पर clean install¹ — और WSL2 तथा Windows Sandbox दोनों उसी Windows hypervisor पर बने हैं। रोज़ use किए Windows के नीचे, पहले से software की एक और परत है।

यह श्रृंखला, “Windows virtualization की गहराई”, उस परत में क्या होता है उसे बुनियाद से अनुसरण करती है।

“Windows virtualization की गहराई” — सभी 3 भाग

1. भाग 1 (यह लेख): Hypervisor और partitions
   हम अनुसरण करते हैं कि Hyper-V enable करने पर host Windows कहाँ चलने लगता है।
2. भाग 2: वह memory जिसे kernel भी नहीं देख सकता — VBS, HVCI और Credential Guard
   हम अनुसरण करते हैं कि Windows उन secrets को कहाँ रखता है जिन्हें न Administrator पढ़ सकता है न kernel।
3. भाग 3: सेकंडों में boot होने वाली virtual machines — WSL2, Windows Sandbox और containers
   हम memory और image साझा करने के तरीके से अनुसरण करते हैं कि पूर्ण VM भारी होने पर भी WSL2 और Sandbox हल्के क्यों हैं।

भाग 1 जो प्रश्न हल करता है वह केवल एक है।

Hyper-V enable करने पर host Windows कहाँ चलने लगता है?

लक्षित पाठक वे developers और operators हैं जो Hyper-V, WSL2 या Windows Sandbox use करते हैं और नीचे क्या चल रहा है mechanism से समझना चाहते हैं। Prerequisites हैं x64 Windows 10/11 या वर्तमान Windows Server (इस लेख में rings, VT-x/AMD-V और EPT/RVI की चर्चा x64 मानती है; Arm64 exception levels जैसे अलग mechanism use करता है)। आवश्यक पृष्ठभूमि kernel mode और user mode का भेद लगभग है; VM operations experience या hypervisor-development ज्ञान नहीं चाहिए। कठिनाई मध्यम है। हम CPU virtualization extensions की अवधारणा cover करते हैं, पर instruction-set विवरण में नहीं जाते।

1. निष्कर्ष पहले

Hyper-V सुनकर लोग “Windows के ऊपर बैठा VM-चलाने वाला software” चित्रित कर सकते हैं। वास्तविक structure उलटी है।

जिस क्षण आप Hyper-V enable कर reboot करते हैं, physical CPU और memory नियंत्रित करने वाला hypervisor है, और host Windows उसके ऊपर पहले, privileged partition — “root partition” — के रूप में चलता है।

Hypervisor hardware और OS के बीच बैठी पतली software परत है, जो “partition” नामक isolated execution environment बनाती है और hardware पहुँच का mediation करती है।² जिसमें host Windows जाता है वह root partition है; जिनमें VM जाते हैं वे child partitions हैं। Root partition विशेष माना जाता है (उसकी physical devices तक सीधी पहुँच है और management stack रखता है), पर इस अर्थ में कि वह physical CPU सीधे नियंत्रित नहीं करता, वह child partition जैसी ही स्थिति में खड़ा है।

flowchart TB
    accTitle: Hyper-V enable होने के बाद समग्र structure
    accDescr: Hypervisor physical hardware पर सीधे बैठता है, और उसके ऊपर host Windows रखने वाला root partition तथा VM रखने वाले child partitions बैठते हैं
    hw["Physical hardware"] --> hv["Hypervisor"]
    hv --> root["Root partition（host Windows）"]
    hv --> child1["Child partition（VM）"]
    root -.-> stack["Management stack और device drivers"]

चित्र 1: Hyper-V “Windows के ऊपर VM software” नहीं बल्कि Windows के नीचे जाने वाली परत है, और host OS खुद root partition के अंदर चलता है।

आप सोच सकते हैं, “Enable करने के बाद कुछ अलग नहीं लगता, क्या सच में इतनी बड़ी उलटी हुई?” हाँ हुई। ठीक इसलिए यह structure आमतौर पर नज़र नहीं आती। इस लेख में हम इस एक आरेख को तीन अक्षों पर खोलते हैं: CPU, memory, और device I/O।

2. CPU से — rings के नीचे एक और privilege

2.1. Ring protection की पुनरावृत्ति

x64 CPU में privilege levels (rings) हैं, और Windows kernel mode ring 0 पर तथा user mode ring 3 पर चलाता है। Applications hardware सीधे नहीं छू सकते क्योंकि privileged instructions ring 3 से execute नहीं हो सकते।

तो एक ही physical CPU पर कई OS kernels, प्रत्येक ring 0 पर चलता, सुरक्षित कैसे रखें? हर kernel इस धारणा पर लिखा है कि “मैं CPU नियंत्रित करता हूँ”। सभी को ring 0 दें तो टकराते हैं; रोकें तो चलेंगे नहीं।

flowchart TB
    accTitle: कई OS kernels के ring 0 माँगने की problem
    accDescr: Host और guest दोनों kernels ring 0 पर पूर्ण अधिकार मानकर लिखे हैं, इसलिए traditional ring सीढ़ी अकेले उन्हें एक ही physical CPU पर सुरक्षित नहीं रख सकती
    k1["Host kernel（ring 0 मानता）"] --> want["Physical CPU का नियंत्रण माँगता"]
    k2["Guest kernel（ring 0 मानता）"] --> want
    want --> conflict["Traditional rings मेल नहीं करातीं"]
    conflict --> need["Ring 0 के ऊपर mediator चाहिए"]

चित्र 2: Ring सीढ़ी एक OS मानकर बनी, इसलिए कई kernels रखने के लिए उसके ऊपर एक और privilege चाहिए।

2.2. Virtualization extensions — hypervisor के लिए reserved mode

इस problem को हल करने वाली चीज़ CPU के virtualization extensions (Intel VT-x/AMD-V) हैं। Hyper-V इस विशेषता वाला processor चाहिए।² Virtualization extensions traditional rings से अलग अक्ष पर “hypervisor का execution mode” और “guest का execution mode” जोड़ते हैं। यह ring 0 से भी मज़बूत privilege है, कभी “ring -1” उपनाम से।

• Guest kernel पहले की तरह ring 0 पर चलता रहता है। Rewrite नहीं चाहिए।
• पर वह ring 0 “guest mode के अंदर ring 0” है, और physical CPU समग्र नियंत्रित नहीं करता।
• जब guest ऐसा विशेष operation छूता है जिसमें hypervisor हस्तक्षेप चाहिए (intercept के रूप में configure instructions, या exception या violation), CPU नियंत्रण स्वतः hypervisor को देता है (VM Exit)। Hypervisor सँभालने के बाद guest पर लौटता है (VM Entry)। Ordinary memory पहुँच बिना VM Exit गुज़रती हैं, जब तक SLAT translation सफल हो।

Interrupts उसी तरह काम करते हैं। Partitions physical processor सीधे नहीं छूते; hypervisor interrupt प्राप्त कर प्रत्येक partition को निर्देशित करता है।²

flowchart TB
    accTitle: Guest execution और VM Exit का flow
    accDescr: Guest kernel और app guest mode में ring 0 और ring 3 पर चलते हैं; ordinary memory पहुँच SLAT translation से गुज़रती है, जबकि configure intercepts और exceptions VM Exit से नियंत्रण hypervisor को देते हैं, जो फिर VM Entry से guest पर लौटता है
    guest["Guest mode में चलना（ring-0 kernel सहित）"] --> op{"हस्तक्षेप चाहिए?（intercept/exception）"}
    op -->|नहीं| cont["ज्यों का त्यों चलते रहें"]
    op -->|हाँ| exitEv["VM Exit（CPU नियंत्रण देता）"]
    exitEv --> hvp["Hypervisor सँभालता है"]
    hvp --> entry["VM Entry से guest पर लौटें"]
    entry --> guest

चित्र 3: Guest OS बिना rewrite ring 0 पर चलता रहता है, और CPU hypervisor को केवल ज़रूरत पर बुलाता है।

यह आना-जाना memory श्रृंखला में अनुसरण किए flow जैसा लगता है — “page fault पर kernel में प्रवेश, फिर उसी instruction पर लौटना”। CPU exception या transition mechanism से नियंत्रण रोकता है, ऊँचे स्तर के manager को निर्णय लेने देता है, फिर लौटाता है। Windows की गहराई में यह आकार बार-बार आता है।

2.3. Type 1 और Type 2 — अंतर यह है कि कहाँ बैठता है

Hypervisors मोटे तौर पर Type 1 (bare-metal) में बँटते हैं, जो hardware पर सीधे चलता है, और Type 2 (hosted) में, जो host OS के ऊपर चलता है। Hyper-V Type 1 है।³ VirtualBox और VMware Workstation (अकेले चलाने पर) Type 2 वर्गीकृत होते हैं।

Type 1 सुनकर लोग “बिना host OS वाले केवल-server configuration” कल्पना करते हैं, पर Hyper-V अलग है। Host Windows गायब नहीं होता — वह root partition में “घर बदलता” है। Hyper-V enable कर reboot करने पर, boot के दौरान hypervisor पहले start होता है, और host Windows फिर उसके ऊपर root partition के रूप में आता है।

flowchart TB
    accTitle: Type 1 और Type 2 hypervisor का अंतर
    accDescr: Type 2 में host OS hardware पर बैठता है और hypervisor व VM host OS पर बैठते हैं, जबकि Type 1 Hyper-V में hypervisor hardware पर सीधे बैठता है और host OS खुद उसके ऊपर root partition में जाता है
    subgraph t2 ["Type 2（hosted）"]
        hw2["Hardware"] --> hostos["Host OS"]
        hostos --> hv2["Hypervisor"]
        hv2 --> vm2["VM"]
    end
    subgraph t1 ["Type 1（Hyper-V）"]
        hw1["Hardware"] --> hv1["Hypervisor"]
        hv1 --> root1["Root partition（host OS）"]
        hv1 --> vm1["VM"]
    end
    vm2 ~~~ hw1

चित्र 4: Type 2 में hypervisor host OS पर बैठता है, जबकि Type 1 Hyper-V में क्रम उलटा है और host OS खुद एक परत नीचे की परत पर बैठता है।

Boot timeline पर देखने पर, enable करने पर जो परिवर्तन होता है वह ऐसा दिखता है।

flowchart TB
    accTitle: Hyper-V enable होने के बाद boot क्रम
    accDescr: Power-on के बाद boot के दौरान hypervisor पहले start होता है, host Windows फिर उसके ऊपर root partition के रूप में आता है, और VM, VBS आदि उसके बाद start होते हैं
    poweron["Power on और boot शुरू"] --> bhv["Hypervisor पहले start"]
    bhv --> broot["Host Windows root के रूप में"]
    broot --> blater["VM, VBS, WSL2 आदि ऊपर start"]
    broot -.-> feel["User experience अपरिवर्तित"]

चित्र 5: क्रम का उलटा logon screen आने से पहले पूरा हो चुका होता है, और host OS शुरू से hypervisor पर आता है।

3. Partition — isolation की इकाई

3.1. केवल root partition के पास भूमिकाएँ

Partition hypervisor द्वारा दी गई isolation की logical इकाई है।² पर हर partition समान नहीं। कुछ चीज़ें केवल root partition के पास हैं।

• Physical devices तक सीधी पहुँच। Disk, NIC, GPU आदि के device drivers root partition के अंदर Windows में रहते हैं, hypervisor में नहीं। Windows Server पर Hyper-V में ऐसा configuration है जो विशिष्ट PCIe devices सीधे child partition को सौंपता है (Discrete Device Assignment); उस स्थिति में root उस device को छोड़ देता है (यह client Windows पर उपलब्ध नहीं)।⁴
• Virtualization management stack। VMMS (Virtual Machine Management Service), जो VM बनाना, start करना और रोकना नियंत्रित करता है, और per-VM worker process (vmwp.exe) root partition में user mode में चलते हैं।⁵ ये Hyper-V की VM management विशेषताओं का भाग हैं, इसलिए केवल VBS या WSL2 के लिए hypervisor चलाने वाले host पर absent हो सकते हैं।
• Child partition बनाने का अधिकार। Root partition hypercall API (hypervisor में calling interface) से child partitions बनाता है।²

इस design का कारण है। यदि हर device driver hypervisor में ही डालें, तो hypervisor विशाल हो जाता है और bugs तथा attack-entry points बढ़ते हैं। Hypervisor खुद को CPU और memory की mediation के न्यूनतम काम तक सीमित रखता है, और devices की देखभाल root partition के Windows पर छोड़ता है। भूमिकाओं का यह विभाजन Hyper-V को पतला रखता है।

flowchart TB
    accTitle: Root और child partition के बीच भूमिका विभाजन
    accDescr: Root partition virtualization management stack और physical device drivers रखता है और hypercall से child बनाता है; child सामान्यतः केवल virtual devices देखता है, और Windows Server पर Discrete Device Assignment में सौंपे devices तक सीधी पहुँच करता है
    subgraph rootp ["Root partition"]
        vmms["VMMS और worker processes"]
        drv["Physical device drivers"]
    end
    subgraph childp ["Child partition"]
        gos["Guest OS"]
        vdev["सामान्यतः केवल virtual devices"]
    end
    vmms -->|Hypercall से बनाएँ और manage| childp
    hv2["Hypervisor（CPU और memory mediator）"] --- rootp
    hv2 --- childp

चित्र 6: Device drivers और management stack को root-partition पक्ष पर रखना ही hypervisor को पतला रखता है।

3.2. Child partition से दिखने वाली दुनिया

Child partition का guest OS सामान्य virtual-device configuration में physical hardware सीधे नहीं देख सकता (एकमात्र exception पिछली धारा में वर्णित Windows Server पर Discrete Device Assignment से सौंपा device है)। जो वह देख सकता है वे virtual processors, अपनी प्रतीत होने वाली memory space, और virtual devices हैं। Virtual devices के requests VMBus या hypervisor से root partition को forward होते हैं।² CPU-time allocation और SLAT से memory translation, दूसरी ओर, root से गुज़रे बिना hypervisor सीधे सँभालता है। Root जो mediation करता है वह device I/O है, हर physical resource नहीं।

flowchart TB
    accTitle: Child partition से दिखने वाली दुनिया
    accDescr: Guest OS जो देखता है वे virtual processors, partition की private memory space और virtual devices हैं; virtual devices के requests VMBus आदि से root को जाते हैं, CPU time और memory translation hypervisor सीधे सँभालता है, और Windows Server पर DDA में केवल सौंपे devices सीधे पहुँचे जाते हैं
    gos2["Guest OS（child）"] --> vcpu["Virtual processors"]
    gos2 --> rest{"Memory या device?"}
    rest --> gpa2["Private memory space"]
    rest --> vdev2["Virtual devices"]
    vdev2 --> rootx["Root को forward"]
    rootx -.-> vbus["VMBus आदि से"]
    gos2 -.-> phys2["Physical CPU, RAM, devices"]
    phys2 -.-> hid["सीधे नहीं दिखते"]
    phys2 -.-> dda2["DDA: सौंपे devices"]
    dda2 -.-> ddaN["Windows Server"]
    vcpu ~~~ phys2

चित्र 7: सामान्य virtual-device configuration में guest जो देखता है सब virtual खिड़की है और physical तक path mediator से जाता है; केवल Windows Server पर DDA से सौंपा device exception है।

यहाँ महत्वपूर्ण है कि host Windows पर चलते app के लिए यह structure लगभग transparent है। Win32 API calls और page-fault handling पहले की तरह root partition के अंदर Windows kernel process करता है। Hypervisor केवल तभी हस्तक्षेप करता है जब configure intercepts या exceptions छूटे।

4. Memory से — address translation एक और स्तर पाता है

4.1. तीन प्रकार के addresses

Memory श्रृंखला के भाग 1 में हमने वह flow अनुसरण किया जिससे virtual address page table से physical address में translate होता है (“Virtual address के physical RAM बनने का क्षण”)। Virtualized environment में उस translation के नीचे एक और स्तर जुड़ता है, और तीन प्रकार के addresses होते हैं।

Guest OS अपनी page table से GVA को GPA में translate करता है। पर guest जो GPA देखता है वास्तविक physical address नहीं; प्रत्येक partition की private memory space है।² GPA को RAM के वास्तविक स्थान (SPA) पर map करना hypervisor का काम है।

4.2. SLAT — hardware में two-level translation

यदि यह second-level translation केवल software में करें, तो hypervisor को हर guest page-table update एक-एक कर track करना पड़ता, जो performance की दृष्टि से realistic नहीं। इसलिए CPU hardware में second-level translation tables चलाने वाला mechanism देता है। वह SLAT (Second Level Address Translation) है; Intel EPT (Extended Page Tables) और AMD RVI implementations हैं। वर्तमान Hyper-V SLAT-capable 64-bit processor चाहिए।⁴

flowchart TB
    accTitle: SLAT से two-level address translation
    accDescr: Guest virtual address guest OS page table से guest physical address में translate होता है, फिर hypervisor द्वारा managed SLAT से system physical address में और वास्तविक RAM तक पहुँचता है
    gva["Guest virtual address（GVA）"] -->|Guest OS page table| gpa["Guest physical address（GPA）"]
    gpa -->|"SLAT（EPT/RVI tables）"| spa["System physical address（SPA）"]
    spa --> ram["Physical RAM"]
    gpa -.-> note["वह परत जिसे guest physical मानता है"]

चित्र 8: Guest की page table के नीचे hypervisor द्वारा managed एक और translation table बैठती है, और CPU दोनों hardware में चलता है।

SLAT केवल VM execution दक्षता के लिए मौजूद विशेषता नहीं। भाग 2 में दिखने वाला VBS “per privilege level अलग SLAT translation table हो सकती है” गुण को security boundary की सामग्री के रूप में use करता है। Kernel भी न देख सके ऐसी memory बनाने का कारण यह है कि hypervisor यह second-level translation रखता है। यह पूरी श्रृंखला की सूत्र-रेखा बनती है, इसलिए एक बिंदु याद रखें: “Translation tables का owner hypervisor है”।

5. Device I/O से — VMBus और दो प्रकार के devices

5.1. Emulated devices की सीमाएँ

Child partition को devices दिखाने का classic तरीका वास्तविक hardware (उदाहरण पुराना IDE controller) को software में पूरी तरह नकल करना है। Compatibility ऊँची है क्योंकि guest OS के in-box drivers ज्यों के त्यों काम करते हैं, पर हर बार guest I/O port छूते VM Exit होता है, और performance नहीं बढ़ता।

flowchart TB
    accTitle: Emulated device पर I/O धीमा क्यों है
    accDescr: हर बार guest I/O port operate करता है, नियंत्रण VM Exit से hypervisor पक्ष जाता है, device software में नकल होता है, और guest पर लौटाया जाता है, इसलिए चक्कर दोहरता है और धीमा है
    gio["Guest I/O port operate करता"] --> vex["VM Exit होता है"]
    vex --> emu2["Device software में emulate"]
    emu2 --> back["VM Entry से guest पर लौटें"]
    back -->|अगले port operation पर दोहरा| gio

चित्र 9: यह चक्कर एक disk पहुँच के पीछे कई बार चलता है, और compatibility की कीमत performance में चुकाई जाती है।

5.2. VMBus और VSP/VSC — virtualization के लिए design किया तेज़ path

इसलिए Hyper-V के पास virtualization मानकर design किया “synthetic device” mechanism है। तीन पात्र हैं।²

• VMBus: Partitions के बीच logical communication channel। Shared memory use करने वाला high-speed inter-partition communication देता है।³
• VSP (Virtualization Service Provider): Root-partition पक्ष पर रहने वाली service, जो child से device requests प्राप्त कर उन्हें root पक्ष के device/backend stack से जोड़ती है। Request physical device तक पहुँच सकता है, या virtual disk या virtual switch जैसे host-पक्ष backend सँभाल सकता है।
• VSC (Virtualization Service Consumer): Child-partition पक्ष guest OS में जाने वाला synthetic device driver। VMBus पर VSP को request भेजता है।

Guest OS storage request उदाहरण लेकर, flow ऐसा दिखता है। Guest app का WriteFile guest kernel के I/O stack से उतरता है और, तल पर, VSC तक पहुँचता है (वास्तविक hardware के बजाय)। VSC request VMBus पर रख root partition के VSP को सौंपता है, और VSP request root-पक्ष I/O stack में बहाता है। Virtual-disk (VHDX) configuration में, यह write host पर VHDX file पर write के रूप में सँभलता है और अंततः physical disk तक पहुँचता है। इस दृष्टिकोण को Enlightened I/O (virtualization से अवगत I/O) कहते हैं, और यह device-emulation परत को bypass कर दक्षता बढ़ाता है।²

flowchart TB
    accTitle: Synthetic device का I/O path
    accDescr: Child partition के app का I/O request guest kernel से VSC तक पहुँचता है, VMBus पार कर root partition के VSP तक जाता है, और VSP जिस root-पक्ष I/O stack से जोड़ता है उस पर physical device driver से वास्तविक device तक, या virtual disk व virtual switch जैसे host-पक्ष backend तक जा सकता है
    app["Child partition का app"] --> gk["Guest kernel I/O stack"]
    gk --> vsc["VSC（synthetic device driver）"]
    vsc -->|VMBus| vsp["VSP（root-partition पक्ष）"]
    vsp --> rio["Root-पक्ष I/O stack"]
    rio --> pdrv["Physical device driver"]
    rio --> hb["Host-पक्ष backend（VHDX, vSwitch）"]
    pdrv --> dev["Physical device"]

चित्र 10: Synthetic device से guest I/O VMBus पर root partition पार करता है और, root-पक्ष stack से, वास्तविक device या host-पक्ष backend तक पहुँचता है।

यानी, VM की disk I/O या networking तेज़ है या नहीं यह केवल guest पक्ष पर नहीं, root-partition पक्ष के I/O stack और device drivers की state पर भी depend करता है। VM performance problem जाँचते समय host-पक्ष observation अनिवार्य इसलिए है कि path वास्तव में host से गुज़रता है।

flowchart TB
    accTitle: Emulated device बनाम synthetic device
    accDescr: Emulated device वास्तविक hardware नकल करता है ताकि in-box guest drivers काम करें पर धीमा है; synthetic device VMBus मानकर बना purpose-built driver है और तेज़ है
    dev2{"Child को दिखाया device"} --> emu["Emulated device"]
    dev2 --> syn["Synthetic device"]
    emu -.-> emuP["वास्तविक hardware नकल; compatibility पहले"]
    emuP -.-> emuC["हर I/O पर हस्तक्षेप; धीमा"]
    syn -.-> synP["VMBus के इर्द-गिर्द design; तेज़"]
    synP -.-> synC["Guest में मेल खाता driver चाहिए"]

चित्र 11: दो प्रकार के virtual devices में, emulated devices OS install के तुरंत बाद compatibility उठाते हैं, और synthetic devices रोज़ के use में performance।

6. VM कभी use न करने पर भी यह किसी और की problem क्यों नहीं

अब तक की structure “VM खड़े करने वालों की कहानी” लग सकती है। पर जैसा प्रारंभ में कहा, वर्तमान Windows पर hypervisor रोज़ का भाग है।

• Virtualization-based security (VBS)। यह Windows hypervisor से isolated environment बनाकर security विशेषताएँ वहाँ रखती है। Windows 11 पर compatible hardware पर clean install जैसी शर्तें पूरी होने पर default से enable होती है।¹ विवरण भाग 2 में हैं।
• WSL2। यह हल्के utility VM के अंदर वास्तविक Linux kernel चलाता है।⁶
• Windows Sandbox। Hypervisor से isolated disposable Windows environment।⁷ दोनों भाग 3 में cover हैं।

flowchart TB
    accTitle: उसी hypervisor पर बैठने वाली रोज़ की विशेषताएँ
    accDescr: न केवल Hyper-V VM बल्कि VBS, जो clean install जैसी शर्तें पूरी करने वाले devices पर default से enable है, तथा WSL2 और Windows Sandbox, सभी उसी Windows hypervisor पर बने हैं
    base["Windows hypervisor"] --> f1["Hyper-V VM"]
    base --> f2["VBS（clean install आदि पर default）"]
    base --> f3["WSL2"]
    base --> f4["Windows Sandbox"]
    f2 -.-> daily["VM न use करने वाले PC पर भी क्यों चलता"]

चित्र 12: बुनियाद एक है, और यही आरेख वह जगह है जहाँ धारणा “virtualization VM use करने वालों की कहानी है” टूटती है।

व्यवहार में लोग अक्सर एक और बात पर कदम रखते हैं: third-party virtualization software से सह-अस्तित्व। क्योंकि hypervisor CPU के virtualization extensions का exclusive use करता है, Windows hypervisor चलते environment में VirtualBox आदि traditional तरीके से (CPU के virtualization extensions खुद use कर) नहीं चल सकते। इसके लिए Windows Hypervisor Platform नामक public API दी गई है, और third-party virtualization stack Windows hypervisor के ऊपर बैठकर चल सकता है।⁸ वर्तमान VirtualBox/VMware इस mechanism से WSL2 से सह-अस्तित्व कर सकते हैं, पर mode बदलने के साथ आने वाले performance और विशेषता अंतर कभी “Hyper-V (या VBS) enable करने के बाद virtualization software अलग व्यवहार करने लगा” के रूप में देखे जाते हैं।

flowchart TB
    accTitle: CPU virtualization extensions का owner, और third-party path
    accDescr: Windows hypervisor चलते समय CPU virtualization extensions का exclusive owner है; WHP समर्थित third-party virtualization software Windows Hypervisor Platform से उसके ऊपर चलता है, जबकि असमर्थित implementations नहीं चल सकतीं या limited हैं
    vt["CPU virtualization extensions（VT-x/AMD-V）"] --> hvon{"Windows hypervisor चल रहा?"}
    hvon -->|नहीं| direct["Third-party सीधे use कर सकता"]
    hvon -->|हाँ| own["Hypervisor का exclusive use"]
    own --> whp["Windows Hypervisor Platform"]
    whp --> third["WHP-capable third-party उसके ऊपर"]
    third -.-> nowhp["असमर्थित नहीं चलते, या limited"]

चित्र 13: Virtualization extensions का owner एक है, और hypervisor चलते सह-अस्तित्व कर सकने वाला एकमात्र third-party software वह है जो public API (WHP) समर्थित करता है।

7. स्वयं देखें

आप अपनी machine पर confirm कर सकते हैं कि hypervisor चल रहा है या नहीं।

पहले, बिना Administrator privilege चला सकने वाली जाँच।

# Whether we are running on top of a hypervisor
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent

# VBS status (same source as "Virtualization-based security" in msinfo32)
Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus

VirtualizationBasedSecurityStatus VBS चलने की अवस्था संख्या के रूप में लौटाता है (2 है “Running”)।⁹

एक सावधानी। HypervisorPresent केवल यह बताता है कि “क्या हम hypervisor के ऊपर चल रहे हैं”; root और child नहीं अलग करता। VM के अंदर Windows पर चलाएँ तो भी True लौटाता है, child partition के रूप में। Physical PC पर Windows पर True हो तो वह Windows root partition के अंदर है — इसे execution environment के साथ पढ़ें।

अगला, Command Prompt से classic।

systeminfo

Output के अंत में “Hyper-V Requirements” देखें। जिस machine पर hypervisor अभी नहीं चल रहा, वहाँ व्यक्तिगत requirements — SLAT support, virtualization extensions enable हैं या नहीं, आदि — listed होती हैं। जिस machine पर hypervisor पहले से चल रहा हो, requirements के बजाय एक पंक्ति मिलती है: “A hypervisor has been detected. Features required for Hyper-V will not be displayed.”⁴ इसलिए वह एक पंक्ति यह कथन है कि आपका Windows किसी hypervisor के ऊपर चल रहा है। HypervisorPresent की तरह, physical PC पर “root partition के अंदर”, या VM के अंदर “child partition के रूप में” पढ़ना पड़ता है।

यदि हर systeminfo requirement “Yes” हो, तो केवल hardware पक्ष तैयार है। Hyper-V विशेषता खुद Pro, Enterprise और Education editions पर उपलब्ध है, Home पर नहीं।¹⁰

GUI में, msinfo32 के “System Summary” के अंतर्गत “Virtualization-based security” पंक्ति देखें। ध्यान दें कि Task Manager के CPU pane में “Virtualization: Enabled” केवल firmware में virtualization extensions enable हैं या नहीं दिखाता है, जो hypervisor चल रहा है या नहीं से अलग जानकारी है।

flowchart TB
    accTitle: Hypervisor चल रहा है या नहीं कैसे जाँचें
    accDescr: यदि systeminfo कहे कि hypervisor पता चला तो आप hypervisor पर चल रहे हैं（physical PC पर root के अंदर）; यदि Hyper-V Requirements list आए तो अभी नहीं चल रहा इसलिए SLAT, VM Monitor Mode Extensions और DEP जैसी हर requirement जाँचें, पर सब Yes केवल hardware पक्ष तैयार है और Hyper-V विशेषता की edition requirement भी है
    start2["systeminfo चलाएँ"] --> q1{"Requirement field?"}
    q1 -->|Detected| running["Hypervisor चल रहा"]
    running -.-> runN["Root के अंदर"]
    runN -.-> runN2["Physical PC पर"]
    q1 -->|Listed| notyet["अभी नहीं चल रहा"]
    notyet --> q2{"सब requirements Yes?"}
    q2 -->|सब Yes| can["Hardware पक्ष तैयार"]
    can -.-> ed["Pro / Ent / Edu चाहिए"]
    q2 -->|कुछ No| uefi["UEFI/BIOS items जाँचें"]

चित्र 14: systeminfo का “Hyper-V Requirements” field चलने-अवस्था जाँच और prerequisite जाँच दोनों का काम करता है।

8. व्यवहार में बचने वाली तीन गलत पढ़तें

8.1. “हमने Hyper-V enable नहीं किया, इसलिए virtualization हमारे PC से संबंधित नहीं”

यदि आपने Hyper-V विशेषता (management tools और VM execution environment) enable न की हो, तब भी VBS enable हो तो Windows hypervisor चल रहा होता है। Driver compatibility problem, performance testing, या third-party virtualization software की परेशानी जाँचते समय, विशेषता enable है या नहीं नहीं — HypervisorPresent और VBS चलने की अवस्था जाँचें।

8.2. “Task Manager कहता है ‘Virtualization: Enabled’, इसलिए Hyper-V चल रहा है”

वह display firmware setting के बारे में है (VT-x/AMD-V उपलब्ध है या नहीं)। Hypervisor की चलने अवस्था systeminfo की “A hypervisor has been detected” से आँकें। इसके उल्टे, यदि Task Manager “Disabled” कहे, तो Hyper-V या WSL2 भी enable नहीं कर सकते, इसलिए पहले UEFI/BIOS setting जाँचें।

flowchart TB
    accTitle: आसानी से उलझने वाली तीन जाँचें
    accDescr: Task Manager का Virtualization field firmware setting दिखाता है, Windows Features list install अवस्था, और systeminfo या HypervisorPresent चलने अवस्था; प्रत्येक अलग प्रश्न का उत्तर देता है
    q3{"कौन सा प्रश्न?"}
    q3 --> fw{"Firmware या Windows?"}
    q3 --> c3["Hypervisor चल रहा?"]
    fw --> a3["Firmware extensions?"]
    fw --> b3["Hyper-V विशेषता ऑन?"]
    a3 -.-> a3t["Task Manager CPU pane"]
    b3 -.-> b3t["Windows Features UI"]
    c3 -.-> c3t["systeminfo"]
    c3 -.-> c3tp["HypervisorPresent"]

चित्र 15: ये तीन स्वतंत्र प्रश्न हैं, और किसी एक display से बाकी दो निकालना गलत पढ़त है।

8.3. “यदि VM धीमा है, तो guest-OS problem है”

Synthetic-device I/O VMBus पार कर root partition के VSP तक जाता है और root-पक्ष device/backend stack (physical drivers, तथा virtual-switch और virtual-disk processing) से गुज़रता है। यदि केवल guest के अंदर counters देखें, तो host-पक्ष storage या NIC में बैठा bottleneck नहीं मिलेगा। VM performance problems का सिद्धांत दोनों पक्षों से observation है: guest और host (root partition)।

9. सारांश

• Hyper-V enable करने पर hypervisor hardware पर सीधे चलता है और host Windows root partition के रूप में चलता है।²
• Guest OS kernel ring 0 पर चलता रहता है, और केवल intercept के रूप में configure operations, तथा exceptions, VM Exit से hypervisor को सौंपे जाते हैं। Ordinary memory पहुँच SLAT translation से गुज़रती हैं।
• केवल root partition physical device drivers और virtualization management stack रखता है, और hypercall से child partitions बनाता है।²
• Memory GVA→GPA→SPA का two-level translation बन जाती है, और second level SLAT (EPT/RVI) hardware में सँभालता है। वर्तमान Hyper-V को SLAT चाहिए।⁴
• Device I/O पर synthetic-device path VSC→VMBus→VSP हावी है, और performance host-पक्ष I/O stack पर भी depend करता है।²
• Windows 11 पर, क्योंकि VBS clean install जैसी शर्तें पूरी करने वाले devices पर default से enable है, VM कभी use न करने वाले PC पर भी hypervisor का चलना असामान्य नहीं।¹ चलने अवस्था HypervisorPresent और systeminfo से confirm कर सकते हैं।

भाग 1 का बड़ा चित्र इस एक आरेख में सिमटता है।

flowchart TB
    accTitle: भाग 1 का बड़ा चित्र
    accDescr: Hypervisor root और child partitions के नीचे बैठता है; CPU virtual processors schedule कर allocate होते हैं（VM Exit केवल configure intercepts और exceptions पर）, memory two-level SLAT translation से mediate होती है, synthetic-device I/O VMBus पर forward होकर root के VSP सँभालता है, और emulated devices व Discrete Device Assignment के अन्य paths हैं
    up["Root + child partitions"] --> hvS["Hypervisor"]
    hvS --> cpuS["CPU: VP schedule"]
    hvS --> memS["Memory: SLAT"]
    cpuS -.-> cpuN["Intercept पर VM Exit"]
    memS -.-> memN["Two-level translation"]
    memS ~~~ devS
    devS["Device: VMBus I/O"] --> vspS["Root-पक्ष VSP सँभालता"]
    devS -.-> devN["Emulated / DDA: अन्य"]

चित्र 16: CPU scheduling और memory translation hypervisor सीधे सँभालता है (VM Exit केवल हस्तक्षेप पर), और synthetic-device I/O VMBus के उस पार root partition (VSP) mediation करता है।

जारी भाग 2 में, “वह memory जिसे kernel भी नहीं देख सकता — VBS, HVCI और Credential Guard“।

हम इस लेख की सूत्र-रेखा उठाते हैं — कि hypervisor SLAT translation tables रखता है — और अनुसरण करते हैं कि Windows “वह memory जिसे न Administrator पढ़ सकता है न kernel” कैसे बनाता है।

संबंधित लेख

• Windows memory की गहराई (भाग 1) — Virtual address के physical RAM बनने का क्षण: page fault शुरू से अंत तक
• Windows का “memory use” वास्तव में क्या है? — Working Set, Private Bytes, Commit और Page File सही पढ़ना
• Windows Sandbox से app validation कैसे तेज़ करें
• Windows processor scheduling settings — background services और P/E cores

संबंधित परामर्श क्षेत्र

KomuraSoft LLC Windows applications के लिए validation-environment design, virtualized environment में performance जाँच, और driver व peripheral compatibility problems का analysis सँभालता है।

• Windows app development
• बग और कारणों की जाँच
• मौजूदा संपत्तियों का reuse और migration
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

Hyper-V enable करने पर host Windows वास्तव में कहाँ चलता है?

Hypervisor physical CPU और memory के allocation पर सीधा नियंत्रण लेता है, और host Windows root partition नामक विशेष partition के अंदर चलता है। Physical devices का नियंत्रण सामान्यतः root-partition पक्ष के drivers सँभालते हैं। Root partition device drivers और virtualization management stack रखता है, पर physical CPU का ownership hypervisor का है।

क्या Task Manager का "Virtualization: Enabled" मतलब है कि Hyper-V चल रहा है?

नहीं। वह display दिखाता है कि CPU के virtualization extensions (Intel VT-x/AMD-V) firmware में enable हैं या नहीं। यह देखने के लिए कि hypervisor वास्तव में चल रहा है, systeminfo में "A hypervisor has been detected" देखें, या Win32_ComputerSystem.HypervisorPresent जाँचें।

मैंने कभी VM नहीं बनाया, फिर भी hypervisor क्यों चल रहा है?

Windows 11 पर virtualization-based security (VBS) उन devices पर default से enable होती है जो शर्तें पूरी करते हैं — उदाहरण के लिए compatible hardware पर clean install — और VBS Windows hypervisor पर बना है। वही बात यदि आप WSL2 या Windows Sandbox use करते हैं। VM use से बिना संबंध hypervisor का चलना असामान्य नहीं।

SLAT क्या है, और Hyper-V के लिए यह क्यों आवश्यक है?

SLAT (Second Level Address Translation) वह mechanism है जिससे CPU guest physical addresses को वास्तविक physical addresses में translate करता है; Intel EPT और AMD RVI implementations हैं। उसके बिना hypervisor को translation tables software में रखनी पड़तीं, जो performance की दृष्टि से realistic नहीं, इसलिए वर्तमान Hyper-V इसे hard requirement मानता है।

यदि मैं Hyper-V enable करूँ, तो क्या VirtualBox और VMware काम करना बंद कर देंगे?

क्योंकि hypervisor CPU के virtualization extensions का exclusive use करता है, third-party hypervisor traditional तरीके से नहीं चल सकता। पर वर्तमान VirtualBox और VMware में Windows hypervisor के ऊपर चलने वाला mode है (Windows Hypervisor Platform के माध्यम से), इसलिए प्रत्येक के हाल के versions सह-अस्तित्व कर सकते हैं।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।