Windows Virtualization Internals (भाग 3) — सेकंडों में boot होने वाली VMs: WSL2, Windows Sandbox और containers इतने हल्के क्यों हैं

Go Komura

doi:10.5281/zenodo.22176905

Windows Virtualization Internals (भाग 3) — सेकंडों में boot होने वाली VMs: WSL2, Windows Sandbox और containers इतने हल्के क्यों हैं

22 Aug 2026 04:00 · अद्यतन तिथि: 28 Aug 2026 · Go Komura · Windows, Virtualization, WSL2, Windows Sandbox, Containers, Hyper-V

संशोधन इतिहास (पहला संस्करण, 22 Aug 2026 को प्रकाशित)

22 Aug 2026: पहला प्रकाशन

इस लेख का हवाला दें(DOI: 10.5281/zenodo.22176905)

यह लेख Zenodo पर संग्रहीत है। नीचे वह DOI है जो हमेशा नवीनतम संस्करण की ओर ले जाता है, और वह DOI भी जो आपके पढ़े जा रहे संस्करण से बँधा है।

Go Komura (2026). Windows Virtualization Internals (भाग 3) — सेकंडों में boot होने वाली VMs: WSL2, Windows Sandbox और containers इतने हल्के क्यों हैं. KomuraSoft LLC. https://doi.org/10.5281/zenodo.22176905 https://comcomponent.com/hi/blog/windows-virtualization-internals-wsl2-sandbox-containers/

DOI (नवीनतम संस्करण): 10.5281/zenodo.22176905
DOI (यह संस्करण): 10.5281/zenodo.22176906

Hyper-V Manager में Windows VM बनाएँ तो start होने में दसियों सेकंड लगते हैं और कई gigabytes memory exclusive control में लेता है। पर उसी PC पर wsl टाइप करने से कुछ सेकंड में Linux shell लौटता है, और Windows Sandbox भी कुछ सेकंड में disposable desktop खोलता है।¹

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

Series की अंतिम किस्त जो सवाल हल करती है वह केवल एक है।

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

Target readers वे developers और operators हैं जो development और validation के लिए WSL2, Windows Sandbox और Windows containers उपयोग करते हैं, और उनका हल्कापन तथा constraints mechanism से समझना चाहते हैं। Prerequisites हैं Windows 10/11; Windows Sandbox section चलाने के लिए Pro, Enterprise या Education edition चाहिए (Home और Windows Server में यह feature नहीं)। Background knowledge भाग 1 की partition concept है। Difficulty intermediate है।

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

Lightweight VM isolation रेखा (dedicated kernel और hypervisor boundary) रखती है और “full guest OS copy” हल्की करती है। Sandbox host के Windows स्वयं share करता है; WSL2 guest को छोटे, purpose-built Linux से बदलता है; और दोनों मामलों में memory static reservation नहीं बल्कि host के साथ dynamic memory sharing है।

Full VM के भार का स्रोत isolation स्वयं नहीं बल्कि duplication / कॉपी है। Disk पर एक और OS image, RAM में एक और OS जितने pages, और हर start पर एक और full boot। Lightweight VM वह duplication / कॉपी दो policies से काटती हैं: “जो share करना सुरक्षित हो उसे share करें” (Sandbox) और “यदि share न कर सकें, तो छोटा बनाकर rebuild करें” (WSL2)।

flowchart TB
    accTitle: Lightweight VM सहारा देने वाले तीन प्रकार के sharing
    accDescr: Full VM जो OS image duplicate करता था उसे Sandbox share कर और WSL2 shrink कर काटता है; default static allocation वाली memory（Dynamic Memory exception）host के साथ dynamic memory sharing बनती है; start हल्के kernel और minimal setup से बदलता है; केवल isolation boundary रहती है
    heavy["full VM: duplication / कॉपी"] --> d1["disk: OS image copy"]
    heavy --> more{"memory या start?"}
    more --> d2["memory: static default"]
    more --> d3["start: full boot"]
    d1 -->|बदलता| s1["share（Sandbox）"]
    s1 -.-> s1b["या shrink（WSL2）"]
    d2 -->|बदलता| s2["dynamic memory sharing"]
    d3 -->|बदलता| s3["हल्का kernel + न्यून."]

चित्र 1: “वही hypervisor, फिर भी हल्का” के उत्तर का skeleton यह है कि उन्होंने duplication / कॉपी रोकी, isolation नहीं।

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

2. Full VM क्या ढो रहा है

तुलना की baseline के रूप में, traditional VM क्या ढोता है।

Independent OS image। Guest OS की हर file virtual disk के अंदर रखता है। Host पर वही Windows हो तो भी share नहीं करता।
मोटा memory allocation। Traditional VM का default host memory static size पर allocate करना है। Hyper-V Dynamic Memory जैसे mechanism configured limit के भीतर allocation बढ़ा-घटा सकते हैं, पर demand बदलने के adjustment के साधन सीमित हैं।²
General-purpose full boot। Firmware, boot loader, और services का set physical machine जैसी ही क्रम में start होता है।

