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

हाइपरवाइज़र भौतिक CPU और मेमोरी के आवंटन पर सीधा नियंत्रण लेता है, और होस्ट Windows रूट पार्टीशन नामक विशेष पार्टीशन के अंदर चलता है। भौतिक डिवाइस का नियंत्रण सामान्यतः रूट-पार्टीशन पक्ष के ड्राइवर सँभालते हैं। रूट पार्टीशन डिवाइस ड्राइवर और वर्चुअलाइज़ेशन प्रबंधन स्टैक रखता है, पर भौतिक CPU का स्वामित्व हाइपरवाइज़र का है।

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

नहीं। वह प्रदर्शन दिखाता है कि CPU के वर्चुअलाइज़ेशन एक्सटेंशन (Intel VT-x/AMD-V) फ़र्मवेयर में सक्षम हैं या नहीं। यह देखने के लिए कि हाइपरवाइज़र वास्तव में चल रहा है, systeminfo में "A hypervisor has been detected" देखें, या Win32_ComputerSystem.HypervisorPresent जाँचें।

मैंने कभी VM नहीं बनाया, फिर भी हाइपरवाइज़र क्यों चल रहा है?

Windows 11 पर वर्चुअलाइज़ेशन-आधारित सुरक्षा (VBS) उन डिवाइस पर डिफ़ॉल्ट से सक्षम होती है जो शर्तें पूरी करते हैं — उदाहरण के लिए संगत हार्डवेयर पर क्लीन इंस्टॉल — और VBS Windows हाइपरवाइज़र पर बना है। वही बात यदि आप WSL2 या Windows Sandbox उपयोग करते हैं। VM उपयोग से बिना संबंध हाइपरवाइज़र का चलना असामान्य नहीं।

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

SLAT (Second Level Address Translation) वह तंत्र है जिससे CPU गेस्ट भौतिक पतों को वास्तविक भौतिक पतों में अनुवादित करता है; Intel EPT और AMD RVI इम्प्लीमेंटेशन हैं। उसके बिना हाइपरवाइज़र को अनुवाद तालिकाएँ सॉफ़्टवेयर में रखनी पड़तीं, जो प्रदर्शन की दृष्टि से यथार्थवादी नहीं, इसलिए वर्तमान Hyper-V इसे कठोर आवश्यकता मानता है।

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

क्योंकि हाइपरवाइज़र CPU के वर्चुअलाइज़ेशन एक्सटेंशन का अनन्य उपयोग करता है, तृतीय-पक्ष हाइपरवाइज़र पारंपरिक तरीके से नहीं चल सकता। पर वर्तमान VirtualBox और VMware में Windows हाइपरवाइज़र के ऊपर चलने वाला मोड है (Windows Hypervisor Platform के माध्यम से), इसलिए प्रत्येक के हाल के संस्करण सह-अस्तित्व कर सकते हैं।

Windows वर्चुअलाइज़ेशन की गहराई (भाग 1) — आपका Windows वास्तव में कहाँ चल रहा है? हाइपरवाइज़र और पार्टीशन

22 Aug 2026 02:00 · Go Komura · Windows, वर्चुअलाइज़ेशन, Hyper-V, Hypervisor, SLAT, VMBus

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

उसका अर्थ यह तथ्य है। उस PC पर, होस्ट Windows स्वयं पहले से हाइपरवाइज़र के ऊपर चल रहा है। “वर्चुअलाइज़ेशन” अब केवल Hyper-V Manager में VM बनाने वालों की तकनीक नहीं रही। Windows 11 पर वर्चुअलाइज़ेशन-आधारित सुरक्षा (VBS) उन कॉन्फ़िगरेशन पर डिफ़ॉल्ट से सक्षम होती है जो शर्तें पूरी करते हैं — उदाहरण के लिए संगत हार्डवेयर पर क्लीन इंस्टॉल¹ — और WSL2 तथा Windows Sandbox दोनों उसी Windows हाइपरवाइज़र पर बने हैं। रोज़ उपयोग किए Windows के नीचे, पहले से सॉफ़्टवेयर की एक और परत है।

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

“Windows वर्चुअलाइज़ेशन की गहराई” — सभी 3 भाग

भाग 1 (यह लेख): हाइपरवाइज़र और पार्टीशन
हम अनुसरण करते हैं कि Hyper-V सक्षम करने पर होस्ट Windows कहाँ चलने लगता है।
भाग 2: वह मेमोरी जिसे कर्नेल भी नहीं देख सकता — VBS, HVCI और Credential Guard
हम अनुसरण करते हैं कि Windows उन रहस्यों को कहाँ रखता है जिन्हें न एडमिनिस्ट्रेटर पढ़ सकता है न कर्नेल।
भाग 3: सेकंडों में बूट होने वाली वर्चुअल मशीनें — WSL2, Windows Sandbox और कंटेनर
हम मेमोरी और इमेज साझा करने के तरीके से अनुसरण करते हैं कि पूर्ण VM भारी होने पर भी WSL2 और Sandbox हल्के क्यों हैं।

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

Hyper-V सक्षम करने पर होस्ट Windows कहाँ चलने लगता है?

लक्षित पाठक वे डेवलपर और ऑपरेटर हैं जो Hyper-V, WSL2 या Windows Sandbox उपयोग करते हैं और नीचे क्या चल रहा है तंत्र से समझना चाहते हैं। पूर्वापेक्षाएँ हैं x64 Windows 10/11 या वर्तमान Windows Server (इस लेख में रिंग, VT-x/AMD-V और EPT/RVI की चर्चा x64 मानती है; Arm64 exception levels जैसे अलग तंत्र उपयोग करता है)। आवश्यक पृष्ठभूमि कर्नेल मोड और यूज़र मोड का भेद लगभग है; VM संचालन अनुभव या हाइपरवाइज़र-विकास ज्ञान नहीं चाहिए। कठिनाई मध्यम है। हम CPU वर्चुअलाइज़ेशन एक्सटेंशन की अवधारणा कवर करते हैं, पर निर्देश-सेट विवरण में नहीं जाते।

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

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

जिस क्षण आप Hyper-V सक्षम कर रीबूट करते हैं, भौतिक CPU और मेमोरी नियंत्रित करने वाला हाइपरवाइज़र है, और होस्ट Windows उसके ऊपर पहले, विशेषाधिकार प्राप्त पार्टीशन — “रूट पार्टीशन” — के रूप में चलता है।

हाइपरवाइज़र हार्डवेयर और OS के बीच बैठी पतली सॉफ़्टवेयर परत है, जो “पार्टीशन” नामक पृथक निष्पादन वातावरण बनाती है और हार्डवेयर पहुँच का मध्यस्थता करती है।² जिसमें होस्ट Windows जाता है वह रूट पार्टीशन है; जिनमें VM जाते हैं वे चाइल्ड पार्टीशन हैं। रूट पार्टीशन विशेष माना जाता है (उसकी भौतिक डिवाइस तक सीधी पहुँच है और प्रबंधन स्टैक रखता है), पर इस अर्थ में कि वह भौतिक CPU सीधे नियंत्रित नहीं करता, वह चाइल्ड पार्टीशन जैसी ही स्थिति में खड़ा है।

