क्या WSL2 एक VM है?

हाँ। WSL2 Microsoft द्वारा बनाए गए वास्तविक Linux कर्नेल को हल्के यूटिलिटी VM के अंदर चलाता है। VM को WSL पर्दे के पीछे प्रबंधित करता है, इसलिए डिज़ाइन उपयोगकर्ता को VM सेटिंग या बूट की प्रतीक्षा सोचने नहीं देता। हर Linux वितरण इस प्रबंधित VM के अंदर पृथक कंटेनर के रूप में चलता है।

WSL2 में /mnt/c के अंतर्गत फ़ाइल ऑपरेशन धीमे क्यों हैं?

क्योंकि WSL2 Linux कर्नेल से Windows-पक्ष फ़ाइल सिस्टम तक पहुँच OS सीमा पार करने वाली फ़ाइल शेयरिंग से जाती है। Linux फ़ाइल सिस्टम (ext4 वर्चुअल डिस्क) पर ऑपरेशन तेज़ हैं, इसलिए नियम है प्रोजेक्ट फ़ाइलें उन उपकरणों वाले उसी OS पक्ष पर रखें जो उन पर काम करते हैं।

क्या vmmem प्रोसेस का बड़ा मेमोरी उपयोग लीक है?

अधिकांश मामलों में लीक नहीं। WSL2 मेमोरी उपयोग के साथ बढ़ती-सिकुड़ती है, और प्रोसेस ने जो मेमोरी छोड़ी वह pageReporting सेटिंग के अधीन Windows को लौटाई जाती है, जो डिफ़ॉल्ट से सक्षम है। फ़ाइल-कैश पेज भी वर्तमान WSL .wslconfig में autoMemoryReclaim से स्वतः पुनः प्राप्त करता है (डिफ़ॉल्ट dropCache है)। जिन वातावरणों में ये सेटिंग अक्षम हैं, या पुराने WSL पर, मेमोरी VM निकलने तक रह सकती है; उस स्थिति में memory सेटिंग से ऊपरी सीमा सेट करें, या wsl --shutdown से लौटाएँ।

Windows Sandbox कुछ सौ मेगाबाइट डिस्क से पूर्ण Windows कैसे बूट कर सकता है?

डायनामिक बेस इमेज नामक तंत्र से। यह होस्ट पर पहले से इंस्टॉल Windows से अपरिवर्तनीय OS फ़ाइलें साझा करता है, और केवल थोड़ी संख्या में परिवर्तनीय फ़ाइलों की साफ़ प्रति रखता है। इससे Windows की पूर्ण प्रति संग्रहीत किए बिना पूर्ण, बूट योग्य इमेज जोड़ी जा सकती है।

क्या कंटेनर VM से अधिक सुरक्षित हैं?

यह अलगाव मोड पर निर्भर करता है। प्रोसेस-पृथक कंटेनर होस्ट के साथ कर्नेल साझा करते हैं, और Microsoft इसे मज़बूत सुरक्षा सीमा नहीं मानता। विरोधी कोड सँभालते समय Hyper-V अलगाव चाहिए, जो हर कंटेनर को अपना समर्पित कर्नेल देता है।

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

22 Aug 2026 04:00 · Go Komura · Windows, वर्चुअलाइज़ेशन, WSL2, Windows Sandbox, कंटेनर, Hyper-V

Hyper-V Manager में Windows VM बनाएँ तो शुरू होने में दसियों सेकंड लगते हैं और कई गीगाबाइट मेमोरी एकाधिकार में लेता है। पर उसी PC पर wsl टाइप करने से कुछ सेकंड में Linux शेल लौटता है, और Windows Sandbox भी कुछ सेकंड में डिस्पोजेबल डेस्कटॉप खोलता है।¹

दोनों उसी Windows हाइपरवाइज़र पर टिके हैं (भाग 1, “आपका Windows वास्तव में कहाँ चल रहा है?”)। भाग 2 में हमने देखा कि यह बुनियाद कर्नेल से मज़बूत अलगाव बना सकती है। तो एक भारी और दूसरा हल्का क्यों?

श्रृंखला की अंतिम किस्त जो प्रश्न हल करती है वह केवल एक है।

पूर्ण VM भारी हैं — तो WSL2 और Windows Sandbox इतने हल्के क्यों हैं?

लक्षित पाठक वे डेवलपर और ऑपरेटर हैं जो विकास और सत्यापन के लिए WSL2, Windows Sandbox और Windows कंटेनर उपयोग करते हैं, और उनका हल्कापन तथा बाधाएँ तंत्र से समझना चाहते हैं। पूर्वापेक्षाएँ हैं Windows 10/11; Windows Sandbox धारा चलाने के लिए Pro, Enterprise या Education संस्करण चाहिए (Home और Windows Server में यह विशेषता नहीं)। पृष्ठभूमि ज्ञान भाग 1 की पार्टीशन अवधारणा है। कठिनाई मध्यम है।

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

हल्की VM अलगाव रेखा (समर्पित कर्नेल और हाइपरवाइज़र सीमा) रखती है और “पूर्ण गेस्ट OS की प्रति” हल्की करती है। Sandbox होस्ट के Windows स्वयं साझा करता है; WSL2 गेस्ट को छोटे, उद्देश्य-निर्मित Linux से बदलता है; और दोनों मामलों में मेमोरी स्थिर आरक्षण नहीं बल्कि होस्ट के साथ गतिशील उधार-देन है।

पूर्ण VM के भार का स्रोत अलगाव स्वयं नहीं बल्कि द्विरावृत्ति है। डिस्क पर एक और OS इमेज, RAM में एक और OS जितने पेज, और हर शुरू पर एक और पूर्ण बूट। हल्की VM वह द्विरावृत्ति दो नीतियों से काटती हैं: “जो साझा करना सुरक्षित हो उसे साझा करें” (Sandbox) और “यदि साझा न कर सकें, तो छोटा बनाकर पुनर्निर्माण करें” (WSL2)।

flowchart TB
    accTitle: हल्की VM सहारा देने वाले तीन प्रकार के साझाकरण
    accDescr: पूर्ण VM जो OS इमेज दोहराता था उसे Sandbox साझा कर और WSL2 सिकोड़ कर काटता है; डिफ़ॉल्ट स्थिर आवंटन वाली मेमोरी（डायनामिक मेमोरी अपवाद）होस्ट के साथ गतिशील उधार-देन बनती है; प्रारंभ हल्के कर्नेल और न्यूनतम सेटअप से बदलता है; केवल अलगाव सीमा रहती है
    heavy["पूर्ण VM: द्विरावृत्ति"] --> d1["डिस्क: OS इमेज प्रति"]
    heavy --> more{"मेमोरी या प्रारंभ?"}
    more --> d2["मेमोरी: स्थिर डिफ़ॉल्ट"]
    more --> d3["प्रारंभ: पूर्ण बूट"]
    d1 -->|बदलता| s1["साझा（Sandbox）"]
    s1 -.-> s1b["या सिकोड़ें（WSL2）"]
    d2 -->|बदलता| s2["गतिशील होस्ट उधार"]
    d3 -->|बदलता| s3["हल्का कर्नेल + न्यून."]