flowchart TB
    accTitle: Full VM के तीन भार
    accDescr: Full VM independent OS image, default static memory allocation, और general-purpose full boot ढोता है, और वे disk, RAM तथा start time में cost बनते हैं
    fullvm["full VM"] --> b1["independent OS image"]
    fullvm --> more{"memory या boot?"}
    more --> b2["static memory default"]
    more --> b3["general-purpose boot"]
    b1 -.-> c1["copy के लिए extra disk"]
    b2 -.-> c2["unused RAM भी रखता"]
    b3 -.-> c3["दसियों सेकंड लगते"]

चित्र 2: Full VM की cost का breakdown isolation के लिए नहीं बल्कि generality और duplication / कॉपी के लिए चुकाया जाता है।

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

3. WSL2 — purpose-built kernel वाला utility VM

3.1. Structure: managed VM और उसके अंदर distributions

WSL2 वह mechanism है जो lightweight utility VM के अंदर actual Linux kernel चलाता है।³ तीन बिंदु हैं।

Kernel actual है, पर specific product है। यह Stable शाखा से Microsoft द्वारा बनाया Linux kernel है, size और performance में पहले से WSL2 के लिए tune। Current standard, Microsoft Store–distributed WSL पर, kernel WSL package के साथ update होता है और wsl --update से apply होता है (पुराने in-box distribution पर Windows Update से आता था)।⁴ क्योंकि kernel actual है, system-call compatibility पूर्ण है, और Docker जैसे tools ज्यों के त्यों चलते हैं।
VM पर्दे के पीछे है। VM बनाना, start करना और रोकना WSL manage करता है; user बस shell खोलता है। VM-settings screen नहीं और boot की प्रतीक्षा महसूस नहीं।⁴
Distribution VM के अंदर container है। Ubuntu और Debian जैसे distributions एक managed VM के अंदर isolated container के रूप में चलते हैं। वे network namespace और kernel share करते हैं, जबकि PID, mount और user जैसे namespaces अलग हैं।³

flowchart TB
    accTitle: WSL2 architecture
    accDescr: Host Windows और lightweight utility VM hypervisor पर साथ बैठते हैं; Microsoft-built Linux kernel VM के अंदर चलता है; और हर distribution उसके अंदर isolated container के रूप में चलता है
    hv["hypervisor"] --> host["host Windows"]
    hv --> uvm["lightweight utility VM"]
    uvm --> lk["Linux kernel（Microsoft build; wsl --update）"]
    lk --> u1["Ubuntu（container）"]
    lk --> u2["Debian（container）"]
    host <-->|"Interop（commands, files, network）"| uvm

चित्र 3: “क्या WSL2 VM है?” का उत्तर “हाँ, पर managed, पर्दे-के-पीछे VM” है, और कई distributions install करने पर भी VM एक ही रहता है।

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

flowchart TB
    accTitle: wsl command चलाने से कुछ सेकंड में shell लौटने तक
    accDescr: wsl चलाने पर यदि utility VM नहीं चल रहा हो तो lightweight VM और Linux kernel start होते हैं; यदि पहले से चल रहा हो तो reuse; और distribution के container में shell लौटता है
    cmd["wsl चलाएँ"] --> vmq{"utility VM पहले से चल रहा?"}
    vmq -->|नहीं| bootvm["lightweight VM और Linux kernel start（कुछ सेकंड）"]
    vmq -->|हाँ| reuse["पहले से चलते VM का reuse"]
    bootvm --> shell["container के अंदर shell लौटता"]
    reuse --> shell

चित्र 4: प्रतीक्षा केवल minimal VM start है, और यहीं full boot का सामान उतारना दिखता है।

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

WSL2 performance की बात में हमेशा आने वाला विषय यह है कि files कहाँ रखें।

Linux पक्ष की files (ext4 virtual disk) पर operations तेज़ हैं। क्योंकि Linux kernel अपने file system से सीधे बात करता है, और WSL1 की तुलना में tarball निकालने में 20 गुना तक, तथा git clone और npm install में 2–5 गुना तेजी के उदाहरण बताए गए हैं।⁴
Windows पक्ष की files (/mnt/c आदि) पर operations धीमे हो जाते हैं क्योंकि वे OS boundary पार करने वाली file sharing से जाते हैं। Cross-OS file-system performance वह एक बड़ा item है जहाँ WSL2 WSL1 से खराब है।⁴

इसलिए नियम है: “Project files उन tools वाले उसी OS पक्ष पर रखें जो उन पर काम करते हैं”।⁴ Linux build tools से सँभाला repository Linux पक्ष पर जाता है; Visual Studio में build किया solution Windows पक्ष पर।

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

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

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

WSL2 का memory usage (Task Manager में vmmem process के रूप में दिखता है) static reservation नहीं; usage के साथ बढ़ता-सिकुड़ता है। Process ने जो memory छोड़ी वह pageReporting setting के अधीन automatically Windows को लौटाई जाती है, जो default से enable है।⁵ File cache के रूप में रखे pages पहले VM निकलने तक Windows को नहीं लौटते थे।⁴ Current WSL में, experimental .wslconfig setting autoMemoryReclaim (default dropCache) cache भी automatically reclaim करती है।⁵ जिन environments में यह setting disabled है, या पुराने WSL पर, लंबे session का cache VM निकलने तक रह सकता है और host memory पर दबाव डाल सकता है।