flowchart TB
    accTitle: Hyper-V सक्षम होने के बाद समग्र संरचना
    accDescr: हाइपरवाइज़र भौतिक हार्डवेयर पर सीधे बैठता है, और उसके ऊपर होस्ट Windows रखने वाला रूट पार्टीशन तथा VM रखने वाले चाइल्ड पार्टीशन बैठते हैं
    hw["भौतिक हार्डवेयर"] --> hv["हाइपरवाइज़र"]
    hv --> root["रूट पार्टीशन（होस्ट Windows）"]
    hv --> child1["चाइल्ड पार्टीशन（VM）"]
    root -.-> stack["प्रबंधन स्टैक और डिवाइस ड्राइवर"]

चित्र 1: Hyper-V “Windows के ऊपर VM सॉफ़्टवेयर” नहीं बल्कि Windows के नीचे जाने वाली परत है, और होस्ट OS स्वयं रूट पार्टीशन के अंदर चलता है।

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

2. CPU से — रिंगों के नीचे एक और विशेषाधिकार

2.1. रिंग सुरक्षा की पुनरावृत्ति

x64 CPU में विशेषाधिकार स्तर (रिंग) हैं, और Windows कर्नेल मोड रिंग 0 पर तथा यूज़र मोड रिंग 3 पर चलाता है। ऐप्लिकेशन हार्डवेयर सीधे नहीं छू सकते क्योंकि विशेषाधिकार निर्देश रिंग 3 से निष्पादित नहीं हो सकते।

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

flowchart TB
    accTitle: कई OS कर्नेल के रिंग 0 माँगने की समस्या
    accDescr: होस्ट और गेस्ट दोनों कर्नेल रिंग 0 पर पूर्ण अधिकार मानकर लिखे हैं, इसलिए पारंपरिक रिंग सीढ़ी अकेले उन्हें एक ही भौतिक CPU पर सुरक्षित नहीं रख सकती
    k1["होस्ट कर्नेल（रिंग 0 मानता）"] --> want["भौतिक CPU का नियंत्रण माँगता"]
    k2["गेस्ट कर्नेल（रिंग 0 मानता）"] --> want
    want --> conflict["पारंपरिक रिंग मेल नहीं करातीं"]
    conflict --> need["रिंग 0 के ऊपर मध्यस्थ चाहिए"]

चित्र 2: रिंग सीढ़ी एक OS मानकर बनी, इसलिए कई कर्नेल रखने के लिए उसके ऊपर एक और विशेषाधिकार चाहिए।

2.2. वर्चुअलाइज़ेशन एक्सटेंशन — हाइपरवाइज़र के लिए आरक्षित मोड

इस समस्या को हल करने वाली चीज़ CPU के वर्चुअलाइज़ेशन एक्सटेंशन (Intel VT-x/AMD-V) हैं। Hyper-V इस विशेषता वाला प्रोसेसर चाहिए।² वर्चुअलाइज़ेशन एक्सटेंशन पारंपरिक रिंगों से अलग अक्ष पर “हाइपरवाइज़र का निष्पादन मोड” और “गेस्ट का निष्पादन मोड” जोड़ते हैं। यह रिंग 0 से भी मज़बूत विशेषाधिकार है, कभी “रिंग -1” उपनाम से।

गेस्ट कर्नेल पहले की तरह रिंग 0 पर चलता रहता है। पुनर्लेखन नहीं चाहिए।
पर वह रिंग 0 “गेस्ट मोड के अंदर रिंग 0” है, और भौतिक CPU समग्र नियंत्रित नहीं करता।
जब गेस्ट ऐसा विशेष ऑपरेशन छूता है जिसमें हाइपरवाइज़र हस्तक्षेप चाहिए (इंटरसेप्ट के रूप में कॉन्फ़िगर निर्देश, या अपवाद या उल्लंघन), CPU नियंत्रण स्वतः हाइपरवाइज़र को देता है (VM Exit)। हाइपरवाइज़र सँभालने के बाद गेस्ट पर लौटता है (VM Entry)। साधारण मेमोरी पहुँच बिना VM Exit गुज़रती हैं, जब तक SLAT अनुवाद सफल हो।

इंटरप्ट उसी तरह काम करते हैं। पार्टीशन भौतिक प्रोसेसर सीधे नहीं छूते; हाइपरवाइज़र इंटरप्ट प्राप्त कर प्रत्येक पार्टीशन को निर्देशित करता है।²

flowchart TB
    accTitle: गेस्ट निष्पादन और VM Exit का प्रवाह
    accDescr: गेस्ट कर्नेल और ऐप गेस्ट मोड में रिंग 0 और रिंग 3 पर चलते हैं; साधारण मेमोरी पहुँच SLAT अनुवाद से गुज़रती है, जबकि कॉन्फ़िगर इंटरसेप्ट और अपवाद VM Exit से नियंत्रण हाइपरवाइज़र को देते हैं, जो फिर VM Entry से गेस्ट पर लौटता है
    guest["गेस्ट मोड में चलना（रिंग-0 कर्नेल सहित）"] --> op{"हस्तक्षेप चाहिए?（इंटरसेप्ट/अपवाद）"}
    op -->|नहीं| cont["ज्यों का त्यों चलते रहें"]
    op -->|हाँ| exitEv["VM Exit（CPU नियंत्रण देता）"]
    exitEv --> hvp["हाइपरवाइज़र सँभालता है"]
    hvp --> entry["VM Entry से गेस्ट पर लौटें"]
    entry --> guest

चित्र 3: गेस्ट OS बिना पुनर्लेखन रिंग 0 पर चलता रहता है, और CPU हाइपरवाइज़र को केवल ज़रूरत पर बुलाता है।

यह आना-जाना मेमोरी श्रृंखला में अनुसरण किए प्रवाह जैसा लगता है — “पेज फ़ॉल्ट पर कर्नेल में प्रवेश, फिर उसी निर्देश पर लौटना”। CPU अपवाद या संक्रमण तंत्र से नियंत्रण रोकता है, ऊँचे स्तर के प्रबंधक को निर्णय लेने देता है, फिर लौटाता है। Windows की गहराई में यह आकार बार-बार आता है।

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

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

Type 1 सुनकर लोग “बिना होस्ट OS वाले केवल-सर्वर कॉन्फ़िगरेशन” कल्पना करते हैं, पर Hyper-V अलग है। होस्ट Windows गायब नहीं होता — वह रूट पार्टीशन में “घर बदलता” है। Hyper-V सक्षम कर रीबूट करने पर, बूट के दौरान हाइपरवाइज़र पहले शुरू होता है, और होस्ट Windows फिर उसके ऊपर रूट पार्टीशन के रूप में आता है।

flowchart TB
    accTitle: Type 1 और Type 2 हाइपरवाइज़र का अंतर
    accDescr: Type 2 में होस्ट OS हार्डवेयर पर बैठता है और हाइपरवाइज़र व VM होस्ट OS पर बैठते हैं, जबकि Type 1 Hyper-V में हाइपरवाइज़र हार्डवेयर पर सीधे बैठता है और होस्ट OS स्वयं उसके ऊपर रूट पार्टीशन में जाता है
    subgraph t2 ["Type 2（hosted）"]
        hw2["हार्डवेयर"] --> hostos["होस्ट OS"]
        hostos --> hv2["हाइपरवाइज़र"]
        hv2 --> vm2["VM"]
    end
    subgraph t1 ["Type 1（Hyper-V）"]
        hw1["हार्डवेयर"] --> hv1["हाइपरवाइज़र"]
        hv1 --> root1["रूट पार्टीशन（होस्ट OS）"]
        hv1 --> vm1["VM"]
    end
    vm2 ~~~ hw1