चित्र 1: “वही हाइपरवाइज़र, फिर भी हल्का” के उत्तर का कंकाल यह है कि उन्होंने द्विरावृत्ति रोकी, अलगाव नहीं।

नीचे हम WSL2, Windows Sandbox और कंटेनर इसी क्रम में देखते हैं, और प्रत्येक किस प्रकार की द्विरावृत्ति काटता है।

2. पूर्ण VM क्या ढो रहा है

तुलना की आधार रेखा के रूप में, पारंपरिक VM क्या ढोता है।

स्वतंत्र OS इमेज। गेस्ट OS की हर फ़ाइल वर्चुअल डिस्क के अंदर रखता है। होस्ट पर वही Windows हो तो भी साझा नहीं करता।
मोटा मेमोरी आवंटन। पारंपरिक VM का डिफ़ॉल्ट होस्ट मेमोरी स्थिर आकार पर आवंटित करना है। Hyper-V Dynamic Memory जैसे तंत्र कॉन्फ़िगर सीमा के भीतर आवंटन बढ़ा-घटा सकते हैं, पर माँग बदलने के समायोजन के साधन सीमित हैं।²
सामान्य-उद्देश्य पूर्ण बूट। फ़र्मवेयर, बूट लोडर, और सेवाओं का सेट भौतिक मशीन जैसी ही क्रम में शुरू होता है।

flowchart TB
    accTitle: पूर्ण VM के तीन भार
    accDescr: पूर्ण VM स्वतंत्र OS इमेज, डिफ़ॉल्ट स्थिर मेमोरी आवंटन, और सामान्य-उद्देश्य पूर्ण बूट ढोता है, और वे डिस्क, RAM तथा प्रारंभ समय में लागत बनते हैं
    fullvm["पूर्ण VM"] --> b1["स्वतंत्र OS इमेज"]
    fullvm --> more{"मेमोरी या बूट?"}
    more --> b2["स्थिर मेमोरी डिफ़ॉल्ट"]
    more --> b3["सामान्य-उद्देश्य बूट"]
    b1 -.-> c1["प्रति के लिए अतिरिक्त डिस्क"]
    b2 -.-> c2["अप्रयुक्त RAM भी रखता"]
    b3 -.-> c3["दसियों सेकंड लगते"]

चित्र 2: पूर्ण VM की लागत का विघटन अलगाव के लिए नहीं बल्कि सामान्यता और द्विरावृत्ति के लिए चुकाया जाता है।

ये दोष नहीं; “गेस्ट में कुछ भी रख सकते हैं” सामान्यता की कीमत हैं। Windows Server के बगल पुराना Linux चलाने जैसे उपयोग के लिए वह सामान्यता मूल्य है। पर “विकास या सत्यापन के लिए होस्ट जैसा (या पूर्वनिर्धारित) OS अभी चलाना चाहता हूँ” जैसे उपयोग के लिए अधिकांश व्यर्थ सामान है। हल्की VM उद्देश्य संकीर्ण कर वह सामान उतार देती हैं।

3. WSL2 — उद्देश्य-निर्मित कर्नेल वाला यूटिलिटी VM

3.1. संरचना: प्रबंधित VM और उसके अंदर वितरण

WSL2 वह तंत्र है जो हल्के यूटिलिटी VM के अंदर वास्तविक Linux कर्नेल चलाता है।³ तीन बिंदु हैं।

कर्नेल वास्तविक है, पर विशिष्ट उत्पाद है। यह Stable शाखा से Microsoft द्वारा बनाया Linux कर्नेल है, आकार और प्रदर्शन में पहले से WSL2 के लिए ट्यून। वर्तमान मानक, Microsoft Store–वितरित WSL पर, कर्नेल WSL पैकेज के साथ अद्यतन होता है और wsl --update से लागू होता है (पुराने इन-बॉक्स वितरण पर Windows Update से आता था)।⁴ क्योंकि कर्नेल वास्तविक है, सिस्टम-कॉल संगतता पूर्ण है, और Docker जैसे उपकरण ज्यों के त्यों चलते हैं।
VM पर्दे के पीछे है। VM बनाना, शुरू करना और रोकना WSL प्रबंधित करता है; उपयोगकर्ता बस शेल खोलता है। VM-सेटिंग स्क्रीन नहीं और बूट की प्रतीक्षा महसूस नहीं।⁴
वितरण VM के अंदर कंटेनर है। Ubuntu और Debian जैसे वितरण एक प्रबंधित VM के अंदर पृथक कंटेनर के रूप में चलते हैं। वे नेटवर्क नेमस्पेस और कर्नेल साझा करते हैं, जबकि PID, माउंट और यूज़र जैसे नेमस्पेस अलग हैं।³

flowchart TB
    accTitle: WSL2 वास्तुकला
    accDescr: होस्ट Windows और हल्का यूटिलिटी VM हाइपरवाइज़र पर साथ बैठते हैं; Microsoft-निर्मित Linux कर्नेल VM के अंदर चलता है; और हर वितरण उसके अंदर पृथक कंटेनर के रूप में चलता है
    hv["हाइपरवाइज़र"] --> host["होस्ट Windows"]
    hv --> uvm["हल्का यूटिलिटी VM"]
    uvm --> lk["Linux कर्नेल（Microsoft बिल्ड; wsl --update）"]
    lk --> u1["Ubuntu（कंटेनर）"]
    lk --> u2["Debian（कंटेनर）"]
    host <-->|"Interop（कमांड, फ़ाइलें, नेटवर्क）"| uvm

चित्र 3: “क्या WSL2 VM है?” का उत्तर “हाँ, पर प्रबंधित, पर्दे-के-पीछे VM” है, और कई वितरण इंस्टॉल करने पर भी VM एक ही रहता है।

wsl टाइप करने के क्षण पीछे ऐसा दिखता है।

flowchart TB
    accTitle: wsl कमांड चलाने से कुछ सेकंड में शेल लौटने तक
    accDescr: wsl चलाने पर यदि यूटिलिटी VM नहीं चल रहा हो तो हल्का VM और Linux कर्नेल शुरू होते हैं; यदि पहले से चल रहा हो तो पुनः उपयोग; और वितरण के कंटेनर में शेल लौटता है
    cmd["wsl चलाएँ"] --> vmq{"यूटिलिटी VM पहले से चल रहा?"}
    vmq -->|नहीं| bootvm["हल्का VM और Linux कर्नेल शुरू（कुछ सेकंड）"]
    vmq -->|हाँ| reuse["पहले से चलते VM का पुनः उपयोग"]
    bootvm --> shell["कंटेनर के अंदर शेल लौटता"]
    reuse --> shell

चित्र 4: प्रतीक्षा केवल न्यूनतम VM प्रारंभ है, और यहीं पूर्ण बूट का सामान उतारना दिखता है।

3.2. फ़ाइल I/O: किस पक्ष पर रखें इससे अलग चीज़ बन जाती है

WSL2 प्रदर्शन की बात में हमेशा आने वाला विषय यह है कि फ़ाइलें कहाँ रखें।