flowchart TB
    accTitle: WSL2 memory कैसे बढ़ती, सिकुड़ती और लौटती है
    accDescr: WSL2 के अंदर demand बढ़ने से VM का memory usage बढ़ता है; process-released pages default-enable pageReporting से Windows को लौटते हैं; file cache default पर autoMemoryReclaim automatically reclaim करता है; पर disabled setting या पुराने WSL पर VM निकलने तक रहता है, और wsl --shutdown सब लौटाता है
    grow["WSL2 के अंदर memory demand बढ़ती"] --> vm["vmmem usage बढ़ता"]
    vm --> freed{"वह page छोड़ा गया?"}
    freed -->|"process ने छोड़ा（pageReporting ऑन）"| ret["automatically Windows को लौटा"]
    freed -->|file cache के रूप में| amr["autoMemoryReclaim automatically reclaim（default）"]
    amr -.-> old2["disabled setting या पुराने WSL पर VM निकलने तक"]
    old2 --> sd["wsl --shutdown सब लौटाता"]

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

यदि स्पष्ट upper limit चाहिए, %UserProfile%\.wslconfig VM की समग्र memory, CPU संख्या और swap control कर सकता है।⁵

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

Setting बदलने के बाद प्रभावी होने के लिए wsl --shutdown से VM पुनः start करें। यह dynamic allocation — “upper limit setting है, actual usage demand का अनुसरण करता है” — अगले विषय Windows Sandbox में और आगे जाता है।

4. Windows Sandbox — host के Windows का reuse

4.1. Dynamic base image: 500 MB में पूर्ण Windows

Windows Sandbox hypervisor से isolated disposable Windows desktop है। बंद करें तो सब गायब; अगली बार clean state से कुछ सेकंड में start होता है।¹

पहली पहेली disk है। पूर्ण Windows boot कर सकता है, फिर भी install के बाद Sandbox की base image केवल लगभग 500 MB है, और distribution time compressed 30 MB।² रहस्य dynamic base image है।

अधिकांश OS files immutable हैं, इसलिए host की copies ज्यों की त्यों share हो सकती हैं।
थोड़ी संख्या में mutable files share नहीं हो सकतीं, इसलिए उनकी clean copy base image के अंदर रखी जाती है।
Start पर, host की immutable files और mutable files की local copies मिलाकर पूर्ण Windows image जोड़ी जाती है।²

अर्थात्, Sandbox Windows की copy न download करता है न store; वह host पर पहले से install Windows का reuse कर start होता है।

flowchart TB
    accTitle: Dynamic base image कैसे जोड़ी जाती है
    accDescr: Host Windows से immutable OS files share होती हैं; केवल mutable files base image में clean copy के रूप में रखी जाती हैं; और दोनों मिलाकर Sandbox की पूर्ण Windows image बनती है
    hostw["host का पूर्ण Windows"] --> imm["immutable OS files（अधिकांश）"]
    hostw --> mut["mutable OS files（अल्पसंख्यक）"]
    imm -->|ज्यों की त्यों share| img["Sandbox boot image"]
    mut -->|clean copy रखें| img
    img --> boot["पूर्ण Windows के रूप में boot"]
    img -.-> size["केवल लगभग 500 MB store"]

चित्र 7: Disk duplication / कॉपी छोड़ने का रूप “दूसरा Windows रखना” नहीं बल्कि “host के Windows से जोड़ना” है।

वह combination निम्नलिखित lifecycle संभव बनाता है। जो त्यागा जाता है वह Sandbox के अंदर local state है। यदि .wsb configuration file में host से writable folder map किया हो, वहाँ के changes host पर रहते हैं।⁶

flowchart TB
    accTitle: Windows Sandbox lifecycle
    accDescr: Start करना कुछ सेकंड में clean Windows तैयार करता है; app validation या प्रयोग के बाद बंद करें तो Sandbox के अंदर सारी state त्यागी जाती है इसलिए अगली बार भी clean start; पर writable mapped host folders के changes रहते हैं
    launch["start（कुछ सेकंड）"] --> clean["clean Windows"]
    clean --> work["app validation या प्रयोग"]
    work --> close2["बंद करें"]
    close2 --> discard["Sandbox के अंदर सारी state त्यागें"]
    discard -.-> mapped["mapped writable folders के changes host पर रहते"]
    discard -->|अगला start| launch

चित्र 8: हर बार clean लौट सकना इसलिए है कि mutable भाग disposable copy है, और उसे त्यागना design का भाग है।

4.2. Direct map: वही ntdll.dll वही physical page है

न केवल disk बल्कि RAM भी share होती है। क्योंकि Sandbox host जैसी ही OS image चलाता है, “direct map” नामक technique उपयोग होती है ताकि OS binaries के लिए host जैसी ही physical memory pages उपयोग करे। जब ntdll.dll Sandbox के अंदर memory में load होता है, वह host पर पहले से load उसी binary के उसी physical page की ओर इंगित करता है। Host के secrets खतरे में डाले बिना, traditional VM से बहुत छोटा memory footprint पाता है।²