चित्र 4: Type 2 में हाइपरवाइज़र होस्ट OS पर बैठता है, जबकि Type 1 Hyper-V में क्रम उलटा है और होस्ट OS स्वयं एक परत नीचे की परत पर बैठता है।

बूट समयरेखा पर देखने पर, सक्षम करने पर जो परिवर्तन होता है वह ऐसा दिखता है।

flowchart TB
    accTitle: Hyper-V सक्षम होने के बाद बूट क्रम
    accDescr: पावर-ऑन के बाद बूट के दौरान हाइपरवाइज़र पहले शुरू होता है, होस्ट Windows फिर उसके ऊपर रूट पार्टीशन के रूप में आता है, और VM, VBS आदि उसके बाद शुरू होते हैं
    poweron["पावर ऑन और बूट शुरू"] --> bhv["हाइपरवाइज़र पहले शुरू"]
    bhv --> broot["होस्ट Windows रूट के रूप में"]
    broot --> blater["VM, VBS, WSL2 आदि ऊपर शुरू"]
    broot -.-> feel["उपयोगकर्ता अनुभव अपरिवर्तित"]

चित्र 5: क्रम का उलटा लॉगऑन स्क्रीन आने से पहले पूरा हो चुका होता है, और होस्ट OS शुरू से हाइपरवाइज़र पर आता है।

3. पार्टीशन — अलगाव की इकाई

3.1. केवल रूट पार्टीशन के पास भूमिकाएँ

पार्टीशन हाइपरवाइज़र द्वारा दी गई अलगाव की तार्किक इकाई है।² पर हर पार्टीशन समान नहीं। कुछ चीज़ें केवल रूट पार्टीशन के पास हैं।

भौतिक डिवाइस तक सीधी पहुँच। डिस्क, NIC, GPU आदि के डिवाइस ड्राइवर रूट पार्टीशन के अंदर Windows में रहते हैं, हाइपरवाइज़र में नहीं। Windows Server पर Hyper-V में ऐसा कॉन्फ़िगरेशन है जो विशिष्ट PCIe डिवाइस सीधे चाइल्ड पार्टीशन को सौंपता है (Discrete Device Assignment); उस स्थिति में रूट उस डिवाइस को छोड़ देता है (यह क्लाइंट Windows पर उपलब्ध नहीं)।⁴
वर्चुअलाइज़ेशन प्रबंधन स्टैक। VMMS (Virtual Machine Management Service), जो VM बनाना, शुरू करना और रोकना नियंत्रित करता है, और प्रति-VM वर्कर प्रोसेस (vmwp.exe) रूट पार्टीशन में यूज़र मोड में चलते हैं।⁵ ये Hyper-V की VM प्रबंधन विशेषताओं का भाग हैं, इसलिए केवल VBS या WSL2 के लिए हाइपरवाइज़र चलाने वाले होस्ट पर अनुपस्थित हो सकते हैं।
चाइल्ड पार्टीशन बनाने का अधिकार। रूट पार्टीशन हाइपरकॉल API (हाइपरवाइज़र में कॉलिंग इंटरफ़ेस) से चाइल्ड पार्टीशन बनाता है।²

इस डिज़ाइन का कारण है। यदि हर डिवाइस ड्राइवर हाइपरवाइज़र में ही डालें, तो हाइपरवाइज़र विशाल हो जाता है और बग तथा हमला-प्रवेश बिंदु बढ़ते हैं। हाइपरवाइज़र स्वयं को CPU और मेमोरी की मध्यस्थता के न्यूनतम काम तक सीमित रखता है, और डिवाइस की देखभाल रूट पार्टीशन के Windows पर छोड़ता है। भूमिकाओं का यह विभाजन Hyper-V को पतला रखता है।

flowchart TB
    accTitle: रूट और चाइल्ड पार्टीशन के बीच भूमिका विभाजन
    accDescr: रूट पार्टीशन वर्चुअलाइज़ेशन प्रबंधन स्टैक और भौतिक डिवाइस ड्राइवर रखता है और हाइपरकॉल से चाइल्ड बनाता है; चाइल्ड सामान्यतः केवल वर्चुअल डिवाइस देखता है, और Windows Server पर Discrete Device Assignment में सौंपे डिवाइस तक सीधी पहुँच करता है
    subgraph rootp ["रूट पार्टीशन"]
        vmms["VMMS और वर्कर प्रोसेस"]
        drv["भौतिक डिवाइस ड्राइवर"]
    end
    subgraph childp ["चाइल्ड पार्टीशन"]
        gos["गेस्ट OS"]
        vdev["सामान्यतः केवल वर्चुअल डिवाइस"]
    end
    vmms -->|हाइपरकॉल से बनाएँ और प्रबंधित| childp
    hv2["हाइपरवाइज़र（CPU और मेमोरी मध्यस्थ）"] --- rootp
    hv2 --- childp

चित्र 6: डिवाइस ड्राइवर और प्रबंधन स्टैक को रूट-पार्टीशन पक्ष पर रखना ही हाइपरवाइज़र को पतला रखता है।

3.2. चाइल्ड पार्टीशन से दिखने वाली दुनिया

चाइल्ड पार्टीशन का गेस्ट OS सामान्य वर्चुअल-डिवाइस कॉन्फ़िगरेशन में भौतिक हार्डवेयर सीधे नहीं देख सकता (एकमात्र अपवाद पिछली धारा में वर्णित Windows Server पर Discrete Device Assignment से सौंपा डिवाइस है)। जो वह देख सकता है वे वर्चुअल प्रोसेसर, अपनी प्रतीत होने वाली मेमोरी स्पेस, और वर्चुअल डिवाइस हैं। वर्चुअल डिवाइस के अनुरोध VMBus या हाइपरवाइज़र से रूट पार्टीशन को अग्रेषित होते हैं।² CPU-समय आवंटन और SLAT से मेमोरी अनुवाद, दूसरी ओर, रूट से गुज़रे बिना हाइपरवाइज़र सीधे सँभालता है। रूट जो मध्यस्थता करता है वह डिवाइस I/O है, हर भौतिक संसाधन नहीं।

flowchart TB
    accTitle: चाइल्ड पार्टीशन से दिखने वाली दुनिया
    accDescr: गेस्ट OS जो देखता है वे वर्चुअल प्रोसेसर, पार्टीशन की निजी मेमोरी स्पेस और वर्चुअल डिवाइस हैं; वर्चुअल डिवाइस के अनुरोध VMBus आदि से रूट को जाते हैं, CPU समय और मेमोरी अनुवाद हाइपरवाइज़र सीधे सँभालता है, और Windows Server पर DDA में केवल सौंपे डिवाइस सीधे पहुँचे जाते हैं
    gos2["गेस्ट OS（चाइल्ड）"] --> vcpu["वर्चुअल प्रोसेसर"]
    gos2 --> rest{"मेमोरी या डिवाइस?"}
    rest --> gpa2["निजी मेमोरी स्पेस"]
    rest --> vdev2["वर्चुअल डिवाइस"]
    vdev2 --> rootx["रूट को अग्रेषित"]
    rootx -.-> vbus["VMBus आदि से"]
    gos2 -.-> phys2["भौतिक CPU, RAM, डिवाइस"]
    phys2 -.-> hid["सीधे नहीं दिखते"]
    phys2 -.-> dda2["DDA: सौंपे डिवाइस"]
    dda2 -.-> ddaN["Windows Server"]
    vcpu ~~~ phys2