Linux पक्ष की फ़ाइलों (ext4 वर्चुअल डिस्क) पर ऑपरेशन तेज़ हैं। क्योंकि Linux कर्नेल अपने फ़ाइल सिस्टम से सीधे बात करता है, और WSL1 की तुलना में टारबॉल निकालने में 20 गुना तक, तथा git clone और npm install में 2–5 गुना तेजी के उदाहरण बताए गए हैं।⁴
Windows पक्ष की फ़ाइलों (/mnt/c आदि) पर ऑपरेशन धीमे हो जाते हैं क्योंकि वे OS सीमा पार करने वाली फ़ाइल शेयरिंग से जाते हैं। क्रॉस-OS फ़ाइल-सिस्टम प्रदर्शन वह एक बड़ा आइटम है जहाँ WSL2 WSL1 से खराब है।⁴

इसलिए नियम है: “प्रोजेक्ट फ़ाइलें उन उपकरणों वाले उसी OS पक्ष पर रखें जो उन पर काम करते हैं”।⁴ Linux बिल्ड उपकरणों से सँभाला रिपॉज़िटरी Linux पक्ष पर जाता है; Visual Studio में बिल्ड किया समाधान Windows पक्ष पर।

flowchart TB
    accTitle: WSL2 फ़ाइल I/O पथों का काँटा
    accDescr: Linux-पक्ष ext4 वर्चुअल डिस्क तक पहुँच Linux कर्नेल से सीधी इसलिए तेज़; Windows-पक्ष फ़ाइलों तक पहुँच OS सीमा पार शेयरिंग से इसलिए धीमी
    io["WSL2 के अंदर फ़ाइल ऑपरेशन"] --> place{"फ़ाइल किस पक्ष?"}
    place -->|"Linux पक्ष（home आदि）"| ext4["ext4 वर्चुअल डिस्क पर सीधा I/O"]
    place -->|"Windows पक्ष（/mnt/c आदि）"| p9["OS सीमा पार शेयरिंग से"]
    ext4 --> fast["तेज़（WSL1 से 20 गुना तक उदाहरण）"]
    p9 --> slow["धीमा होने लगता"]
    slow -.-> fix["हल: फ़ाइल उपयोग करने वाले OS पर"]

चित्र 5: जो धीमा है वह पथ है, WSL2 नहीं, इसलिए फ़ाइलें कहाँ रखें बदलने से प्रदर्शन समस्या अक्सर गायब हो जाती है।

3.3. मेमोरी: बढ़ती है, सिकुड़ती है, पर सब कुछ हमेशा नहीं लौटाती

WSL2 का मेमोरी उपयोग (Task Manager में vmmem प्रोसेस के रूप में दिखता है) स्थिर आरक्षण नहीं; उपयोग के साथ बढ़ता-सिकुड़ता है। प्रोसेस ने जो मेमोरी छोड़ी वह pageReporting सेटिंग के अधीन स्वतः Windows को लौटाई जाती है, जो डिफ़ॉल्ट से सक्षम है।⁵ फ़ाइल कैश के रूप में रखे पेज पहले VM निकलने तक Windows को नहीं लौटते थे।⁴ वर्तमान WSL में, प्रयोगात्मक .wslconfig सेटिंग autoMemoryReclaim (डिफ़ॉल्ट dropCache) कैश भी स्वतः पुनः प्राप्त करती है।⁵ जिन वातावरणों में यह सेटिंग disabled है, या पुराने WSL पर, लंबे सत्र का कैश VM निकलने तक रह सकता है और होस्ट मेमोरी पर दबाव डाल सकता है।

flowchart TB
    accTitle: WSL2 मेमोरी कैसे बढ़ती, सिकुड़ती और लौटती है
    accDescr: WSL2 के अंदर माँग बढ़ने से VM का मेमोरी उपयोग बढ़ता है; प्रोसेस-छोड़े पेज डिफ़ॉल्ट-सक्षम pageReporting से Windows को लौटते हैं; फ़ाइल कैश डिफ़ॉल्ट पर autoMemoryReclaim स्वतः पुनः प्राप्त करता है; पर अक्षम सेटिंग या पुराने WSL पर VM निकलने तक रहता है, और wsl --shutdown सब लौटाता है
    grow["WSL2 के अंदर मेमोरी माँग बढ़ती"] --> vm["vmmem उपयोग बढ़ता"]
    vm --> freed{"वह पेज छोड़ा गया?"}
    freed -->|"प्रोसेस ने छोड़ा（pageReporting ऑन）"| ret["स्वतः Windows को लौटा"]
    freed -->|फ़ाइल कैश के रूप में| amr["autoMemoryReclaim स्वतः पुनः प्राप्त（डिफ़ॉल्ट）"]
    amr -.-> old2["अक्षम सेटिंग या पुराने WSL पर VM निकलने तक"]
    old2 --> sd["wsl --shutdown सब लौटाता"]

चित्र 6: जो “केवल बढ़ता गया” लगता है मुख्यतः कैश है (और pageReporting बंद हो तो प्रोसेस-छोड़े पेज भी), इसलिए लीक तय करने से पहले लौटने का पथ जानें।

यदि स्पष्ट ऊपरी सीमा चाहिए, %UserProfile%\.wslconfig VM की समग्र मेमोरी, CPU संख्या और स्वैप नियंत्रित कर सकता है।⁵

# %UserProfile%\.wslconfig
[wsl2]
memory=8GB
processors=4
swap=2GB

सेटिंग बदलने के बाद प्रभावी होने के लिए wsl --shutdown से VM पुनः शुरू करें। यह गतिशील आवंटन — “ऊपरी सीमा सेटिंग है, वास्तविक उपयोग माँग का अनुसरण करता है” — अगले विषय Windows Sandbox में और आगे जाता है।

4. Windows Sandbox — होस्ट के Windows का पुनः उपयोग

4.1. डायनामिक बेस इमेज: 500 MB में पूर्ण Windows

Windows Sandbox हाइपरवाइज़र से पृथक डिस्पोजेबल Windows डेस्कटॉप है। बंद करें तो सब गायब; अगली बार साफ़ अवस्था से कुछ सेकंड में शुरू होता है।¹

पहली पहेली डिस्क है। पूर्ण Windows बूट कर सकता है, फिर भी इंस्टॉल के बाद Sandbox की बेस इमेज केवल लगभग 500 MB है, और वितरण समय संपीड़ित 30 MB।² रहस्य डायनामिक बेस इमेज है।

अधिकांश OS फ़ाइलें अपरिवर्तनीय हैं, इसलिए होस्ट की प्रतियाँ ज्यों की त्यों साझा हो सकती हैं।
थोड़ी संख्या में परिवर्तनीय फ़ाइलें साझा नहीं हो सकतीं, इसलिए उनकी साफ़ प्रति बेस इमेज के अंदर रखी जाती है।
प्रारंभ पर, होस्ट की अपरिवर्तनीय फ़ाइलें और परिवर्तनीय फ़ाइलों की स्थानीय प्रतियाँ मिलाकर पूर्ण Windows इमेज जोड़ी जाती है।²

अर्थात्, Sandbox Windows की प्रति न डाउनलोड करता है न संग्रहीत; वह होस्ट पर पहले से इंस्टॉल Windows का पुनः उपयोग कर शुरू होता है।