“एक ही physical page कई users में share करें” — वही विचार है जो memory series के भाग 3 में अनुसरण किए section objects से DLL sharing का (“Section Object और Copy-on-Write”)। वह mechanism processes के बीच sharing था; Sandbox इसे VM boundary पार करता है।

flowchart TB
    accTitle: Direct map से physical-page sharing
    accDescr: Host का app और Sandbox के अंदर app ntdll जैसी OS binaries के लिए एक ही physical memory page share करते हैं, जिससे memory usage घटता है
    happ["host का app"] --> hva["host-पक्ष virtual address"]
    sapp["Sandbox के अंदर app"] --> sva["Sandbox-पक्ष virtual address"]
    hva --> phys["वही physical page（ntdll.dll जैसी OS binaries）"]
    sva --> phys
    phys -.-> save["OS जितनी RAM duplicate नहीं"]

चित्र 9: Direct map processes के बीच उपयोग हुआ page-sharing विचार है, VM boundary पार apply।

Traditional VM के static memory allocation के विरुद्ध, Sandbox जिस container technique पर बैठता है resource allocation host के सहयोग से dynamically तय करता है। यदि host memory कम पड़े, वह container से memory उसी तरह reclaim कर सकता है जैसे ordinary process से।² Hyper-V Dynamic Memory भी VM का allocation configured limit के भीतर बढ़ा-घटाता है, पर Sandbox आगे जाता है: अंतर यह है कि वह host के memory management के उसी मैदान पर dynamic memory sharing करता है।

flowchart TB
    accTitle: Host और Sandbox के बीच memory सहयोग
    accDescr: Traditional VM का default सीमित adjustment साधन वाला static-size exclusive allocation है; Sandbox host memory pressure के उत्तर में reclaim target बनता है और ordinary process जैसे उसी मैदान पर dynamic memory sharing करता है
    pressure["host memory pressure बढ़ता"] --> from{"कहाँ से reclaim करें?"}
    from --> proc["ordinary process के Working Set"]
    from --> sbx["Sandbox（container）का usage"]
    proc --> relief["खाली memory सुरक्षित"]
    sbx --> relief
    relief -.-> contrast["traditional VM के adjustment साधन सीमित"]

चित्र 10: Dynamic memory sharing में Sandbox VM पक्ष के बजाय process पक्ष पर खड़ा है, और host संकट में memory पेश करता है।

भाग 1 में हमने कहा “VM का performance host पक्ष पर भी निर्भर करता है”, पर lightweight VM से एक कदम और: memory का allocation स्वयं host के साथ संयुक्त काम है। Sandbox “भारी virtualization product” के बजाय “एक और app” जैसा अनुभव इसलिए दे सकता है कि यह सहयोग है।

Business apps validate करने के लिए Sandbox उपयोग करने की ठोस प्रक्रिया पहले के “Windows Sandbox से app validation कैसे तेज़ करें” में है। यह लेख उसके नीचे का mechanism है।

5. Containers — isolation रेखा कहाँ खींचें

5.1. Process isolation और Hyper-V isolation

Windows containers के runtime पर दो isolation modes हैं। Image shared है; start करते समय flag से चुनते हैं।⁷

Process isolation: कई containers host के साथ kernel share करते हैं और file system, registry, network ports, process-ID space, Object Manager namespace आदि के per-namespace virtualization से अलग होते हैं। मूलतः Linux containers जैसा ही दृष्टिकोण है।
Hyper-V isolation: हर container अत्यधिक optimized VM के अंदर चलता है और प्रभाव में dedicated kernel रखता है। VM की उपस्थिति container और host के बीच hardware-level isolation डालती है।⁷

Namespace से isolation को registry virtualization लेख में देखी technique (“Windows पर Registry Redirection और Virtualization”) — “उसी API के नीचे अलग वास्तविकता दिखाना” — का पूर्ण संस्करण कहा जा सकता है।

flowchart TB
    accTitle: Process isolation बनाम Hyper-V isolation
    accDescr: Process isolation में containers host के साथ kernel share करते और namespaces से अलग होते हैं; Hyper-V isolation में हर container optimized VM के अंदर dedicated kernel रखता है
    subgraph pi ["process isolation"]
        c1["container A"] --> sk1["host से shared kernel"]
        c2["container B"] --> sk1
    end
    subgraph hi ["Hyper-V isolation"]
        c3["container C"] --> k3["dedicated kernel（optimized VM में）"]
        c4["container D"] --> k4["dedicated kernel（optimized VM में）"]
    end
    sk1 ~~~ c3

चित्र 11: एक ही container image पर भी, isolation रेखा kernel के ऊपर खींचें या kernel स्वयं बाँटें यह start करते समय चुनाव है।

5.2. किसे “security boundary” कह सकते हैं

इन दो modes का अंतर केवल performance कहानी नहीं। Microsoft process-isolated containers को मज़बूत security boundary नहीं मानता। Security boundary के रूप में (vulnerability response सहित) बनाए रखे containers hypervisor-isolated containers हैं, और adversarial multi-tenant scenario में Hyper-V isolation चुनना चाहिए।⁸