चित्र 7: सामान्य वर्चुअल-डिवाइस कॉन्फ़िगरेशन में गेस्ट जो देखता है सब वर्चुअल खिड़की है और भौतिक तक पथ मध्यस्थ से जाता है; केवल Windows Server पर DDA से सौंपा डिवाइस अपवाद है।

यहाँ महत्त्वपूर्ण है कि होस्ट Windows पर चलते ऐप के लिए यह संरचना लगभग पारदर्शी है। Win32 API कॉल और पेज-फ़ॉल्ट हैंडलिंग पहले की तरह रूट पार्टीशन के अंदर Windows कर्नेल संसाधित करता है। हाइपरवाइज़र केवल तभी हस्तक्षेप करता है जब कॉन्फ़िगर इंटरसेप्ट या अपवाद छूटे।

4. मेमोरी से — पता अनुवाद एक और स्तर पाता है

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

मेमोरी श्रृंखला के भाग 1 में हमने वह प्रवाह अनुसरण किया जिससे वर्चुअल पता पेज तालिका से भौतिक पते में अनुवादित होता है (“वर्चुअल पता के भौतिक RAM बनने का क्षण”)। वर्चुअलाइज़्ड वातावरण में उस अनुवाद के नीचे एक और स्तर जुड़ता है, और तीन प्रकार के पते होते हैं।

पता	संक्षेप	कौन प्रबंधित करता है
Guest virtual address	GVA	गेस्ट OS पेज तालिका
Guest physical address	GPA	वह पता जिसे गेस्ट OS “भौतिक” मानता है
System physical address	SPA	हाइपरवाइज़र (RAM में वास्तविक स्थान)

गेस्ट OS अपनी पेज तालिका से GVA को GPA में अनुवादित करता है। पर गेस्ट जो GPA देखता है वास्तविक भौतिक पता नहीं; प्रत्येक पार्टीशन की निजी मेमोरी स्पेस है।² GPA को RAM के वास्तविक स्थान (SPA) पर मैप करना हाइपरवाइज़र का काम है।

4.2. SLAT — हार्डवेयर में दो-स्तर अनुवाद

यदि यह द्वितीय-स्तर अनुवाद केवल सॉफ़्टवेयर में करें, तो हाइपरवाइज़र को हर गेस्ट पेज-तालिका अद्यतन एक-एक कर ट्रैक करना पड़ता, जो प्रदर्शन की दृष्टि से यथार्थवादी नहीं। इसलिए CPU हार्डवेयर में द्वितीय-स्तर अनुवाद तालिकाएँ चलाने वाला तंत्र देता है। वह SLAT (Second Level Address Translation) है; Intel EPT (Extended Page Tables) और AMD RVI इम्प्लीमेंटेशन हैं। वर्तमान Hyper-V SLAT-सक्षम 64-बिट प्रोसेसर चाहिए।⁴

flowchart TB
    accTitle: SLAT से दो-स्तर पता अनुवाद
    accDescr: गेस्ट वर्चुअल पता गेस्ट OS पेज तालिका से गेस्ट भौतिक पते में अनुवादित होता है, फिर हाइपरवाइज़र द्वारा प्रबंधित SLAT से सिस्टम भौतिक पते में और वास्तविक RAM तक पहुँचता है
    gva["गेस्ट वर्चुअल पता（GVA）"] -->|गेस्ट OS पेज तालिका| gpa["गेस्ट भौतिक पता（GPA）"]
    gpa -->|"SLAT（EPT/RVI तालिकाएँ）"| spa["सिस्टम भौतिक पता（SPA）"]
    spa --> ram["भौतिक RAM"]
    gpa -.-> note["वह परत जिसे गेस्ट भौतिक मानता है"]

चित्र 8: गेस्ट की पेज तालिका के नीचे हाइपरवाइज़र द्वारा प्रबंधित एक और अनुवाद तालिका बैठती है, और CPU दोनों हार्डवेयर में चलता है।

SLAT केवल VM निष्पादन दक्षता के लिए मौजूद विशेषता नहीं। भाग 2 में दिखने वाला VBS “प्रति विशेषाधिकार स्तर अलग SLAT अनुवाद तालिका हो सकती है” गुण को सुरक्षा सीमा की सामग्री के रूप में उपयोग करता है। कर्नेल भी न देख सके ऐसी मेमोरी बनाने का कारण यह है कि हाइपरवाइज़र यह द्वितीय-स्तर अनुवाद रखता है। यह पूरी श्रृंखला की सूत्र-रेखा बनती है, इसलिए एक बिंदु याद रखें: “अनुवाद तालिकाओं का स्वामी हाइपरवाइज़र है”।

5. डिवाइस I/O से — VMBus और दो प्रकार के डिवाइस

5.1. इम्यूलेटेड डिवाइस की सीमाएँ

चाइल्ड पार्टीशन को डिवाइस दिखाने का क्लासिक तरीका वास्तविक हार्डवेयर (उदाहरण पुराना IDE नियंत्रक) को सॉफ़्टवेयर में पूरी तरह नकल करना है। संगतता ऊँची है क्योंकि गेस्ट OS के इनबॉक्स ड्राइवर ज्यों के त्यों काम करते हैं, पर हर बार गेस्ट I/O पोर्ट छूते VM Exit होता है, और प्रदर्शन नहीं बढ़ता।

flowchart TB
    accTitle: इम्यूलेटेड डिवाइस पर I/O धीमा क्यों है
    accDescr: हर बार गेस्ट I/O पोर्ट ऑपरेट करता है, नियंत्रण VM Exit से हाइपरवाइज़र पक्ष जाता है, डिवाइस सॉफ़्टवेयर में नकल होता है, और गेस्ट पर लौटाया जाता है, इसलिए चक्कर दोहरता है और धीमा है
    gio["गेस्ट I/O पोर्ट ऑपरेट करता"] --> vex["VM Exit होता है"]
    vex --> emu2["डिवाइस सॉफ़्टवेयर में इम्यूलेट"]
    emu2 --> back["VM Entry से गेस्ट पर लौटें"]
    back -->|अगले पोर्ट ऑपरेशन पर दोहरा| gio

चित्र 9: यह चक्कर एक डिस्क पहुँच के पीछे कई बार चलता है, और संगतता की कीमत प्रदर्शन में चुकाई जाती है।

5.2. VMBus और VSP/VSC — वर्चुअलाइज़ेशन के लिए डिज़ाइन किया तेज़ पथ

इसलिए Hyper-V के पास वर्चुअलाइज़ेशन मानकर डिज़ाइन किया “सिंथेटिक डिवाइस” तंत्र है। तीन पात्र हैं।²

VMBus: पार्टीशनों के बीच तार्किक संचार चैनल। शेयर्ड मेमोरी उपयोग करने वाला उच्च-गति अंतर-पार्टीशन संचार देता है।³
VSP (Virtualization Service Provider): रूट-पार्टीशन पक्ष पर रहने वाली सेवा, जो चाइल्ड से डिवाइस अनुरोध प्राप्त कर उन्हें रूट पक्ष के डिवाइस/बैकएंड स्टैक से जोड़ती है। अनुरोध भौतिक डिवाइस तक पहुँच सकता है, या वर्चुअल डिस्क या वर्चुअल स्विच जैसे होस्ट-पक्ष बैकएंड सँभाल सकता है।
VSC (Virtualization Service Consumer): चाइल्ड-पार्टीशन पक्ष गेस्ट OS में जाने वाला सिंथेटिक डिवाइस ड्राइवर। VMBus पर VSP को अनुरोध भेजता है।