flowchart TB
    accTitle: डायनामिक बेस इमेज कैसे जोड़ी जाती है
    accDescr: होस्ट Windows से अपरिवर्तनीय OS फ़ाइलें साझा होती हैं; केवल परिवर्तनीय फ़ाइलें बेस इमेज में साफ़ प्रति के रूप में रखी जाती हैं; और दोनों मिलाकर Sandbox की पूर्ण Windows इमेज बनती है
    hostw["होस्ट का पूर्ण Windows"] --> imm["अपरिवर्तनीय OS फ़ाइलें（अधिकांश）"]
    hostw --> mut["परिवर्तनीय OS फ़ाइलें（अल्पसंख्यक）"]
    imm -->|ज्यों की त्यों साझा| img["Sandbox बूट इमेज"]
    mut -->|साफ़ प्रति रखें| img
    img --> boot["पूर्ण Windows के रूप में बूट"]
    img -.-> size["केवल लगभग 500 MB संग्रहीत"]

चित्र 7: डिस्क द्विरावृत्ति छोड़ने का रूप “दूसरा Windows रखना” नहीं बल्कि “होस्ट के Windows से जोड़ना” है।

वह संयोजन निम्नलिखित जीवनचक्र संभव बनाता है। जो त्यागा जाता है वह Sandbox के अंदर स्थानीय अवस्था है। यदि .wsb कॉन्फ़िगरेशन फ़ाइल में होस्ट से लेखन योग्य फ़ोल्डर मैप किया हो, वहाँ के परिवर्तन होस्ट पर रहते हैं।⁶

flowchart TB
    accTitle: Windows Sandbox जीवनचक्र
    accDescr: शुरू करना कुछ सेकंड में साफ़ Windows तैयार करता है; ऐप सत्यापन या प्रयोग के बाद बंद करें तो Sandbox के अंदर सारी अवस्था त्यागी जाती है इसलिए अगली बार भी साफ़ शुरू; पर लेखन योग्य मैप किए होस्ट फ़ोल्डर के परिवर्तन रहते हैं
    launch["शुरू（कुछ सेकंड）"] --> clean["साफ़ Windows"]
    clean --> work["ऐप सत्यापन या प्रयोग"]
    work --> close2["बंद करें"]
    close2 --> discard["Sandbox के अंदर सारी अवस्था त्यागें"]
    discard -.-> mapped["मैप किए लेखन योग्य फ़ोल्डर के परिवर्तन होस्ट पर रहते"]
    discard -->|अगला प्रारंभ| launch

चित्र 8: हर बार साफ़ लौट सकना इसलिए है कि परिवर्तनीय भाग डिस्पोजेबल प्रति है, और उसे त्यागना डिज़ाइन का भाग है।

4.2. डायरेक्ट मैप: वही ntdll.dll वही भौतिक पेज है

न केवल डिस्क बल्कि RAM भी साझा होती है। क्योंकि Sandbox होस्ट जैसी ही OS इमेज चलाता है, “डायरेक्ट मैप” नामक तकनीक उपयोग होती है ताकि OS बाइनरी के लिए होस्ट जैसी ही भौतिक मेमोरी पेज उपयोग करे। जब ntdll.dll Sandbox के अंदर मेमोरी में लोड होता है, वह होस्ट पर पहले से लोड उसी बाइनरी के उसी भौतिक पेज की ओर इंगित करता है। होस्ट के रहस्य खतरे में डाले बिना, पारंपरिक VM से बहुत छोटा मेमोरी पदचिह्न पाता है।²

“एक ही भौतिक पेज कई उपयोगकर्ताओं में साझा करें” — वही विचार है जो मेमोरी श्रृंखला के भाग 3 में अनुसरण किए सेक्शन ऑब्जेक्ट से DLL साझाकरण का (“Section Object और Copy-on-Write”)। वह तंत्र प्रोसेस के बीच साझाकरण था; Sandbox इसे VM सीमा पार करता है।

flowchart TB
    accTitle: डायरेक्ट मैप से भौतिक-पेज साझाकरण
    accDescr: होस्ट का ऐप और Sandbox के अंदर ऐप ntdll जैसी OS बाइनरी के लिए एक ही भौतिक मेमोरी पेज साझा करते हैं, जिससे मेमोरी उपयोग घटता है
    happ["होस्ट का ऐप"] --> hva["होस्ट-पक्ष वर्चुअल पता"]
    sapp["Sandbox के अंदर ऐप"] --> sva["Sandbox-पक्ष वर्चुअल पता"]
    hva --> phys["वही भौतिक पेज（ntdll.dll जैसी OS बाइनरी）"]
    sva --> phys
    phys -.-> save["OS जितनी RAM दोहरानी नहीं"]

चित्र 9: डायरेक्ट मैप प्रोसेस के बीच उपयोग हुआ पेज-साझाकरण विचार है, VM सीमा पार लागू।

4.3. मेमोरी उधार-देन: VM से अधिक प्रोसेस जैसा

पारंपरिक VM के स्थिर मेमोरी आवंटन के विरुद्ध, Sandbox जिस कंटेनर तकनीक पर बैठता है संसाधन आवंटन होस्ट के सहयोग से गतिशील तय करता है। यदि होस्ट मेमोरी कम पड़े, वह कंटेनर से मेमोरी उसी तरह पुनः प्राप्त कर सकता है जैसे साधारण प्रोसेस से।² Hyper-V Dynamic Memory भी VM का आवंटन कॉन्फ़िगर सीमा के भीतर बढ़ा-घटाता है, पर Sandbox आगे जाता है: अंतर यह है कि वह होस्ट के मेमोरी प्रबंधन के उसी मैदान पर उधार-देन करता है।

flowchart TB
    accTitle: होस्ट और Sandbox के बीच मेमोरी सहयोग
    accDescr: पारंपरिक VM का डिफ़ॉल्ट सीमित समायोजन साधन वाला स्थिर-आकार अनन्य आवंटन है; Sandbox होस्ट मेमोरी दबाव के उत्तर में पुनः-प्राप्ति लक्ष्य बनता है और साधारण प्रोसेस जैसे उसी मैदान पर मेमोरी उधार-देन करता है
    pressure["होस्ट मेमोरी दबाव बढ़ता"] --> from{"कहाँ से पुनः प्राप्त करें?"}
    from --> proc["साधारण प्रोसेस के Working Set"]
    from --> sbx["Sandbox（कंटेनर）का उपयोग"]
    proc --> relief["खाली मेमोरी सुरक्षित"]
    sbx --> relief
    relief -.-> contrast["पारंपरिक VM के समायोजन साधन सीमित"]

चित्र 10: मेमोरी के उधार-देन में Sandbox VM पक्ष के बजाय प्रोसेस पक्ष पर खड़ा है, और होस्ट संकट में मेमोरी पेश करता है।

भाग 1 में हमने कहा “VM का प्रदर्शन होस्ट पक्ष पर भी निर्भर करता है”, पर हल्की VM से एक कदम और: मेमोरी का आवंटन स्वयं होस्ट के साथ संयुक्त काम है। Sandbox “भारी वर्चुअलाइज़ेशन उत्पाद” के बजाय “एक और ऐप” जैसा अनुभव इसलिए दे सकता है कि यह सहयोग है।