भाग 2 में देखा VBS भी “kernel टूट सकता है” मानकर hypervisor boundary पर पीछे हटने वाला design था। वही कसौटी containers की दुनिया में लागू होती है। Untrusted code सीमित करने वाली रेखा hypervisor boundary पर खींची जाती है, shared kernel के अंदर नहीं।

flowchart TB
    accTitle: Code पर कितना भरोसा उससे isolation कैसे चुनें
    accDescr: यदि workload trusted हो तो process isolation से density और performance लें; यदि code untrusted या किसी और का हो तो Hyper-V isolated containers, networking बंद कठोर Windows Sandbox, या isolated VM जैसी hypervisor boundary चुनें
    trust{"उस code पर भरोसा कर सकते?"} -->|हाँ| dens["process isolation（density और गति पहले）"]
    trust -->|नहीं / किसी और का code| bound["hypervisor boundary चुनें"]
    bound --> opt1["Hyper-V isolated container"]
    bound --> opt2["कठोर Sandbox या isolated VM"]

चित्र 12: Isolation mode performance कहानी से पहले security कहानी है, और भरोसा तय करता है रेखा कहाँ खींचें।

प्रसंगवश, Hyper-V VM के अंदर Hyper-V isolated containers चलाना hypervisor दो परत गहरा कर देता है — nested virtualization। Conditions पूरी करने वाले environments पर एक level का nesting production में supported है (Windows 10 / Windows Server 2016 या बाद के host वाला Intel processor, या Windows 11 / Windows Server 2022 या बाद के host वाला AMD processor, और प्रत्येक मामले में compatible VM configuration version), और आगे की prerequisite बाहरी VM को virtualization extensions दिखाने वाली setting है (Hyper-V में Set-VMProcessor पर ExposeVirtualizationExtensions)। VM के अंदर WSL2 चलाना उसी तरह supported है।⁹ Cloud में development VM में WSL2 या Docker उपयोग कर सकते हैं या नहीं यह भी तय होता है कि वह VM size और configuration nested virtualization दिखाता है या नहीं।

flowchart TB
    accTitle: Nested virtualization की structure
    accDescr: Cloud VM physical host के hypervisor पर बैठता है, और उसके अंदर दूसरा hypervisor（supported nesting एक level）WSL2 और Hyper-V isolated containers सहारा देने चलता है
    phys3["physical host का hypervisor"] --> cvm["cloud VM（dev machine）"]
    cvm --> nhv["VM के अंदर hypervisor（nesting level 1）"]
    nhv --> w2["WSL2"]
    nhv --> hvc["Hyper-V isolated container"]
    nhv -.-> limit["supported nesting एक level"]

चित्र 13: Cloud VM के अंदर wsl चलने का कारण यह है कि nested virtualization आधिकारिक रूप से केवल एक level supported है।

5.3. Isolation और हल्केपन का spectrum

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

flowchart TB
    accTitle: Isolation मज़बूती और हल्केपन का spectrum
    accDescr: Process-isolated containers सबसे हल्के पर kernel share करते हैं; WSL2, Sandbox और Hyper-V isolated containers dedicated kernel वाली lightweight VM हैं（Sandbox share कर हल्का, WSL2 purpose-built kernel से）; full VM सबसे भारी पर general-purpose
    ax["हल्का ← → भारी"] ~~~ p1
    p1["process-isolated containers（shared kernel）"] --> p2["WSL2, Sandbox, Hyper-V isolation（dedicated kernel वाली lightweight VM）"]
    p2 --> p3["full VM（कुछ भी चलाए; full copy रखे）"]
    p1 -.-> n1["boundary: namespaces"]
    p2 -.-> n2["boundary: hypervisor"]
    p3 -.-> n3["boundary: hypervisor + पूर्ण स्वतंत्रता"]

चित्र 14: Lightweight-VM समूह वह मध्य समाधान है जिसने hypervisor boundary रखी और duplication / कॉपी काटी; काटने का तरीका Sandbox के लिए sharing और WSL2 के लिए purpose-built kernel में बँटता है।

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

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