गेस्ट OS स्टोरेज अनुरोध उदाहरण लेकर, प्रवाह ऐसा दिखता है। गेस्ट ऐप का WriteFile गेस्ट कर्नेल के I/O स्टैक से उतरता है और, तल पर, VSC तक पहुँचता है (वास्तविक हार्डवेयर के बजाय)। VSC अनुरोध VMBus पर रख रूट पार्टीशन के VSP को सौंपता है, और VSP अनुरोध रूट-पक्ष I/O स्टैक में बहाता है। वर्चुअल-डिस्क (VHDX) कॉन्फ़िगरेशन में, यह लेखन होस्ट पर VHDX फ़ाइल पर लेखन के रूप में सँभलता है और अंततः भौतिक डिस्क तक पहुँचता है। इस दृष्टिकोण को Enlightened I/O (वर्चुअलाइज़ेशन से अवगत I/O) कहते हैं, और यह डिवाइस-इम्यूलेशन परत को बाईपास कर दक्षता बढ़ाता है।²

flowchart TB
    accTitle: सिंथेटिक डिवाइस का I/O पथ
    accDescr: चाइल्ड पार्टीशन के ऐप का I/O अनुरोध गेस्ट कर्नेल से VSC तक पहुँचता है, VMBus पार कर रूट पार्टीशन के VSP तक जाता है, और VSP जिस रूट-पक्ष I/O स्टैक से जोड़ता है उस पर भौतिक डिवाइस ड्राइवर से वास्तविक डिवाइस तक, या वर्चुअल डिस्क व वर्चुअल स्विच जैसे होस्ट-पक्ष बैकएंड तक जा सकता है
    app["चाइल्ड पार्टीशन का ऐप"] --> gk["गेस्ट कर्नेल I/O स्टैक"]
    gk --> vsc["VSC（सिंथेटिक डिवाइस ड्राइवर）"]
    vsc -->|VMBus| vsp["VSP（रूट-पार्टीशन पक्ष）"]
    vsp --> rio["रूट-पक्ष I/O स्टैक"]
    rio --> pdrv["भौतिक डिवाइस ड्राइवर"]
    rio --> hb["होस्ट-पक्ष बैकएंड（VHDX, vSwitch）"]
    pdrv --> dev["भौतिक डिवाइस"]

चित्र 10: सिंथेटिक डिवाइस से गेस्ट I/O VMBus पर रूट पार्टीशन पार करता है और, रूट-पक्ष स्टैक से, वास्तविक डिवाइस या होस्ट-पक्ष बैकएंड तक पहुँचता है।

अर्थात्, VM की डिस्क I/O या नेटवर्किंग तेज़ है या नहीं यह केवल गेस्ट पक्ष पर नहीं, रूट-पार्टीशन पक्ष के I/O स्टैक और डिवाइस ड्राइवर की अवस्था पर भी निर्भर करता है। VM प्रदर्शन समस्या जाँचते समय होस्ट-पक्ष अवलोकन अनिवार्य इसलिए है कि पथ वास्तव में होस्ट से गुज़रता है।

flowchart TB
    accTitle: इम्यूलेटेड डिवाइस बनाम सिंथेटिक डिवाइस
    accDescr: इम्यूलेटेड डिवाइस वास्तविक हार्डवेयर नकल करता है ताकि इनबॉक्स गेस्ट ड्राइवर काम करें पर धीमा है; सिंथेटिक डिवाइस VMBus मानकर बना उद्देश्य-निर्मित ड्राइवर है और तेज़ है
    dev2{"चाइल्ड को दिखाया डिवाइस"} --> emu["इम्यूलेटेड डिवाइस"]
    dev2 --> syn["सिंथेटिक डिवाइस"]
    emu -.-> emuP["वास्तविक हार्डवेयर नकल; संगतता पहले"]
    emuP -.-> emuC["हर I/O पर हस्तक्षेप; धीमा"]
    syn -.-> synP["VMBus के इर्द-गिर्द डिज़ाइन; तेज़"]
    synP -.-> synC["गेस्ट में मेल खाता ड्राइवर चाहिए"]

चित्र 11: दो प्रकार के वर्चुअल डिवाइस में, इम्यूलेटेड डिवाइस OS इंस्टॉल के तुरंत बाद संगतता उठाते हैं, और सिंथेटिक डिवाइस रोज़ के उपयोग में प्रदर्शन।

6. VM कभी उपयोग न करने पर भी यह किसी और की समस्या क्यों नहीं

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

वर्चुअलाइज़ेशन-आधारित सुरक्षा (VBS)। यह Windows हाइपरवाइज़र से पृथक वातावरण बनाकर सुरक्षा विशेषताएँ वहाँ रखती है। Windows 11 पर संगत हार्डवेयर पर क्लीन इंस्टॉल जैसी शर्तें पूरी होने पर डिफ़ॉल्ट से सक्षम होती है।¹ विवरण भाग 2 में हैं।
WSL2। यह हल्के यूटिलिटी VM के अंदर वास्तविक Linux कर्नेल चलाता है।⁶
Windows Sandbox। हाइपरवाइज़र से पृथक डिस्पोजेबल Windows वातावरण।⁷ दोनों भाग 3 में कवर हैं।

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

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

व्यवहार में लोग अक्सर एक और बात पर कदम रखते हैं: तृतीय-पक्ष वर्चुअलाइज़ेशन सॉफ़्टवेयर से सह-अस्तित्व। क्योंकि हाइपरवाइज़र CPU के वर्चुअलाइज़ेशन एक्सटेंशन का अनन्य उपयोग करता है, Windows हाइपरवाइज़र चलते वातावरण में VirtualBox आदि पारंपरिक तरीके से (CPU के वर्चुअलाइज़ेशन एक्सटेंशन स्वयं उपयोग कर) नहीं चल सकते। इसके लिए Windows Hypervisor Platform नामक सार्वजनिक API दी गई है, और तृतीय-पक्ष वर्चुअलाइज़ेशन स्टैक Windows हाइपरवाइज़र के ऊपर बैठकर चल सकता है।⁸ वर्तमान VirtualBox/VMware इस तंत्र से WSL2 से सह-अस्तित्व कर सकते हैं, पर मोड बदलने के साथ आने वाले प्रदर्शन और विशेषता अंतर कभी “Hyper-V (या VBS) सक्षम करने के बाद वर्चुअलाइज़ेशन सॉफ़्टवेयर अलग व्यवहार करने लगा” के रूप में देखे जाते हैं।

flowchart TB
    accTitle: CPU वर्चुअलाइज़ेशन एक्सटेंशन का स्वामी, और तृतीय-पक्ष पथ
    accDescr: Windows हाइपरवाइज़र चलते समय CPU वर्चुअलाइज़ेशन एक्सटेंशन का अनन्य स्वामी है; WHP समर्थित तृतीय-पक्ष वर्चुअलाइज़ेशन सॉफ़्टवेयर Windows Hypervisor Platform से उसके ऊपर चलता है, जबकि असमर्थित इम्प्लीमेंटेशन नहीं चल सकतीं या सीमित हैं
    vt["CPU वर्चुअलाइज़ेशन एक्सटेंशन（VT-x/AMD-V）"] --> hvon{"Windows हाइपरवाइज़र चल रहा?"}
    hvon -->|नहीं| direct["तृतीय-पक्ष सीधे उपयोग कर सकता"]
    hvon -->|हाँ| own["हाइपरवाइज़र का अनन्य उपयोग"]
    own --> whp["Windows Hypervisor Platform"]
    whp --> third["WHP-सक्षम तृतीय-पक्ष उसके ऊपर"]
    third -.-> nowhp["असमर्थित नहीं चलते, या सीमित"]