व्यावसायिक ऐप सत्यापित करने के लिए Sandbox उपयोग करने की ठोस प्रक्रिया पहले के “Windows Sandbox से ऐप सत्यापन कैसे तेज़ करें” में है। यह लेख उसके नीचे का तंत्र है।

5. कंटेनर — अलगाव रेखा कहाँ खींचें

5.1. प्रोसेस अलगाव और Hyper-V अलगाव

Windows कंटेनर के रन टाइम पर दो अलगाव मोड हैं। इमेज साझा है; शुरू करते समय फ़्लैग से चुनते हैं।⁷

प्रोसेस अलगाव: कई कंटेनर होस्ट के साथ कर्नेल साझा करते हैं और फ़ाइल सिस्टम, रजिस्ट्री, नेटवर्क पोर्ट, प्रोसेस-ID स्पेस, Object Manager नेमस्पेस आदि के प्रति-नेमस्पेस वर्चुअलाइज़ेशन से अलग होते हैं। मूलतः Linux कंटेनर जैसा ही दृष्टिकोण है।
Hyper-V अलगाव: हर कंटेनर अत्यधिक अनुकूलित VM के अंदर चलता है और प्रभाव में समर्पित कर्नेल रखता है। VM की उपस्थिति कंटेनर और होस्ट के बीच हार्डवेयर-स्तर अलगाव डालती है।⁷

नेमस्पेस से अलगाव को रजिस्ट्री वर्चुअलाइज़ेशन लेख में देखी तकनीक (“Windows पर Registry Redirection और Virtualization”) — “उसी API के नीचे अलग वास्तविकता दिखाना” — का पूर्ण संस्करण कहा जा सकता है।

flowchart TB
    accTitle: प्रोसेस अलगाव बनाम Hyper-V अलगाव
    accDescr: प्रोसेस अलगाव में कंटेनर होस्ट के साथ कर्नेल साझा करते और नेमस्पेस से अलग होते हैं; Hyper-V अलगाव में हर कंटेनर अनुकूलित VM के अंदर समर्पित कर्नेल रखता है
    subgraph pi ["प्रोसेस अलगाव"]
        c1["कंटेनर A"] --> sk1["होस्ट से साझा कर्नेल"]
        c2["कंटेनर B"] --> sk1
    end
    subgraph hi ["Hyper-V अलगाव"]
        c3["कंटेनर C"] --> k3["समर्पित कर्नेल（अनुकूलित VM में）"]
        c4["कंटेनर D"] --> k4["समर्पित कर्नेल（अनुकूलित VM में）"]
    end
    sk1 ~~~ c3

चित्र 11: एक ही कंटेनर इमेज पर भी, अलगाव रेखा कर्नेल के ऊपर खींचें या कर्नेल स्वयं बाँटें यह शुरू करते समय चुनाव है।

5.2. किसे “सुरक्षा सीमा” कह सकते हैं

इन दो मोड का अंतर केवल प्रदर्शन कहानी नहीं। Microsoft प्रोसेस-पृथक कंटेनर को मज़बूत सुरक्षा सीमा नहीं मानता। सुरक्षा सीमा के रूप में (भेद्यता प्रतिक्रिया सहित) बनाए रखे कंटेनर हाइपरवाइज़र-पृथक कंटेनर हैं, और विरोधी मल्टी-टेनेंट परिदृश्य में Hyper-V अलगाव चुनना चाहिए।⁸

भाग 2 में देखा VBS भी “कर्नेल टूट सकता है” मानकर हाइपरवाइज़र सीमा पर पीछे हटने वाला डिज़ाइन था। वही कसौटी कंटेनर की दुनिया में लागू होती है। अविश्वसनीय कोड सीमित करने वाली रेखा हाइपरवाइज़र सीमा पर खींची जाती है, साझा कर्नेल के अंदर नहीं।

flowchart TB
    accTitle: कोड पर कितना भरोसा उससे अलगाव कैसे चुनें
    accDescr: यदि वर्कलोड विश्वसनीय हो तो प्रोसेस अलगाव से घनत्व और प्रदर्शन लें; यदि कोड अविश्वसनीय या किसी और का हो तो Hyper-V पृथक कंटेनर, नेटवर्किंग बंद कठोर Windows Sandbox, या पृथक VM जैसी हाइपरवाइज़र सीमा चुनें
    trust{"उस कोड पर भरोसा कर सकते?"} -->|हाँ| dens["प्रोसेस अलगाव（घनत्व और गति पहले）"]
    trust -->|नहीं / किसी और का कोड| bound["हाइपरवाइज़र सीमा चुनें"]
    bound --> opt1["Hyper-V पृथक कंटेनर"]
    bound --> opt2["कठोर Sandbox या पृथक VM"]

चित्र 12: अलगाव मोड प्रदर्शन कहानी से पहले सुरक्षा कहानी है, और भरोसा तय करता है रेखा कहाँ खींचें।

प्रसंगवश, Hyper-V VM के अंदर Hyper-V पृथक कंटेनर चलाना हाइपरवाइज़र दो परत गहरा कर देता है — नेस्टेड वर्चुअलाइज़ेशन। शर्तें पूरी करने वाले वातावरण पर एक स्तर का नेस्टिंग उत्पादन में समर्थित है (Windows 10 / Windows Server 2016 या बाद के होस्ट वाला Intel प्रोसेसर, या Windows 11 / Windows Server 2022 या बाद के होस्ट वाला AMD प्रोसेसर, और प्रत्येक मामले में संगत VM कॉन्फ़िगरेशन संस्करण), और आगे की पूर्वापेक्षा बाहरी VM को वर्चुअलाइज़ेशन एक्सटेंशन दिखाने वाली सेटिंग है (Hyper-V में Set-VMProcessor पर ExposeVirtualizationExtensions)। VM के अंदर WSL2 चलाना उसी तरह समर्थित है।⁹ क्लाउड में विकास VM में WSL2 या Docker उपयोग कर सकते हैं या नहीं यह भी तय होता है कि वह VM आकार और कॉन्फ़िगरेशन नेस्टेड वर्चुअलाइज़ेशन दिखाता है या नहीं।

flowchart TB
    accTitle: नेस्टेड वर्चुअलाइज़ेशन की संरचना
    accDescr: क्लाउड VM भौतिक होस्ट के हाइपरवाइज़र पर बैठता है, और उसके अंदर दूसरा हाइपरवाइज़र（समर्थित नेस्टिंग एक स्तर）WSL2 और Hyper-V पृथक कंटेनर सहारा देने चलता है
    phys3["भौतिक होस्ट का हाइपरवाइज़र"] --> cvm["क्लाउड VM（डेव मशीन）"]
    cvm --> nhv["VM के अंदर हाइपरवाइज़र（नेस्टिंग स्तर 1）"]
    nhv --> w2["WSL2"]
    nhv --> hvc["Hyper-V पृथक कंटेनर"]
    nhv -.-> limit["समर्थित नेस्टिंग एक स्तर"]

चित्र 13: क्लाउड VM के अंदर wsl चलने का कारण यह है कि नेस्टेड वर्चुअलाइज़ेशन आधिकारिक रूप से केवल एक स्तर समर्थित है।