Start time और memory का उठना-गिरना (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 के अंदर बड़ा build या file operation करें, vmmem बढ़ता है, और wsl --shutdown से एक साथ लौटते देखा जा सकता है।

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

Direct map की पृष्ठभूमि (Sandbox)। Sandbox start करें और host पर Task Manager में memory की वृद्धि देखें। वृद्धि “दूसरे Windows” की कल्पना से बहुत छोटी रहना sharing का प्रभाव अपनी कहानी कहता है। Host-पक्ष memory breakdown और गहराई से देखने के लिए, RAMMap और VMMap उपयोग cover करने वाला Sysinternals tools वाला लेख (“Process Explorer / Handle / VMMap व्यवहार में”) उपयोगी है। पर ये host-पक्ष processes और physical memory के classification देखने के tools हैं; guest के साथ sharing स्वयं सीधे नहीं देखते।

Container isolation mode (Docker / Windows containers)। यदि Windows containers environment हो, वही image docker run --isolation=process और --isolation=hyperv से start कर start time और Task Manager में दिखना तुलना करें (process isolation में container के अंदर processes host की process list में आते हैं), तो isolation रेखा कहाँ बैठती है महसूस कर सकते हैं।⁷ पर process isolation यह prerequisite रखता है कि host और image versions मेल खाएँ, और client OS पर development तथा testing उपयोग तक सीमित है। Hyper-V isolation व्यापक combination अनुमति देता है, इसलिए तुलना compatible जोड़ी पर करें।¹⁰

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

7.1. “WSL2 धीमा है”

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

7.2. “vmmem बड़ा होना memory leak है”

WSL2 memory demand के साथ बढ़ती-सिकुड़ती है, और छोड़े भाग लौटते हैं। Current WSL पर file cache भी autoMemoryReclaim (default dropCache) से automatically reclaim होता है, इसलिए “बड़ा रह गया” अक्सर समय के साथ हल होता है।⁵ यदि फिर भी रहे, confirm करें कि autoMemoryReclaim disabled सेट नहीं, और छोड़े भाग लौटाने वाला pageReporting बंद नहीं (या पुराने WSL पर नहीं), फिर या तो .wslconfig में memory से upper limit स्पष्ट करें या session सीमा पर wsl --shutdown से सब लौटाएँ। Leak और non-leak अलग करने का सोचने का तरीका memory series की introductory किस्त, “Windows का "memory usage" वास्तव में क्या है?” जैसा ही है।

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

Process-isolated container kernel share करता है, और Microsoft की कसौटी पर security boundary नहीं।⁸ Untrusted code या sample चलाने के लिए Hyper-V isolated containers, Windows Sandbox, या dedicated VM जैसी hypervisor boundary वाला isolation चुनें। पर hypervisor boundary कंबल छूट नहीं। Windows Sandbox की default setting में network connectivity enable है, और untrusted app को internal network दिखा सकती है।¹ यदि sample चलाने उपयोग करें, .wsb configuration file में network और clipboard redirection disable कर isolation मज़बूत करें, या isolated network पर dedicated VM उपयोग करें।

8. सारांश — series बंद करना

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

Lightweight VM का हल्कापन “duplication / कॉपी रोकने” का परिणाम है, “isolation कमज़ोर करने” का नहीं।
WSL2 managed lightweight utility VM में actual Linux kernel चलाता है, और distributions उस VM के अंदर containers के रूप में अलग होते हैं।³ Performance नियम files उपयोग करने वाले OS पर रखना है, और memory dynamically बढ़ती-सिकुड़ती है, upper limit .wslconfig में control योग्य।⁴⁵
Windows Sandbox dynamic base image से host की immutable OS files share करता है और direct map से targeted OS binaries के physical pages भी share करता है, इसलिए पूर्ण Windows की copy नहीं रखता।² Mutable files के लिए अभी भी लगभग 500 MB चाहिए, साथ उसके अंदर चलाए app की memory।
Container isolation mode start करते समय चुना जाता है, और security boundary कह सकने वाला पक्ष Hyper-V isolation है।⁷⁸

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

भाग 1: Windows के नीचे hypervisor layer है, और host OS स्वयं root partition के रूप में चलता है। CPU और memory (SLAT) की मध्यस्थता यह layer सीधे करती है, और synthetic devices का I/O VMBus के पार root partition (VSP) मध्यस्थता करता है।
भाग 2: वह layer न केवल VMs एक-दूसरे से अलग करने, बल्कि उसी OS के अंदर kernel से मज़बूत boundary (VTL) खींचने के लिए भी उपयोग होती है। Windows 11 की default security इसी पर बनी है।
भाग 3: उसी layer पर, duplication / कॉपी काटना “सेकंडों में start होने वाली virtual machine” संभव बनाता है। Isolation रेखा रखी गई, और यह रोज़ का tool बन गया है।

flowchart TB
    accTitle: पूरी series का एक चित्र
    accDescr: Hardware पर सीधा hypervisor भाग 1 है; host Windows के अंदर VTL0 और VTL1 का विभाजन भाग 2 है; उसी layer पर WSL2, Sandbox और Hyper-V isolation का हल्कापन भाग 3 है; process-isolated containers host kernel share करते हैं; Sandbox share कर हल्का, WSL2 purpose-built kernel से
    hw3["hardware"] --> hv3["hypervisor（भाग 1）"]
    hv3 --> rp3["host Windows（VTL isolation भाग 2）"]
    hv3 --> lw3["WSL2, Sandbox, Hyper-V isolation（भाग 3）"]
    rp3 --> pc3["process-isolated containers（shared kernel）"]
    lw3 -.-> mech3["Sandbox share करता; WSL2 purpose-built kernel से हल्का"]

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

Virtualization अब server-room technique नहीं, न केवल VM खड़े करने वालों की technique। आपके Windows के नीचे की ज़मीन पर, यह चुपचाप security और development experience दोनों सहारा देती है — हम अभी वहीं हैं।

संदर्भ लिंक

Microsoft Learn, Windows Sandbox. Windows Sandbox के disposable VM के रूप में कुछ सेकंड में start होकर बंद करने पर सब त्यागने पर; Microsoft hypervisor से अलग kernel चलाकर host से अलग करने पर; और network connectivity के default से enable तथा configuration file में disable किए जा सकने पर। ↩ ↩² ↩³
Microsoft Learn, Windows Sandbox architecture. Dynamic base image के host की immutable OS files के share और mutable files की clean copy से पूर्ण Windows image जोड़ने पर (install के बाद लगभग 500 MB); traditional VM के static memory allocation के विरुद्ध container के host सहयोग से dynamic allocation पर, जिससे host memory reclaim कर सकता है; और direct map के ntdll.dll जैसी OS binaries को host जैसे ही physical pages उपयोग कराने पर। ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Microsoft Learn, What is the Windows Subsystem for Linux?. WSL2 के lightweight utility VM के अंदर Linux kernel चलाने पर; हर distribution के isolated container के रूप में चलने, network namespace और kernel share करते हुए PID, mount और user जैसे namespaces अलग करने पर। ↩ ↩² ↩³
Microsoft Learn, Comparing WSL Versions. WSL2 kernel के Microsoft द्वारा Stable शाखा से बनाए जाने पर; Store-distributed WSL के OS image से अलग package के रूप में update पाकर wsl --update से apply करने पर (पुराने in-box distribution पर Windows Update से); tarball निकालने में 20 गुना तक जैसे performance उदाहरणों पर; cross-OS file-system performance में WSL1 तेज़ होने पर, इसलिए files उपयोग करने वाले OS पर रखने पर; और memory के छोड़े भाग लौटाते बढ़ने-सिकुड़ने, जबकि cache VM निकलने तक न लौट सकने पर। ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
Microsoft Learn, Advanced settings configuration in WSL. .wslconfig के [wsl2] खंड में WSL2 VM की समग्र memory ceiling, processor संख्या, swap और pageReporting (default से enable; unused memory पता कर लौटाने का ज़िम्मेदार) सेट कर सकने पर; और experimental setting autoMemoryReclaim के default dropCache होने पर, जिससे cache memory automatically reclaim होती है। ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, Use and configure Windows Sandbox. .wsb configuration file में MappedFolders के host folders read-only या writable share कर सकने पर। ↩
Microsoft Learn, Isolation Modes. Windows containers के process isolation के host के साथ kernel share कर namespaces से अलग होने पर; Hyper-V isolation के optimized VM के अंदर प्रभाव में dedicated kernel रखने पर; और start करते समय flag से एक ही image किसी भी mode में चला सकने पर। ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Secure Windows containers. केवल hypervisor-isolated containers के security boundary माने जाने पर; process-isolated containers के मज़बूत security boundary न माने जाने पर; और adversarial multi-tenant scenario में hypervisor isolation चुनने पर। ↩ ↩² ↩³
Microsoft Learn, What is Nested Virtualization?. Hyper-V VM के अंदर Hyper-V isolated containers चलाने (एक level nesting) के production में supported होने पर; requirements Intel processor के साथ Windows Server 2016 / Windows 10 या बाद, या AMD processor के साथ Windows Server 2022 / Windows 11 या बाद, तथा प्रत्येक मामले में compatible VM configuration version होने पर; बाहरी VM को virtualization extensions दिखाने (ExposeVirtualizationExtensions) prerequisite होने पर; और Hyper-V VM के अंदर WSL2 चलाने के supported होने पर। ↩
Microsoft Learn, Windows container version compatibility. Process isolation के host और container image versions मेल मानने पर; Hyper-V isolation के host से अलग OS version की image चला सकने पर; और client OS पर process isolation के development तथा testing उपयोग तक सीमित होने पर। ↩

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

Windows Virtualization Internals (भाग 2) — वो मेमोरी जिसे कर्नेल भी नहीं देख सकता: VBS, HVCI और Credential Guard कैसे काम करते हैं

Compatible hardware पर clean install में VBS default से enable होता है और hypervisor तथा SLAT से kernel से मज़बूत isolation बनाता है। यह ...

लेख पढ़ें

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

जब आप Hyper-V enable करते हैं, तो host Windows खुद root partition के रूप में hypervisor के ऊपर चलता है। यह लेख VT-x, SLAT और VMBus की भूम...

लेख पढ़ें

Win32 Thread Pool API — CreateThreadpoolWork से thread बनाए बिना concurrency

क्या आपके native code में CreateThread calls बिखरी पड़ी हैं? यह लेख Vista में redesign की गई Win32 thread pool API — work, timer, wait और...

लेख पढ़ें

Named Pipes व्यवहार में — design से security तक, Windows की standard IPC

Named pipes — Windows की standard inter-process communication — की practical guide। यह लेख primary sources से byte और message mode का चुन...

लेख पढ़ें

Sleep से resume पर टूटने वाले apps — Windows power events कैसे काम करते हैं और उनसे बचने वाले business apps कैसे बनाएँ

Laptop खोला और business app के connections मर चुके थे — कारण वह design है जिसने sleep का हिसाब ही नहीं रखा। यह लेख WM_POWERBROADCAST noti...

लेख पढ़ें

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

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

Windows ऐप विकास

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

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

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

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

क्या WSL2 एक VM है?: हाँ। WSL2 Microsoft द्वारा बनाए गए actual Linux kernel को lightweight utility VM के अंदर चलाता है। VM को WSL पर्दे के पीछे manage करता है, इसलिए design user को VM settings या boot की प्रतीक्षा सोचने नहीं देता। हर Linux distribution इस managed VM के अंदर isolated container के रूप में चलता है।
WSL2 में /mnt/c के अंतर्गत file operations धीमे क्यों हैं?: क्योंकि WSL2 Linux kernel से Windows-पक्ष file system तक पहुँच OS boundary पार करने वाली file sharing से जाती है। Linux file system (ext4 virtual disk) पर operations तेज़ हैं, इसलिए नियम है project files उन tools वाले उसी OS पक्ष पर रखें जो उन पर काम करते हैं।
क्या vmmem process का बड़ा memory usage leak है?: अधिकांश मामलों में leak नहीं। WSL2 memory usage के साथ बढ़ती-सिकुड़ती है, और process ने जो memory छोड़ी वह pageReporting setting के अधीन Windows को लौटाई जाती है, जो default से enable है। File-cache pages भी current WSL .wslconfig में autoMemoryReclaim से automatically reclaim करता है (default dropCache है)। जिन environments में ये settings disable हैं, या पुराने WSL पर, memory VM निकलने तक रह सकती है; उस स्थिति में memory setting से upper limit सेट करें, या wsl --shutdown से लौटाएँ।
Windows Sandbox कुछ सौ megabytes disk से पूर्ण Windows कैसे boot कर सकता है?: Dynamic base image नामक mechanism से। यह host पर पहले से install Windows से immutable OS files share करता है, और केवल थोड़ी संख्या में mutable files की clean copy रखता है। इससे Windows की full copy store किए बिना पूर्ण, bootable image जोड़ी जा सकती है।
क्या containers VM से अधिक सुरक्षित हैं?: यह isolation mode पर निर्भर करता है। Process-isolated containers host के साथ kernel share करते हैं, और Microsoft इसे मज़बूत security boundary नहीं मानता। Adversarial code सँभालते समय Hyper-V isolation चाहिए, जो हर container को अपना dedicated kernel देता है।

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

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

Go Komura

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

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

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

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

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

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

Windows Virtualization Internals (भाग 3) — सेकंडों में boot होने वाली VMs: WSL2, Windows Sandbox और containers इतने हल्के क्यों हैं

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

2. Full VM क्या ढो रहा है

3. WSL2 — purpose-built kernel वाला utility VM

3.1. Structure: managed VM और उसके अंदर distributions

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

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

4. Windows Sandbox — host के Windows का reuse

4.1. Dynamic base image: 500 MB में पूर्ण Windows

4.2. Direct map: वही ntdll.dll वही physical page है

5. Containers — isolation रेखा कहाँ खींचें

5.1. Process isolation और Hyper-V isolation

5.2. किसे “security boundary” कह सकते हैं

5.3. Isolation और हल्केपन का spectrum

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

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

7.1. “WSL2 धीमा है”

7.2. “vmmem बड़ा होना memory leak है”

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

8. सारांश — series बंद करना

संबंधित लेख

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

संदर्भ लिंक

Windows Virtualization Internals (भाग 2) — वो मेमोरी जिसे कर्नेल भी नहीं देख सकता: VBS, HVCI और Credential Guard कैसे काम करते हैं

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

Win32 Thread Pool API — CreateThreadpoolWork से thread बनाए बिना concurrency

Named Pipes व्यवहार में — design से security तक, Windows की standard IPC

Sleep से resume पर टूटने वाले apps — Windows power events कैसे काम करते हैं और उनसे बचने वाले business apps कैसे बनाएँ

संबंधित विषय

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

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

Windows ऐप विकास

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

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

Go Komura

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

2. Full VM क्या ढो रहा है

3. WSL2 — purpose-built kernel वाला utility VM

3.1. Structure: managed VM और उसके अंदर distributions

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

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

4. Windows Sandbox — host के Windows का reuse

4.1. Dynamic base image: 500 MB में पूर्ण Windows

4.2. Direct map: वही ntdll.dll वही physical page है

4.3. Dynamic memory sharing: VM से अधिक process जैसा

5. Containers — isolation रेखा कहाँ खींचें

5.1. Process isolation और Hyper-V isolation

5.2. किसे “security boundary” कह सकते हैं

5.3. Isolation और हल्केपन का spectrum

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

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

7.1. “WSL2 धीमा है”

7.2. “vmmem बड़ा होना memory leak है”

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

8. सारांश — series बंद करना

संबंधित लेख

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

संदर्भ लिंक

संबंधित लेख

Windows Virtualization Internals (भाग 2) — वो मेमोरी जिसे कर्नेल भी नहीं देख सकता: VBS, HVCI और Credential Guard कैसे काम करते हैं

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

Win32 Thread Pool API — CreateThreadpoolWork से thread बनाए बिना concurrency

Named Pipes व्यवहार में — design से security तक, Windows की standard IPC

Sleep से resume पर टूटने वाले apps — Windows power events कैसे काम करते हैं और उनसे बचने वाले business apps कैसे बनाएँ

संबंधित विषय

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

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

Windows ऐप विकास

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

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

Go Komura