चित्र 13: वर्चुअलाइज़ेशन एक्सटेंशन का स्वामी एक है, और हाइपरवाइज़र चलते सह-अस्तित्व कर सकने वाला एकमात्र तृतीय-पक्ष सॉफ़्टवेयर वह है जो सार्वजनिक API (WHP) समर्थित करता है।

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

आप अपनी मशीन पर पुष्टि कर सकते हैं कि हाइपरवाइज़र चल रहा है या नहीं।

पहले, बिना एडमिनिस्ट्रेटर विशेषाधिकार चला सकने वाली जाँच।

# 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 केवल यह बताता है कि “क्या हम हाइपरवाइज़र के ऊपर चल रहे हैं”; रूट और चाइल्ड नहीं अलग करता। VM के अंदर Windows पर चलाएँ तो भी True लौटाता है, चाइल्ड पार्टीशन के रूप में। भौतिक PC पर Windows पर True हो तो वह Windows रूट पार्टीशन के अंदर है — इसे निष्पादन वातावरण के साथ पढ़ें।

अगला, Command Prompt से क्लासिक।

systeminfo

आउटपुट के अंत में “Hyper-V Requirements” देखें। जिस मशीन पर हाइपरवाइज़र अभी नहीं चल रहा, वहाँ व्यक्तिगत आवश्यकताएँ — SLAT समर्थन, वर्चुअलाइज़ेशन एक्सटेंशन सक्षम हैं या नहीं, आदि — सूचीबद्ध होती हैं। जिस मशीन पर हाइपरवाइज़र पहले से चल रहा हो, आवश्यकताओं के बजाय एक पंक्ति मिलती है: “A hypervisor has been detected. Features required for Hyper-V will not be displayed.”⁴ इसलिए वह एक पंक्ति यह कथन है कि आपका Windows किसी हाइपरवाइज़र के ऊपर चल रहा है। HypervisorPresent की तरह, भौतिक PC पर “रूट पार्टीशन के अंदर”, या VM के अंदर “चाइल्ड पार्टीशन के रूप में” पढ़ना पड़ता है।

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

GUI में, msinfo32 के “System Summary” के अंतर्गत “Virtualization-based security” पंक्ति देखें। ध्यान दें कि Task Manager के CPU पेन में “Virtualization: Enabled” केवल फ़र्मवेयर में वर्चुअलाइज़ेशन एक्सटेंशन सक्षम हैं या नहीं दिखाता है, जो हाइपरवाइज़र चल रहा है या नहीं से अलग जानकारी है।

flowchart TB
    accTitle: हाइपरवाइज़र चल रहा है या नहीं कैसे जाँचें
    accDescr: यदि systeminfo कहे कि हाइपरवाइज़र पता चला तो आप हाइपरवाइज़र पर चल रहे हैं（भौतिक PC पर रूट के अंदर）; यदि Hyper-V Requirements सूची आए तो अभी नहीं चल रहा इसलिए SLAT, VM Monitor Mode Extensions और DEP जैसी हर आवश्यकता जाँचें, पर सब Yes केवल हार्डवेयर पक्ष तैयार है और Hyper-V विशेषता की संस्करण आवश्यकता भी है
    start2["systeminfo चलाएँ"] --> q1{"आवश्यकता फ़ील्ड?"}
    q1 -->|Detected| running["हाइपरवाइज़र चल रहा"]
    running -.-> runN["रूट के अंदर"]
    runN -.-> runN2["भौतिक PC पर"]
    q1 -->|Listed| notyet["अभी नहीं चल रहा"]
    notyet --> q2{"सब आवश्यकताएँ Yes?"}
    q2 -->|सब Yes| can["हार्डवेयर पक्ष तैयार"]
    can -.-> ed["Pro / Ent / Edu चाहिए"]
    q2 -->|कुछ No| uefi["UEFI/BIOS आइटम जाँचें"]

चित्र 14: systeminfo का “Hyper-V Requirements” फ़ील्ड चलने-अवस्था जाँच और पूर्वापेक्षा जाँच दोनों का काम करता है।

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

8.1. “हमने Hyper-V सक्षम नहीं किया, इसलिए वर्चुअलाइज़ेशन हमारे PC से संबंधित नहीं”

यदि आपने Hyper-V विशेषता (प्रबंधन उपकरण और VM निष्पादन वातावरण) सक्षम न की हो, तब भी VBS सक्षम हो तो Windows हाइपरवाइज़र चल रहा होता है। ड्राइवर संगतता समस्या, प्रदर्शन परीक्षण, या तृतीय-पक्ष वर्चुअलाइज़ेशन सॉफ़्टवेयर की परेशानी जाँचते समय, विशेषता सक्षम है या नहीं नहीं — HypervisorPresent और VBS चलने की अवस्था जाँचें।

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

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

flowchart TB
    accTitle: आसानी से उलझने वाली तीन जाँचें
    accDescr: Task Manager का Virtualization फ़ील्ड फ़र्मवेयर सेटिंग दिखाता है, Windows Features सूची इंस्टॉल अवस्था, और systeminfo या HypervisorPresent चलने अवस्था; प्रत्येक अलग प्रश्न का उत्तर देता है
    q3{"कौन सा प्रश्न?"}
    q3 --> fw{"फ़र्मवेयर या Windows?"}
    q3 --> c3["हाइपरवाइज़र चल रहा?"]
    fw --> a3["फ़र्मवेयर एक्सटेंशन?"]
    fw --> b3["Hyper-V विशेषता ऑन?"]
    a3 -.-> a3t["Task Manager CPU पेन"]
    b3 -.-> b3t["Windows Features UI"]
    c3 -.-> c3t["systeminfo"]
    c3 -.-> c3tp["HypervisorPresent"]

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

8.3. “यदि VM धीमा है, तो गेस्ट-OS समस्या है”

सिंथेटिक-डिवाइस I/O VMBus पार कर रूट पार्टीशन के VSP तक जाता है और रूट-पक्ष डिवाइस/बैकएंड स्टैक (भौतिक ड्राइवर, तथा वर्चुअल-स्विच और वर्चुअल-डिस्क प्रोसेसिंग) से गुज़रता है। यदि केवल गेस्ट के अंदर काउंटर देखें, तो होस्ट-पक्ष स्टोरेज या NIC में बैठा बॉटलनेक नहीं मिलेगा। VM प्रदर्शन समस्याओं का सिद्धांत दोनों पक्षों से अवलोकन है: गेस्ट और होस्ट (रूट पार्टीशन)।

9. सारांश