5.3. अलगाव और हल्केपन का स्पेक्ट्रम

अब तक के पात्रों को एक अक्ष पर लगाने पर ऐसा दिखता है।

flowchart TB
    accTitle: अलगाव मज़बूती और हल्केपन का स्पेक्ट्रम
    accDescr: प्रोसेस-पृथक कंटेनर सबसे हल्के पर कर्नेल साझा करते हैं; WSL2, Sandbox और Hyper-V पृथक कंटेनर समर्पित कर्नेल वाली हल्की VM हैं（Sandbox साझा कर हल्का, WSL2 उद्देश्य-निर्मित कर्नेल से）; पूर्ण VM सबसे भारी पर सामान्य-उद्देश्य
    ax["हल्का ← → भारी"] ~~~ p1
    p1["प्रोसेस-पृथक कंटेनर（साझा कर्नेल）"] --> p2["WSL2, Sandbox, Hyper-V अलगाव（समर्पित कर्नेल वाली हल्की VM）"]
    p2 --> p3["पूर्ण VM（कुछ भी चलाए; पूर्ण प्रति रखे）"]
    p1 -.-> n1["सीमा: नेमस्पेस"]
    p2 -.-> n2["सीमा: हाइपरवाइज़र"]
    p3 -.-> n3["सीमा: हाइपरवाइज़र + पूर्ण स्वतंत्रता"]

चित्र 14: हल्की-VM समूह वह मध्य समाधान है जिसने हाइपरवाइज़र सीमा रखी और द्विरावृत्ति काटी; काटने का तरीका Sandbox के लिए साझाकरण और WSL2 के लिए उद्देश्य-निर्मित कर्नेल में बँटता है।

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

हल्कापन और साझाकरण सामने की मशीन पर देखे जा सकते हैं।

प्रारंभ समय और मेमोरी का उठना-गिरना (WSL2)। Task Manager खुला रखकर निम्नलिखित आज़माएँ।

# Felt startup time (the first run starts the VM; the second and later are faster still)
Measure-Command { wsl -e true }

# Memory usage of the WSL2 VM (vmmem / Virtual Machine Memory)
Get-Process -Name vmmem* | Select-Object Name, WorkingSet64

# End the whole VM and watch the memory come back
wsl --shutdown

यदि WSL2 के अंदर बड़ा बिल्ड या फ़ाइल ऑपरेशन करें, vmmem बढ़ता है, और wsl --shutdown से एक साथ लौटते देखा जा सकता है।

फ़ाइलें कहाँ रखें से गति अंतर (WSL2)। वही रिपॉज़िटरी Linux पक्ष (~/repo) और Windows पक्ष (/mnt/c/repo) पर रखकर git status या निकालने का समय तुलना करें, तो धारा 3.2 का अंतर संख्याओं में दिखता है।

डायरेक्ट मैप की पृष्ठभूमि (Sandbox)। Sandbox शुरू करें और होस्ट पर Task Manager में मेमोरी की वृद्धि देखें। वृद्धि “दूसरे Windows” की कल्पना से बहुत छोटी रहना साझाकरण का प्रभाव अपनी कहानी कहता है। होस्ट-पक्ष मेमोरी विघटन और गहराई से देखने के लिए, RAMMap और VMMap उपयोग कवर करने वाला Sysinternals उपकरणों वाला लेख (“Process Explorer / Handle / VMMap व्यवहार में”) उपयोगी है। पर ये होस्ट-पक्ष प्रोसेस और भौतिक मेमोरी के वर्गीकरण देखने के उपकरण हैं; गेस्ट के साथ साझाकरण स्वयं सीधे नहीं देखते।

कंटेनर अलगाव मोड (Docker / Windows कंटेनर)। यदि Windows कंटेनर वातावरण हो, वही इमेज docker run --isolation=process और --isolation=hyperv से शुरू कर प्रारंभ समय और Task Manager में दिखना तुलना करें (प्रोसेस अलगाव में कंटेनर के अंदर प्रोसेस होस्ट की प्रोसेस सूची में आते हैं), तो अलगाव रेखा कहाँ बैठती है महसूस कर सकते हैं।⁷ पर प्रोसेस अलगाव यह पूर्वापेक्षा रखता है कि होस्ट और इमेज संस्करण मेल खाएँ, और क्लाइंट OS पर विकास तथा परीक्षण उपयोग तक सीमित है। Hyper-V अलगाव व्यापक संयोजन अनुमति देता है, इसलिए तुलना संगत जोड़ी पर करें।¹⁰

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

7.1. “WSL2 धीमा है”

जो धीमा है वह WSL2 नहीं बल्कि OS सीमा पार करने वाला फ़ाइल-I/O पथ है। कई मामले हैं जहाँ प्रोजेक्ट Linux पक्ष पर ले जाना अनुभव अलग चीज़ बना देता है।⁴ इसके विपरीत, Windows उपकरण छूएँगे फ़ाइलें Linux पक्ष पर रखना उसी कारण समान रूप से प्रतिकूल है। “उपयोग करने वाले पक्ष वाले उसी OS पर रखें” से आँकें।

7.2. “vmmem बड़ा होना मेमोरी लीक है”

WSL2 मेमोरी माँग के साथ बढ़ती-सिकुड़ती है, और छोड़े भाग लौटते हैं। वर्तमान WSL पर फ़ाइल कैश भी autoMemoryReclaim (डिफ़ॉल्ट dropCache) से स्वतः पुनः प्राप्त होता है, इसलिए “बड़ा रह गया” अक्सर समय के साथ हल होता है।⁵ यदि फिर भी रहे, पुष्टि करें कि autoMemoryReclaim disabled सेट नहीं, और छोड़े भाग लौटाने वाला pageReporting बंद नहीं (या पुराने WSL पर नहीं), फिर या तो .wslconfig में memory से ऊपरी सीमा स्पष्ट करें या सत्र सीमा पर wsl --shutdown से सब लौटाएँ। लीक और गैर-लीक अलग करने का सोचने का तरीका मेमोरी श्रृंखला की परिचयात्मक किस्त, “Windows का "मेमोरी उपयोग" वास्तव में क्या है?” जैसा ही है।

7.3. “कंटेनर में है, इसलिए सुरक्षित है”

प्रोसेस-पृथक कंटेनर कर्नेल साझा करता है, और Microsoft की कसौटी पर सुरक्षा सीमा नहीं।⁸ अविश्वसनीय कोड या नमूना चलाने के लिए Hyper-V पृथक कंटेनर, Windows Sandbox, या समर्पित VM जैसी हाइपरवाइज़र सीमा वाला अलगाव चुनें। पर हाइपरवाइज़र सीमा कंबल छूट नहीं। Windows Sandbox की डिफ़ॉल्ट सेटिंग में नेटवर्क कनेक्टिविटी सक्षम है, और अविश्वसनीय ऐप को आंतरिक नेटवर्क दिखा सकती है।¹ यदि नमूना चलाने उपयोग करें, .wsb कॉन्फ़िगरेशन फ़ाइल में नेटवर्क और क्लिपबोर्ड रीडायरेक्शन अक्षम कर अलगाव मज़बूत करें, या पृथक नेटवर्क पर समर्पित VM उपयोग करें।

8. सारांश — श्रृंखला बंद करना

भाग 3 के बिंदु।

हल्की VM का हल्कापन “द्विरावृत्ति रोकने” का परिणाम है, “अलगाव कमज़ोर करने” का नहीं।
WSL2 प्रबंधित हल्के यूटिलिटी VM में वास्तविक Linux कर्नेल चलाता है, और वितरण उस VM के अंदर कंटेनर के रूप में अलग होते हैं।³ प्रदर्शन नियम फ़ाइलें उपयोग करने वाले OS पर रखना है, और मेमोरी गतिशील बढ़ती-सिकुड़ती है, ऊपरी सीमा .wslconfig में नियंत्रण योग्य।⁴⁵
Windows Sandbox डायनामिक बेस इमेज से होस्ट की अपरिवर्तनीय OS फ़ाइलें साझा करता है और डायरेक्ट मैप से लक्षित OS बाइनरी के भौतिक पेज भी साझा करता है, इसलिए पूर्ण Windows की प्रति नहीं रखता।² परिवर्तनीय फ़ाइलों के लिए अभी भी लगभग 500 MB चाहिए, साथ उसके अंदर चलाए ऐप की मेमोरी।
कंटेनर अलगाव मोड शुरू करते समय चुना जाता है, और सुरक्षा सीमा कह सकने वाला पक्ष Hyper-V अलगाव है।⁷⁸

और यदि पूरी श्रृंखला एक पन्ने पर रखें, तो ऐसा दिखता है।

भाग 1: Windows के नीचे हाइपरवाइज़र परत है, और होस्ट OS स्वयं रूट पार्टीशन के रूप में चलता है। CPU और मेमोरी (SLAT) की मध्यस्थता यह परत सीधे करती है, और सिंथेटिक डिवाइस का I/O VMBus के पार रूट पार्टीशन (VSP) मध्यस्थता करता है।
भाग 2: वह परत न केवल VM एक-दूसरे से अलग करने, बल्कि उसी OS के अंदर कर्नेल से मज़बूत सीमा (VTL) खींचने के लिए भी उपयोग होती है। Windows 11 की डिफ़ॉल्ट सुरक्षा इसी पर बनी है।
भाग 3: उसी परत पर, द्विरावृत्ति काटना “सेकंडों में शुरू होने वाली वर्चुअल मशीन” संभव बनाता है। अलगाव रेखा रखी गई, और यह रोज़ का उपकरण बन गया है।

flowchart TB
    accTitle: पूरी श्रृंखला का एक चित्र
    accDescr: हार्डवेयर पर सीधा हाइपरवाइज़र भाग 1 है; होस्ट Windows के अंदर VTL0 और VTL1 का विभाजन भाग 2 है; उसी परत पर WSL2, Sandbox और Hyper-V अलगाव का हल्कापन भाग 3 है; प्रोसेस-पृथक कंटेनर होस्ट कर्नेल साझा करते हैं; Sandbox साझा कर हल्का, WSL2 उद्देश्य-निर्मित कर्नेल से
    hw3["हार्डवेयर"] --> hv3["हाइपरवाइज़र（भाग 1）"]
    hv3 --> rp3["होस्ट Windows（VTL अलगाव भाग 2）"]
    hv3 --> lw3["WSL2, Sandbox, Hyper-V अलगाव（भाग 3）"]
    rp3 --> pc3["प्रोसेस-पृथक कंटेनर（साझा कर्नेल）"]
    lw3 -.-> mech3["Sandbox साझा करता; WSL2 उद्देश्य-निर्मित कर्नेल से हल्का"]

चित्र 15: तीन किस्तें रखें तो वर्तमान Windows के नीचे की ज़मीन का समग्र चित्र मिलता है।

वर्चुअलाइज़ेशन अब सर्वर-कक्ष तकनीक नहीं, न केवल VM खड़े करने वालों की तकनीक। आपके Windows के नीचे की ज़मीन पर, यह चुपचाप सुरक्षा और विकास अनुभव दोनों सहारा देती है — हम अभी वहीं हैं।

संदर्भ लिंक

Microsoft Learn, Windows Sandbox. Windows Sandbox के डिस्पोजेबल VM के रूप में कुछ सेकंड में शुरू होकर बंद करने पर सब त्यागने पर; Microsoft हाइपरवाइज़र से अलग कर्नेल चलाकर होस्ट से अलग करने पर; और नेटवर्क कनेक्टिविटी के डिफ़ॉल्ट से सक्षम तथा कॉन्फ़िगरेशन फ़ाइल में अक्षम किए जा सकने पर। ↩ ↩² ↩³
Microsoft Learn, Windows Sandbox architecture. डायनामिक बेस इमेज के होस्ट की अपरिवर्तनीय OS फ़ाइलों के साझा और परिवर्तनीय फ़ाइलों की साफ़ प्रति से पूर्ण Windows इमेज जोड़ने पर (इंस्टॉल के बाद लगभग 500 MB); पारंपरिक VM के स्थिर मेमोरी आवंटन के विरुद्ध कंटेनर के होस्ट सहयोग से गतिशील आवंटन पर, जिससे होस्ट मेमोरी पुनः प्राप्त कर सकता है; और डायरेक्ट मैप के ntdll.dll जैसी OS बाइनरी को होस्ट जैसे ही भौतिक पेज उपयोग कराने पर। ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Microsoft Learn, What is the Windows Subsystem for Linux?. WSL2 के हल्के यूटिलिटी VM के अंदर Linux कर्नेल चलाने पर; हर वितरण के पृथक कंटेनर के रूप में चलने, नेटवर्क नेमस्पेस और कर्नेल साझा करते हुए PID, माउंट और यूज़र जैसे नेमस्पेस अलग करने पर। ↩ ↩² ↩³
Microsoft Learn, Comparing WSL Versions. WSL2 कर्नेल के Microsoft द्वारा Stable शाखा से बनाए जाने पर; Store-वितरित WSL के OS इमेज से अलग पैकेज के रूप में अद्यतन पाकर wsl --update से लागू करने पर (पुराने इन-बॉक्स वितरण पर Windows Update से); टारबॉल निकालने में 20 गुना तक जैसे प्रदर्शन उदाहरणों पर; क्रॉस-OS फ़ाइल-सिस्टम प्रदर्शन में WSL1 तेज़ होने पर, इसलिए फ़ाइलें उपयोग करने वाले OS पर रखने पर; और मेमोरी के छोड़े भाग लौटाते बढ़ने-सिकुड़ने, जबकि कैश VM निकलने तक न लौट सकने पर। ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
Microsoft Learn, Advanced settings configuration in WSL. .wslconfig के [wsl2] खंड में WSL2 VM की समग्र मेमोरी छत, प्रोसेसर संख्या, स्वैप और pageReporting (डिफ़ॉल्ट से सक्षम; अप्रयुक्त मेमोरी पता कर लौटाने का ज़िम्मेदार) सेट कर सकने पर; और प्रयोगात्मक सेटिंग autoMemoryReclaim के डिफ़ॉल्ट dropCache होने पर, जिससे कैश मेमोरी स्वतः पुनः प्राप्त होती है। ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, Use and configure Windows Sandbox. .wsb कॉन्फ़िगरेशन फ़ाइल में MappedFolders के होस्ट फ़ोल्डर केवल-पढ़ने या लेखन योग्य साझा कर सकने पर। ↩
Microsoft Learn, Isolation Modes. Windows कंटेनर के प्रोसेस अलगाव के होस्ट के साथ कर्नेल साझा कर नेमस्पेस से अलग होने पर; Hyper-V अलगाव के अनुकूलित VM के अंदर प्रभाव में समर्पित कर्नेल रखने पर; और शुरू करते समय फ़्लैग से एक ही इमेज किसी भी मोड में चला सकने पर। ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Secure Windows containers. केवल हाइपरवाइज़र-पृथक कंटेनर के सुरक्षा सीमा माने जाने पर; प्रोसेस-पृथक कंटेनर के मज़बूत सुरक्षा सीमा न माने जाने पर; और विरोधी मल्टी-टेनेंट परिदृश्य में हाइपरवाइज़र अलगाव चुनने पर। ↩ ↩² ↩³
Microsoft Learn, What is Nested Virtualization?. Hyper-V VM के अंदर Hyper-V पृथक कंटेनर चलाने (एक स्तर नेस्टिंग) के उत्पादन में समर्थित होने पर; आवश्यकताएँ Intel प्रोसेसर के साथ Windows Server 2016 / Windows 10 या बाद, या AMD प्रोसेसर के साथ Windows Server 2022 / Windows 11 या बाद, तथा प्रत्येक मामले में संगत VM कॉन्फ़िगरेशन संस्करण होने पर; बाहरी VM को वर्चुअलाइज़ेशन एक्सटेंशन दिखाने (ExposeVirtualizationExtensions) पूर्वापेक्षा होने पर; और Hyper-V VM के अंदर WSL2 चलाने के समर्थित होने पर। ↩
Microsoft Learn, Windows container version compatibility. प्रोसेस अलगाव के होस्ट और कंटेनर इमेज संस्करण मेल मानने पर; Hyper-V अलगाव के होस्ट से अलग OS संस्करण की इमेज चला सकने पर; और क्लाइंट OS पर प्रोसेस अलगाव के विकास तथा परीक्षण उपयोग तक सीमित होने पर। ↩

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

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