Hyper-V सक्षम करने पर हाइपरवाइज़र हार्डवेयर पर सीधे चलता है और होस्ट Windows रूट पार्टीशन के रूप में चलता है।²
गेस्ट OS कर्नेल रिंग 0 पर चलता रहता है, और केवल इंटरसेप्ट के रूप में कॉन्फ़िगर ऑपरेशन, तथा अपवाद, VM Exit से हाइपरवाइज़र को सौंपे जाते हैं। साधारण मेमोरी पहुँच SLAT अनुवाद से गुज़रती हैं।
केवल रूट पार्टीशन भौतिक डिवाइस ड्राइवर और वर्चुअलाइज़ेशन प्रबंधन स्टैक रखता है, और हाइपरकॉल से चाइल्ड पार्टीशन बनाता है।²
मेमोरी GVA→GPA→SPA का दो-स्तर अनुवाद बन जाती है, और द्वितीय स्तर SLAT (EPT/RVI) हार्डवेयर में सँभालता है। वर्तमान Hyper-V को SLAT चाहिए।⁴
डिवाइस I/O पर सिंथेटिक-डिवाइस पथ VSC→VMBus→VSP हावी है, और प्रदर्शन होस्ट-पक्ष I/O स्टैक पर भी निर्भर करता है।²
Windows 11 पर, क्योंकि VBS क्लीन इंस्टॉल जैसी शर्तें पूरी करने वाले डिवाइस पर डिफ़ॉल्ट से सक्षम है, VM कभी उपयोग न करने वाले PC पर भी हाइपरवाइज़र का चलना असामान्य नहीं।¹ चलने अवस्था HypervisorPresent और systeminfo से पुष्टि कर सकते हैं।

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

flowchart TB
    accTitle: भाग 1 का बड़ा चित्र
    accDescr: हाइपरवाइज़र रूट और चाइल्ड पार्टीशन के नीचे बैठता है; CPU वर्चुअल प्रोसेसर शेड्यूल कर आवंटित होते हैं（VM Exit केवल कॉन्फ़िगर इंटरसेप्ट और अपवाद पर）, मेमोरी दो-स्तर SLAT अनुवाद से मध्यस्थ होती है, सिंथेटिक-डिवाइस I/O VMBus पर अग्रेषित होकर रूट के VSP सँभालता है, और इम्यूलेटेड डिवाइस व Discrete Device Assignment के अन्य पथ हैं
    up["रूट + चाइल्ड पार्टीशन"] --> hvS["हाइपरवाइज़र"]
    hvS --> cpuS["CPU: VP शेड्यूल"]
    hvS --> memS["मेमोरी: SLAT"]
    cpuS -.-> cpuN["इंटरसेप्ट पर VM Exit"]
    memS -.-> memN["दो-स्तर अनुवाद"]
    memS ~~~ devS
    devS["डिवाइस: VMBus I/O"] --> vspS["रूट-पक्ष VSP सँभालता"]
    devS -.-> devN["इम्यूलेटेड / DDA: अन्य"]

चित्र 16: CPU शेड्यूलिंग और मेमोरी अनुवाद हाइपरवाइज़र सीधे सँभालता है (VM Exit केवल हस्तक्षेप पर), और सिंथेटिक-डिवाइस I/O VMBus के उस पार रूट पार्टीशन (VSP) मध्यस्थता करता है।

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

हम इस लेख की सूत्र-रेखा उठाते हैं — कि हाइपरवाइज़र SLAT अनुवाद तालिकाएँ रखता है — और अनुसरण करते हैं कि Windows “वह मेमोरी जिसे न एडमिनिस्ट्रेटर पढ़ सकता है न कर्नेल” कैसे बनाता है।

संदर्भ लिंक

Microsoft Learn, Silicon assisted security. VBS के हार्डवेयर वर्चुअलाइज़ेशन से Secure Kernel को साधारण OS से अलग करने पर, और Windows 11 के नए इंस्टॉल पर पूर्वापेक्षाएँ पूरी करने वाले डिवाइस पर VBS और HVCI के डिफ़ॉल्ट से सक्षम होने पर। ↩ ↩² ↩³
Microsoft Learn, Hyper-V Architecture. हाइपरवाइज़र के पार्टीशन अलगाव की इकाई के रूप में देने पर; रूट पार्टीशन के हाइपरकॉल API से चाइल्ड पार्टीशन बनाने पर; पार्टीशन के भौतिक प्रोसेसर तक सीधी पहुँच के बिना निजी वर्चुअल मेमोरी स्पेस में चलने पर; VMBus, VSP, VSC और Enlightened I/O की भूमिकाओं पर; और हार्डवेयर वर्चुअलाइज़ेशन एक्सटेंशन (Intel VT/AMD-V) आवश्यक होने पर। ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²
Microsoft Learn, Hyper-V architecture (Performance Tuning). Hyper-V के Type 1 हाइपरवाइज़र होने पर, रूट पार्टीशन के भौतिक I/O डिवाइस रखने पर, और VMBus के शेयर्ड मेमोरी उपयोग करने वाला उच्च-प्रदर्शन अंतर-पार्टीशन संचार देने पर। ↩ ↩²
Microsoft Learn, System requirements for Hyper-V on Windows and Windows Server. SLAT-सक्षम 64-बिट प्रोसेसर और VM Monitor Mode Extensions आवश्यक होने पर; systeminfo के “Hyper-V Requirements” फ़ील्ड में आवश्यकताएँ पूरी होने की पुष्टि कर सकने पर; हाइपरवाइज़र चलते “A hypervisor has been detected” दिखने पर; और Discrete Device Assignment के विशिष्ट डिवाइस सीधे चाइल्ड पार्टीशन को सौंप सकने पर। ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Appendix B: Hyper-V Architecture and Feature Overview. VMMS (Virtual Machine Management Service) के चाइल्ड पार्टीशन में VM की अवस्था प्रबंधित करने पर, और हर VM के लिए रूट पार्टीशन में यूज़र मोड में वर्कर प्रोसेस (VMWP) शुरू होने पर। ↩
Microsoft Learn, Comparing WSL Versions. WSL2 के हल्के यूटिलिटी VM के अंदर वास्तविक Linux कर्नेल चलाने पर, और वर्तमान VMware तथा VirtualBox के साथ उपयोग की सावधानियों पर। ↩
Microsoft Learn, Windows Sandbox architecture. Windows Sandbox के कंटेनर तकनीक और हाइपरवाइज़र अलगाव को मिलाकर हल्का Windows वातावरण होने पर। ↩
Microsoft Learn, Windows Hypervisor Platform. तृतीय-पक्ष वर्चुअलाइज़ेशन स्टैक के Windows हाइपरवाइज़र के ऊपर पार्टीशन बनाने और प्रबंधित करने के लिए यूज़र-मोड API दिए जाने पर। ↩
Microsoft Learn, Enable Hotpatch for Azure Arc-enabled servers. Win32_DeviceGuard क्लास पर VirtualizationBasedSecurityStatus से VBS (virtual secure mode) की चलने अवस्था पुष्टि कर सकने पर। ↩
Microsoft Learn, Install Hyper-V. Hyper-V के Windows 10/11 Pro या Enterprise आदि पर सक्षम किए जा सकने, और Home संस्करण पर इंस्टॉल न होने पर। ↩

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

Windows वर्चुअलाइज़ेशन की गहराई (भाग 3) — सेकंडों में बूट होने वाली वर्चुअल मशीनें: WSL2, Windows Sandbox और कंटेनर इतने हल्के क्यों हैं

WSL2 और Windows Sandbox सेकंडों में शुरू होकर इतने हल्के क्यों लगते हैं? यह लेख डायनामिक बेस इमेज और डायरेक्ट मैप से डायनामिक मेमोरी आवंट...

लेख पढ़ें