जब आप Hyper-V सक्षम करते हैं, तो होस्ट Windows स्वयं रूट पार्टीशन के रूप में हाइपरवाइज़र के ऊपर चलता है। यह लेख VT-x, SLAT और VMBus की भू...

लेख पढ़ें

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 ऐप विकास

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

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

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

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

क्या WSL2 एक VM है?: हाँ। WSL2 Microsoft द्वारा बनाए गए वास्तविक Linux कर्नेल को हल्के यूटिलिटी VM के अंदर चलाता है। VM को WSL पर्दे के पीछे प्रबंधित करता है, इसलिए डिज़ाइन उपयोगकर्ता को VM सेटिंग या बूट की प्रतीक्षा सोचने नहीं देता। हर Linux वितरण इस प्रबंधित VM के अंदर पृथक कंटेनर के रूप में चलता है।
WSL2 में /mnt/c के अंतर्गत फ़ाइल ऑपरेशन धीमे क्यों हैं?: क्योंकि WSL2 Linux कर्नेल से Windows-पक्ष फ़ाइल सिस्टम तक पहुँच OS सीमा पार करने वाली फ़ाइल शेयरिंग से जाती है। Linux फ़ाइल सिस्टम (ext4 वर्चुअल डिस्क) पर ऑपरेशन तेज़ हैं, इसलिए नियम है प्रोजेक्ट फ़ाइलें उन उपकरणों वाले उसी OS पक्ष पर रखें जो उन पर काम करते हैं।
क्या vmmem प्रोसेस का बड़ा मेमोरी उपयोग लीक है?: अधिकांश मामलों में लीक नहीं। WSL2 मेमोरी उपयोग के साथ बढ़ती-सिकुड़ती है, और प्रोसेस ने जो मेमोरी छोड़ी वह pageReporting सेटिंग के अधीन Windows को लौटाई जाती है, जो डिफ़ॉल्ट से सक्षम है। फ़ाइल-कैश पेज भी वर्तमान WSL .wslconfig में autoMemoryReclaim से स्वतः पुनः प्राप्त करता है (डिफ़ॉल्ट dropCache है)। जिन वातावरणों में ये सेटिंग अक्षम हैं, या पुराने WSL पर, मेमोरी VM निकलने तक रह सकती है; उस स्थिति में memory सेटिंग से ऊपरी सीमा सेट करें, या wsl --shutdown से लौटाएँ।
Windows Sandbox कुछ सौ मेगाबाइट डिस्क से पूर्ण Windows कैसे बूट कर सकता है?: डायनामिक बेस इमेज नामक तंत्र से। यह होस्ट पर पहले से इंस्टॉल Windows से अपरिवर्तनीय OS फ़ाइलें साझा करता है, और केवल थोड़ी संख्या में परिवर्तनीय फ़ाइलों की साफ़ प्रति रखता है। इससे Windows की पूर्ण प्रति संग्रहीत किए बिना पूर्ण, बूट योग्य इमेज जोड़ी जा सकती है।
क्या कंटेनर VM से अधिक सुरक्षित हैं?: यह अलगाव मोड पर निर्भर करता है। प्रोसेस-पृथक कंटेनर होस्ट के साथ कर्नेल साझा करते हैं, और Microsoft इसे मज़बूत सुरक्षा सीमा नहीं मानता। विरोधी कोड सँभालते समय Hyper-V अलगाव चाहिए, जो हर कंटेनर को अपना समर्पित कर्नेल देता है।

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

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

Go Komura

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

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

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

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

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

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

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

2. पूर्ण VM क्या ढो रहा है

3. WSL2 — उद्देश्य-निर्मित कर्नेल वाला यूटिलिटी VM

3.1. संरचना: प्रबंधित VM और उसके अंदर वितरण

3.2. फ़ाइल I/O: किस पक्ष पर रखें इससे अलग चीज़ बन जाती है

3.3. मेमोरी: बढ़ती है, सिकुड़ती है, पर सब कुछ हमेशा नहीं लौटाती

4. Windows Sandbox — होस्ट के Windows का पुनः उपयोग

4.1. डायनामिक बेस इमेज: 500 MB में पूर्ण Windows

4.2. डायरेक्ट मैप: वही ntdll.dll वही भौतिक पेज है

4.3. मेमोरी उधार-देन: VM से अधिक प्रोसेस जैसा

5. कंटेनर — अलगाव रेखा कहाँ खींचें

5.1. प्रोसेस अलगाव और Hyper-V अलगाव

5.2. किसे “सुरक्षा सीमा” कह सकते हैं

5.3. अलगाव और हल्केपन का स्पेक्ट्रम

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

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

7.1. “WSL2 धीमा है”

7.2. “vmmem बड़ा होना मेमोरी लीक है”

7.3. “कंटेनर में है, इसलिए सुरक्षित है”

8. सारांश — श्रृंखला बंद करना

संबंधित लेख

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

संदर्भ लिंक

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

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

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

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

संबंधित विषय

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

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

Windows ऐप विकास

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

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

Go Komura