Windows वर्चुअलाइज़ेशन की गहराई (भाग 2) — वह मेमोरी जिसे कर्नेल भी नहीं देख सकता: VBS, HVCI और Credential Guard कैसे काम करते हैं

संगत हार्डवेयर पर क्लीन इंस्टॉल पर VBS डिफ़ॉल्ट से सक्षम होता है और हाइपरवाइज़र तथा SLAT से कर्नेल से मज़बूत अलगाव बनाता है। यह लेख VTL, ...

लेख पढ़ें

Win32 Thread Pool API — CreateThreadpoolWork से थ्रेड बनाए बिना समवर्तिता

क्या आपके नेटिव कोड में CreateThread कॉल बिखरी पड़ी हैं? यह लेख Vista में पुनर्डिज़ाइन की गई Win32 थ्रेड पूल API — work, timer, wait और i...

लेख पढ़ें

Named Pipes व्यवहार में — डिज़ाइन से सुरक्षा तक, Windows की मानक IPC

Named pipes — Windows की मानक इंटर-प्रोसेस कम्युनिकेशन — की व्यावहारिक मार्गदर्शिका। यह लेख प्राथमिक स्रोतों से बाइट और मैसेज मोड का चुना...

लेख पढ़ें

क्षेत्र के नाम वाली खोजों में दिखें — छोटे-मझोले उद्यमों के लिए लोकल SEO की व्यावहारिक मार्गदर्शिका (क्षेत्र पृष्ठ और Google Business Profile)

उन छोटे-मझोले उद्यमों के लिए जिनकी साइट "क्षेत्र का नाम + उद्योग" खोजने पर नहीं दिखती। यह लेख लोकल SEO सुधारने का क्रम बताता है: Google B...

लेख पढ़ें

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

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

Windows ऐप विकास

व्यावसायिक ऐप, डिवाइस एकीकरण और संचार उपकरण, आवश्यकताओं से विकास तक।

सेवा देखें संपर्क करें

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

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

Hyper-V सक्षम करने पर होस्ट Windows वास्तव में कहाँ चलता है?: हाइपरवाइज़र भौतिक CPU और मेमोरी के आवंटन पर सीधा नियंत्रण लेता है, और होस्ट Windows रूट पार्टीशन नामक विशेष पार्टीशन के अंदर चलता है। भौतिक डिवाइस का नियंत्रण सामान्यतः रूट-पार्टीशन पक्ष के ड्राइवर सँभालते हैं। रूट पार्टीशन डिवाइस ड्राइवर और वर्चुअलाइज़ेशन प्रबंधन स्टैक रखता है, पर भौतिक CPU का स्वामित्व हाइपरवाइज़र का है।
क्या Task Manager का "Virtualization: Enabled" मतलब है कि Hyper-V चल रहा है?: नहीं। वह प्रदर्शन दिखाता है कि CPU के वर्चुअलाइज़ेशन एक्सटेंशन (Intel VT-x/AMD-V) फ़र्मवेयर में सक्षम हैं या नहीं। यह देखने के लिए कि हाइपरवाइज़र वास्तव में चल रहा है, systeminfo में "A hypervisor has been detected" देखें, या Win32_ComputerSystem.HypervisorPresent जाँचें।
मैंने कभी VM नहीं बनाया, फिर भी हाइपरवाइज़र क्यों चल रहा है?: Windows 11 पर वर्चुअलाइज़ेशन-आधारित सुरक्षा (VBS) उन डिवाइस पर डिफ़ॉल्ट से सक्षम होती है जो शर्तें पूरी करते हैं — उदाहरण के लिए संगत हार्डवेयर पर क्लीन इंस्टॉल — और VBS Windows हाइपरवाइज़र पर बना है। वही बात यदि आप WSL2 या Windows Sandbox उपयोग करते हैं। VM उपयोग से बिना संबंध हाइपरवाइज़र का चलना असामान्य नहीं।
SLAT क्या है, और Hyper-V के लिए यह क्यों आवश्यक है?: SLAT (Second Level Address Translation) वह तंत्र है जिससे CPU गेस्ट भौतिक पतों को वास्तविक भौतिक पतों में अनुवादित करता है; Intel EPT और AMD RVI इम्प्लीमेंटेशन हैं। उसके बिना हाइपरवाइज़र को अनुवाद तालिकाएँ सॉफ़्टवेयर में रखनी पड़तीं, जो प्रदर्शन की दृष्टि से यथार्थवादी नहीं, इसलिए वर्तमान Hyper-V इसे कठोर आवश्यकता मानता है।
यदि मैं Hyper-V सक्षम करूँ, तो क्या VirtualBox और VMware काम करना बंद कर देंगे?: क्योंकि हाइपरवाइज़र CPU के वर्चुअलाइज़ेशन एक्सटेंशन का अनन्य उपयोग करता है, तृतीय-पक्ष हाइपरवाइज़र पारंपरिक तरीके से नहीं चल सकता। पर वर्तमान VirtualBox और VMware में Windows हाइपरवाइज़र के ऊपर चलने वाला मोड है (Windows Hypervisor Platform के माध्यम से), इसलिए प्रत्येक के हाल के संस्करण सह-अस्तित्व कर सकते हैं।

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

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

Go Komura

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

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

प्रोफ़ाइल देखें संपर्क करें

सार्वजनिक लिंक

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

ब्लॉग पर लौटें

Windows वर्चुअलाइज़ेशन की गहराई (भाग 1) — आपका Windows वास्तव में कहाँ चल रहा है? हाइपरवाइज़र और पार्टीशन

“Windows वर्चुअलाइज़ेशन की गहराई” — सभी 3 भाग

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

2. CPU से — रिंगों के नीचे एक और विशेषाधिकार

2.1. रिंग सुरक्षा की पुनरावृत्ति

2.2. वर्चुअलाइज़ेशन एक्सटेंशन — हाइपरवाइज़र के लिए आरक्षित मोड

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

3. पार्टीशन — अलगाव की इकाई

3.1. केवल रूट पार्टीशन के पास भूमिकाएँ

3.2. चाइल्ड पार्टीशन से दिखने वाली दुनिया

4. मेमोरी से — पता अनुवाद एक और स्तर पाता है

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

4.2. SLAT — हार्डवेयर में दो-स्तर अनुवाद

5. डिवाइस I/O से — VMBus और दो प्रकार के डिवाइस

5.1. इम्यूलेटेड डिवाइस की सीमाएँ

5.2. VMBus और VSP/VSC — वर्चुअलाइज़ेशन के लिए डिज़ाइन किया तेज़ पथ

6. VM कभी उपयोग न करने पर भी यह किसी और की समस्या क्यों नहीं

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

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

8.1. “हमने Hyper-V सक्षम नहीं किया, इसलिए वर्चुअलाइज़ेशन हमारे PC से संबंधित नहीं”

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

8.3. “यदि VM धीमा है, तो गेस्ट-OS समस्या है”

9. सारांश

संबंधित लेख

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

संदर्भ लिंक

Windows वर्चुअलाइज़ेशन की गहराई (भाग 2) — वह मेमोरी जिसे कर्नेल भी नहीं देख सकता: VBS, HVCI और Credential Guard कैसे काम करते हैं

Win32 Thread Pool API — CreateThreadpoolWork से थ्रेड बनाए बिना समवर्तिता

Named Pipes व्यवहार में — डिज़ाइन से सुरक्षा तक, Windows की मानक IPC

संबंधित विषय

Windows के तकनीकी विषय

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

Windows ऐप विकास

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

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

Go Komura