WSL2 on kenji.blog

Hyper-V vs WSL2: Windows पर वर्चुअलाइजेशन तकनीक की तुलना

Sun, 13 Sep 2026 07:00:00 +0900

1. परिचय: Windows में वर्चुअलाइजेशन का विकास

Windows प्लेटफॉर्म में वर्चुअलाइजेशन तकनीक ने पिछले कुछ दशकों में नाटकीय विकास देखा है। पहले, थर्ड-पार्टी टाइप 2 हाइपरवाइज़र (जैसे VMware Workstation या VirtualBox) मुख्यधारा में थे, लेकिन जब से Microsoft ने Windows Server 2008 में “Hyper-V” पेश किया है, तब से टाइप 1 हाइपरवाइज़र को डेस्कटॉप OS जैसे Windows 10/11 में भी शामिल किया जाने लगा है।

और हाल के वर्षों में, डेवलपर्स के बीच सबसे ज्यादा ध्यान “WSL2 (Windows Subsystem for Linux 2)” पर दिया गया है। जबकि WSL1 सिस्टम कॉल ट्रांसलेशन पर निर्भर था, WSL2 ने Hyper-V की तकनीक को लागू करते हुए एक “लाइटवेट यूटिलिटी VM (Lightweight Utility VM)” अपनाया है, जिससे पूर्ण Linux संगतता और प्रदर्शन में भारी सुधार हुआ है।

इस लेख में, हम इन दो शक्तिशाली वर्चुअलाइजेशन तकनीकों - पूर्ण विशेषताओं वाले “Hyper-V” और डेवलपर अनुभव पर केंद्रित “WSL2” - के आर्किटेक्चर, प्रदर्शन (CPU, मेमोरी, डिस्क I/O), नेटवर्क कॉन्फ़िगरेशन और सर्वोत्तम उपयोग के मामलों (यूज़ केस) की गहराई से तकनीकी जानकारी के साथ पूरी तरह से तुलना और व्याख्या करेंगे।

2. हाइपरवाइज़र का बुनियादी सिद्धांत और आर्किटेक्चर की तुलना

वर्चुअलाइजेशन तकनीक को समझने के लिए हाइपरवाइज़र (वर्चुअल मशीन मॉनिटर: VMM) के प्रकार का वर्गीकरण बहुत आवश्यक है।

2.1. Type 1 और Type 2 हाइपरवाइज़र के बीच अंतर

हाइपरवाइज़र एक सॉफ़्टवेयर लेयर है जो हार्डवेयर एक्सेस को एब्स्ट्रेक्ट करती है और कई OS (गेस्ट OS) को एक साथ एक ही भौतिक मशीन पर चलाने की अनुमति देती है।

Type 1 (बेयर-मेटल प्रकार): सीधे हार्डवेयर पर चलता है। इसमें होस्ट OS की कोई अवधारणा नहीं होती (हालांकि कभी-कभी विशेषाधिकार प्राप्त एक मैनेजमेंट OS हो सकता है), इसका ओवरहेड बहुत कम होता है, और यह उच्च प्रदर्शन और सुरक्षा प्रदान करता है। उदाहरण: Hyper-V, VMware ESXi, Xen।
Type 2 (होस्ट प्रकार): होस्ट OS (जैसे Windows या macOS) के ऊपर एक एप्लिकेशन के रूप में चलता है। सभी हार्डवेयर एक्सेस होस्ट OS के माध्यम से होते हैं, जिससे ओवरहेड बढ़ जाता है। उदाहरण: VMware Workstation, Oracle VirtualBox।

Windows का Hyper-V एक पूर्ण Type 1 हाइपरवाइज़र है। जब आप Hyper-V को सक्षम करते हैं, तो वास्तव में जो Windows OS आप उपयोग कर रहे हैं वह भी “रूट पार्टीशन (Root Partition)” नामक एक विशेष वर्चुअल मशीन के अंदर चलने लगता है।

2.2. Hyper-V का आर्किटेक्चर विवरण

Hyper-V का आर्किटेक्चर एक माइक्रो-कर्नेल डिज़ाइन को अपनाता है और पार्टीशन (Partition) नामक लॉजिकल अलगाव इकाइयों पर आधारित होता है।

graph TD
A["हार्डवेयर (CPU, RAM, Disk, NIC)"] --> B["Windows हाइपरवाइज़र (Ring -1)"]
B --> C["रूट पार्टीशन (Windows OS)"]
B --> D["चाइल्ड पार्टीशन 1 (Windows VM)"]
B --> E["चाइल्ड पार्टीशन 2 (Linux VM)"]
C --> F["VMBus (वर्चुअल मशीन बस)"]
D --> F
E --> F
C --> G["VID (वर्चुअलाइजेशन इंफ्रास्ट्रक्चर ड्राइवर)"]
C --> H["VMWP.exe (वर्कर प्रोसेस)"]

Windows Hypervisor: CPU के सबसे उच्च विशेषाधिकार प्राप्त स्तर (Ring -1 या VMX Root Mode) में चलता है, और केवल मेमोरी आवंटन और CPU शेड्यूलिंग को संभालता है। इसमें डिवाइस ड्राइवर शामिल नहीं होते हैं।
Root Partition: वह पार्टीशन जिसमें होस्ट Windows OS चलता है। इसमें सभी डिवाइस ड्राइवर होते हैं और यह सीधे हार्डवेयर को नियंत्रित करता है। यह चाइल्ड पार्टीशन के प्रबंधन के लिए कार्य (जैसे WMI प्रोवाइडर और VMWP.exe) भी प्रदान करता है।
Child Partition: वह पार्टीशन जिसमें गेस्ट OS चलता है। इसे सीधे हार्डवेयर तक पहुंचने की अनुमति नहीं है, और यह I/O रिक्वेस्ट (सिंथेटिक I/O) को रूट पार्टीशन में “VMBus” नामक लॉजिकल मेमोरी-शेयर्ड बस के माध्यम से भेजता है।

2.3. WSL2 और Lightweight Utility VM का काम करने का तरीका

WSL2 उसी Type 1 हाइपरवाइज़र बेस तकनीक का उपयोग करता है जिसका Hyper-V करता है, लेकिन यह पूर्ण-सुविधा वाले Hyper-V वर्चुअल मशीन के बजाय “वर्चुअल मशीन प्लेटफ़ॉर्म (Virtual Machine Platform: VMP)” नामक एक सबसेट सुविधा का उपयोग करता है।

WSL2 में उपयोग किए जाने वाले “लाइटवेट यूटिलिटी VM (Lightweight Utility VM)” में पारंपरिक VM के लेगेसी हार्डवेयर एमुलेशन (जैसे वर्चुअल BIOS और वर्चुअल मदरबोर्ड) को पूरी तरह से हटा दिया गया है।

graph TD
A["Windows होस्ट OS (यूज़र स्पेस)"]
B["NTFS फाइल सिस्टम"]
C["9P प्रोटोकॉल सर्वर (Plan 9)"]
D["लाइटवेट यूटिलिटी VM (Linux कर्नेल)"]
E["ext4.vhdx (वर्चुअल डिस्क)"]
F["Linux यूज़र स्पेस (WSL2 डिस्ट्रिब्यूशन)"]
A --> C
C -->| क्रॉस-OS फाइल शेयरिंग | D
D --> E
D --> F

WSL2 की सबसे बड़ी विशेषता इसकी स्टार्टअप गति और होस्ट OS के साथ निर्बाध एकीकरण है। Linux कर्नेल कुछ सेकंड से भी कम समय में बूट हो जाता है और Plan 9 के 9P नेटवर्क फाइल सिस्टम प्रोटोकॉल के माध्यम से Windows फ़ाइल सिस्टम (NTFS) तक पहुंचता है।

3. प्रदर्शन का संपूर्ण विश्लेषण: गणना संसाधन और I/O

वर्चुअल मशीन के प्रदर्शन को CPU, मेमोरी और डिस्क I/O घटकों में ओवरहेड के योग के रूप में दर्शाया जाता है।

3.1. CPU और कॉन्टेक्स्ट स्विच ओवरहेड

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

इस समय CPU ओवरहेड $T_{overhead}$ को निम्नलिखित गणितीय मॉडल द्वारा दर्शाया जा सकता है:

$$ T_{overhead} = \sum_{i=1}^{N} (t_{vm\_exit} + t_{hypercall\_process} + t_{vm\_entry}) $$

जहाँ:

$N$: प्रति यूनिट समय में VM Exit होने की संख्या
$t_{vm\_exit}$: गेस्ट से हाइपरवाइज़र तक का ट्रांज़िशन समय
$t_{hypercall\_process}$: VMBus के माध्यम से I/O प्रोसेसिंग या इंटरप्ट का प्रोसेसिंग समय
$t_{vm\_entry}$: हाइपरवाइज़र से गेस्ट तक वापसी का समय

चूँकि WSL2 में लेगेसी एमुलेशन नहीं है, इसलिए $t_{hypercall\_process}$ अत्यधिक अनुकूलित और बहुत छोटा है। इसलिए, शुद्ध CPU गणनाओं (जैसे कर्नेल को संकलित करना या मशीन लर्निंग मॉडल इनफेरेंस) में, बेयर-मेटल वातावरण की तुलना में प्रदर्शन में गिरावट कुछ प्रतिशत के भीतर ही रहती है।

3.2. मेमोरी आवंटन का तंत्र

जब मेमोरी प्रबंधन के तरीकों की बात आती है, तो दोनों के बीच स्पष्ट रूप से अलग-अलग डिज़ाइन दर्शन होते हैं।

Hyper-V (Dynamic Memory): गेस्ट VM की मेमोरी मांग के अनुसार, रूट पार्टीशन गतिशील रूप से मेमोरी आवंटित और पुनर्प्राप्त (रीक्लेम) करता है। हालाँकि, जब तक सिस्टम में मेमोरी की कमी नধি न हो, गेस्ट OS के भीतर पेज कैशे के रूप में सुरक्षित मेमोरी आसानी से रिलीज़ नहीं होती है।
WSL2 (डायनेमिक मेमोरी रिक्लेम): WSL2 का अपना अनूठा तंत्र है, जो नियमित रूप से अनावश्यक मेमोरी (कैशे सहित) को Linux VM के भीतर से Windows होस्ट को वापस (Reclaim) कर देता है। शुरुआती WSL2 में एक समस्या थी जहाँ Linux पेज कैशे Windows मेमोरी की खपत कर लेता था (Vmmem प्रक्रिया का फूलना), लेकिन इसे अब कर्नेल पैच के माध्यम से सुधार दिया गया है।

3.3. डिस्क I/O की विशेषताएं (VHDX vs ext4.vhdx)

वर्चुअल मशीन के प्रदर्शन में डिस्क I/O सबसे आसानी से बॉटलनेक (अड़चन) बन सकता है।

I/O लेटेंसी $L_{total}$ की गणना इस प्रकार की जाती है:

$$ L_{total} = L_{guest\_fs} + L_{vmbus} + L_{host\_fs} + L_{physical\_disk} $$

Hyper-V के मामले में: सामान्य Hyper-V गेस्ट VHDX फॉर्मेट वर्चुअल डिस्क का उपयोग करते हैं। गेस्ट OS (ext4 या NTFS) के अंदर फाइल सिस्टम से जारी I/O रिक्वेस्ट VMBus के ब्लॉक डिवाइस स्टोरेज ड्राइवर (storvsc) से होकर गुजरती है और Windows पर NTFS पर VHDX फाइल तक एक्सेस के रूप में प्रोसेस होती है।

WSL2 के मामले में: WSL2 के Linux डिस्ट्रिब्यूशन एक समर्पित ext4.vhdx फाइल के भीतर निर्मित नेटिव ext4 फाइल सिस्टम पर चलते हैं। Linux के भीतर फाइल संचालन (जैसे ~ डायरेक्टरी में) उपरोक्त Hyper-V के समान नेटिव प्रदर्शन प्रदान करते हैं। हालाँकि, जब WSL2 Linux से Windows साइड फाइलों (जैसे /mnt/c/) तक पहुँचते हैं, या इसके विपरीत, तो प्रक्रिया काफी अलग होती है। इस क्रॉस-OS एक्सेस के लिए 9P (Plan 9 File System Protocol) का उपयोग किया जाता है।

$$ L_{cross\_os} = L_{9p\_client} + L_{socket\_transfer} + L_{9p\_server} + L_{ntfs} $$

इस 9P प्रोटोकॉल के माध्यम से एक्सेस करने पर सीरियलाइज़ेशन का बड़ा ओवरहेड होता है, और ऐसे उपयोगों के लिए जहाँ बड़ी संख्या में छोटी फ़ाइलों को पढ़ा और लिखा जाता है (उदाहरण के लिए: Windows-साइड डायरेक्टरी में स्थित Node.js प्रोजेक्ट पर npm install या Git संचालन), प्रदर्शन में काफी गिरावट आती है (कभी-कभी 10 गुना से अधिक देरी)। इसलिए, WSL2 का उपयोग करते समय, यह सुनिश्चित करना एक मूल नियम है कि प्रोजेक्ट फाइलें Linux के नेटिव फाइल सिस्टम (जैसे ~/ के तहत) में रखी जाएँ।

4. नेटवर्क संरचना: NAT, Default Switch, Bridged

नेटवर्क क्षमताओं का लचीलापन Hyper-V और WSL2 के बीच सबसे बड़े अंतरों में से एक है।

4.1. WSL2 का नेटवर्क (NAT-आधारित)

WSL2 का नेटवर्क डिफ़ॉल्ट रूप से Hyper-V की वर्चुअल स्विच तकनीक का उपयोग करके “NAT (Network Address Translation)” कॉन्फ़िगरेशन में सेट होता है। Linux VM को स्वचालित रूप से एक निजी IP एड्रेस (जैसे: 172.20.x.x) सौंपा जाता है जो Windows होस्ट से अलग होता है। एक बिल्ट-इन तंत्र है जो Windows होस्ट से localhost को WSL2 के भीतर शुरू की गई सेवाओं (पोर्ट्स) पर फॉरवर्ड करता है, जिससे डेवलपर्स नेटवर्क के बारे में चिंता किए बिना वेब सर्वर आदि का परीक्षण कर सकते हैं।

हाल के वर्षों में, WSL2 के प्रीव्यू वर्जन में “Mirrored मोड” नामक एक नया नेटवर्क मोड पेश किया गया है। इससे IPv6 के लिए सपोर्ट और VPN कनेक्शन के साथ अनुकूलता में सुधार होता है (इसे .wslconfig में सेट किया जा सकता है)।

4.2. Hyper-V का वर्चुअल स्विच (Virtual Switch)

Hyper-V उन्नत एंटरप्राइज़-स्तरीय नेटवर्क बनाने में सक्षम है। यह “वर्चुअल स्विच मैनेजर” के माध्यम से मुख्य रूप से तीन मोड प्रदान करता है:

बाहरी (External): होस्ट मशीन के फिजिकल NIC को वर्चुअल स्विच से बांधता है, जिससे गेस्ट VM सीधे फिजिकल नेटवर्क से जुड़ सकता है (ब्रिज कनेक्शन)। VM को DHCP सर्वर से उसी सबनेट का IP मिलता है जो फिजिकल नेटवर्क का है।
आंतरिक (Internal): केवल होस्ट OS और VM के बीच, और VMs के बीच संचार की अनुमति देता है। यह सीधे बाहरी नेटवर्क तक नहीं पहुंच सकता।
निजी (Private): केवल VMs के बीच संचार की अनुमति देता है, और होस्ट OS के साथ संचार को अवरुद्ध करता है। इसका उपयोग आइसोलेटेड (अलग-थलग) परीक्षण वातावरण बनाने के लिए किया जाता है।

4.3. PowerShell के साथ उन्नत Hyper-V नेटवर्क का निर्माण

डेवलपमेंट या टेस्टिंग वातावरण में, यदि आप VM के लिए एक कस्टमाइज़्ड NAT नेटवर्क बनाना चाहते हैं, तो आप PowerShell का उपयोग करके विस्तृत नियंत्रण प्राप्त कर सकते हैं। यहाँ एक स्क्रिप्ट का उदाहरण दिया गया है जो एक इंटरनल वर्चुअल स्विच बनाता है, उस पर NAT कॉन्फ़िगर करता है, और VM को इंटरनेट एक्सेस प्रदान करता है।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 1. इंटरनल वर्चुअल स्विच बनाना
$SwitchName = "HyperV-NatSwitch"
New-VMSwitch -SwitchName $SwitchName -SwitchType Internal

# 2. होस्ट-साइड वर्चुअल NIC पर IP एड्रेस सेट करना (IP जो गेटवे के रूप में काम करेगा)
$GatewayIP = "192.168.100.1"
$NetPrefix = 24
$InterfaceAlias = "vEthernet ($SwitchName)"
New-NetIPAddress -IPAddress $GatewayIP -PrefixLength $NetPrefix -InterfaceAlias $InterfaceAlias

# 3. NAT नेटवर्क को कॉन्फ़िगर करना
$NatName = "HyperV-NatNetwork"
$NatSubnet = "192.168.100.0/24"
New-NetNat -Name $NatName -InternalIPInterfaceAddressPrefix $NatSubnet

# वेरिफिकेशन कमांड
Get-NetNat

इस कॉन्फ़िगरेशन के साथ, आप निर्दिष्ट Hyper-V गेस्ट पर मैन्युअल रूप से IP 192.168.100.x और गेटवे 192.168.100.1 सेट करके एक कस्टम NAT सेगमेंट बना सकते हैं, जो होस्ट के माध्यम से बाहरी दुनिया के साथ संवाद कर सकता है।

5. उपयोग के मामले (यूज़ केस) और व्यावहारिक चयन मार्गदर्शिका

अब तक आर्किटेक्चर और प्रदर्शन में अंतर को देखते हुए, हम परिभाषित करेंगे कि किस स्थिति में कौन सी तकनीक अपनाई जानी चाहिए।

5.1. परिदृश्य (सिनेरियो) जहाँ WSL2 चुना जाना चाहिए

WSL2 विशेष रूप से “डेवलपर्स की उत्पादकता में सुधार” के लिए डिज़ाइन किया गया है। यह निम्नलिखित उपयोगों के लिए आदर्श है:

वेब डेवलपमेंट और क्लाउड-नेटिव डेवलपमेंट: Docker Desktop (WSL2 बैकएंड) या Podman का उपयोग करके कंटेनर डेवलपमेंट।
Linux-विशिष्ट टूल का उपयोग: अगर आप रोज़ाना bash, grep, awk, sed, या Linux के लिए GCC और Clang कंपाइलर का उपयोग करते हैं।
GUI एप्लिकेशन (WSLg): यदि आप Windows डेस्कटॉप पर Linux X11/Wayland एप्लिकेशन को निर्बाध (सीमलेस) रूप से चलाना चाहते हैं।
मशीन लर्निंग और AI डेवलपमेंट: GPU पास-थ्रू फीचर (NVIDIA CUDA on WSL) का उपयोग करके TensorFlow या PyTorch में तेज़ ट्रेनिंग।

ध्यान दें: यदि आप कर्नेल को बारीक रूप से कस्टमाइज़ करना चाहते हैं या ऐसी जटिल सेवाएँ बनाना चाहते हैं जो systemd पर बहुत अधिक निर्भर करती हैं (हालांकि systemd अब समर्थित है, डिफ़ॉल्ट रूप से यह अक्षम या सीमित हो सकता है), तो आपको प्रतिबंधों का सामना करना पड़ सकता है।

5.2. परिदृश्य (सिनेरियो) जहाँ Hyper-V चुना जाना चाहिए

Hyper-V का उद्देश्य “इंफ्रास्ट्रक्चर वर्चुअलाइजेशन और पूर्ण अलगाव (आइसोलेशन)” है। यह निम्नलिखित उपयोगों के लिए आवश्यक है:

Windows VM चलाना: यदि आप परीक्षण वातावरण के रूप में Windows के विभिन्न संस्करणों (जैसे Windows Server या पुराने Windows 10) को चलाना चाहते हैं।
नेस्टेड वर्चुअलाइजेशन: यदि आप वर्चुअल मशीन के अंदर एक और वर्चुअल मशीन (Hyper-V या KVM) चलाना चाहते हैं। यह इंफ्रास्ट्रक्चर इंजीनियरों के परीक्षण वातावरण के लिए अनिवार्य है।
उन्नत नेटवर्क आवश्यकताएँ: यदि नेटवर्क कॉन्फ़िगरेशन को सख्ती से नियंत्रित करना आवश्यक है, जैसे कि एक्सटर्नल ब्रिजिंग (एक ही LAN से जुड़ना), VLAN टैगिंग, या कई NIC असाइन करना।
स्नैपशॉट (चेकपॉइंट्स): VM को किसी विशिष्ट समय की स्थिति में सहेजने और उसे तुरंत रोलबैक (वापस पलटने) की क्षमता। यह सॉफ़्टवेयर के विनाशकारी परीक्षण या मैलवेयर विश्लेषण के लिए बेहद उपयोगी है।
निश्चित संसाधन आवंटन: यदि आप CPU कोर की संख्या और मेमोरी की मात्रा को सख्ती से फिक्स करना चाहते हैं ताकि होस्ट OS पर प्रभाव कम से कम हो।

6. गणितीय मॉडल के माध्यम से I/O थ्रूपुट का अध्ययन (परिशिष्ट)

एक सिस्टम इंजीनियर के रूप में, दोनों की I/O प्रदर्शन सीमाओं का आकलन करते समय थ्रूपुट $S$ और ब्लॉक साइज़ $B$ के बीच के संबंध को सैद्धांतिक रूप से समझना महत्वपूर्ण है।

डेटा ट्रांसफर थ्रूपुट $S$, प्रति यूनिट समय में ट्रांसफर किए गए डेटा की मात्रा है, और इसे इस प्रकार मॉडल किया जा सकता है:

$$ S(B) = \frac{B}{L_{setup} + \frac{B}{R_{max}}} $$

$B$: ब्लॉक साइज़ (Bytes)
$L_{setup}$: I/O अनुरोध को सेट अप करने और कॉन्टेक्स्ट स्विच से जुड़ी निश्चित लेटेंसी
$R_{max}$: कॉपी या डिवाइस ट्रांसफर में हार्डवेयर की अधिकतम बैंडविड्थ

WSL2 में 9P प्रोटोकॉल के माध्यम से फाइल एक्सेस करते समय, यह $L_{setup}$ बहुत बड़ा होता है (सॉकेट संचार और प्रोटोकॉल के सीरियलाइज़ेशन/डी-सीरियलाइज़ेशन के कारण)। इसलिए, जब ब्लॉक साइज़ $B$ छोटा होता है (जैसे कुछ KB की छोटी फाइलों का बड़े पैमाने पर पढ़ना/लिखना), तो डिनॉमिनेटर (हर) में $L_{setup}$ का प्रभाव हावी हो जाता है, और थ्रूपुट $S$ में भारी गिरावट आती है। इसके विपरीत, Hyper-V के VMBus के माध्यम से VHDX एक्सेस में, $L_{setup}$ को हार्डवेयर इंटरप्ट के स्तर के करीब अनुकूलित किया जाता है, जिससे यह छोटे ब्लॉकों के साथ भी उच्च IOPS बनाए रख सकता है।

यही गणितीय वास्तविकता उस सर्वोत्तम अभ्यास (बेस्ट प्रैक्टिस) का तार्किक आधार है कि “WSL2 में प्रोजेक्ट फाइलों को Windows साइड पर नहीं रखा जाना चाहिए”।

7. निष्कर्ष: दो सह-अस्तित्व वाली वर्चुअलाइजेशन तकनीकें

यह कहना सही नहीं होगा कि Hyper-V या WSL2 में से कोई एक दूसरे से बेहतर है; बल्कि ये “अलग-अलग उद्देश्यों वाले दो समाधान” हैं।

WSL2 Windows OS की सीमाओं को तोड़ता है और Linux इकोसिस्टम को Windows उपयोगकर्ताओं तक निर्बाध और तेज़ी से पहुँचाने के लिए “सर्वोत्तम एकीकरण उपकरण (इंटीग्रेशन टूल)” है। इसे डेवलपर्स के लिए अंतिम CLI वातावरण कहना कोई अतिशयोक्ति नहीं होगी।
Hyper-V एक “पूर्ण-विकसित हाइपरवाइज़र” है जो एंटरप्राइज़ डेटा सेंटरों में विकसित मजबूत अलगाव (आइसोलेशन) और प्रबंधन क्षमताओं को डेस्कटॉप पर लाता है। नेटवर्क निर्माण, Windows OS परीक्षण, और इंफ्रास्ट्रक्चर वातावरण सिमुलेशन के मामले में यह बेजोड़ है।

आधुनिक Windows वातावरण में, ये दोनों तकनीकें आपस में प्रतिस्पर्धा करने के बजाय एक ही VM प्लेटफॉर्म पर खूबसूरती से सह-अस्तित्व में हैं। अपने उपयोग के आधार पर सही जगह पर सही तकनीक का उपयोग करके, Windows दुनिया में सबसे शक्तिशाली और लचीला इंजीनियरिंग वर्कस्टेशन बन जाएगा।

WSL2 (Windows Subsystem for Linux) का अल्टीमेट डेवलपमेंट एनवायरनमेंट सेटअप गाइड

Sat, 12 Sep 2026 23:00:00 +0900

Windows पर Linux-नेटिव डेवलपमेंट एनवायरनमेंट प्रदान करने वाला “WSL2 (Windows Subsystem for Linux 2)” आधुनिक सॉफ्टवेयर डेवलपमेंट में एक अनिवार्य टूल बन गया है। हालाँकि, इसे डिफ़ॉल्ट स्थिति में उपयोग करने बनाम इसके आर्किटेक्चर को समझने और इसे ठीक से ट्यून करने के बीच परफॉरमेंस और डेवलपमेंट अनुभव में एक बड़ा अंतर है।

इस लेख में, हम WSL2 के मूल आर्किटेक्चर की व्याख्या से शुरू करेंगे और “अल्टीमेट डेवलपमेंट एनवायरनमेंट” बनाने के लिए सभी चरणों को विस्तार से (10,000 से अधिक वर्णों में) समझाएंगे जिसकी पेशेवर इंजीनियरों को आवश्यकता होती है। इसमें परफॉरमेंस को अधिकतम करने के लिए सेटिंग्स, एक आरामदायक टर्मिनल एनवायरनमेंट का निर्माण, Docker और VS Code के साथ सहज एकीकरण और उन्नत नेटवर्क कॉन्फ़िगरेशन शामिल हैं।

1. WSL2 का आर्किटेक्चर और WSL1 से इसका विकास

WSL2 की क्षमता को पूरी तरह से अनलॉक करने के लिए, सबसे पहले इसके आंतरिक ढांचे को समझना महत्वपूर्ण है। पहली पीढ़ी के WSL (WSL1) और WSL2 के बीच Windows पर Linux बायनेरिज़ को चलाने का दृष्टिकोण मौलिक रूप से अलग है।

WSL1: सिस्टम कॉल ट्रांसलेशन लेयर

WSL1 ने एक तंत्र अपनाया जो Linux सिस्टम कॉल को वास्तविक समय में Windows NT API में अनुवाद (ट्रांसलेट) करता था। इसका फायदा यह था कि रिसोर्स का ओवरहेड बहुत कम था क्योंकि यह वर्चुअल मशीन (VM) का उपयोग नहीं करता था। हालाँकि, फ़ाइल सिस्टम I/O संचालन जैसे जटिल सिस्टम कॉल का पूरी तरह से अनुकरण करना मुश्किल था, जिससे विशेष रूप से बड़ी संख्या में छोटी फ़ाइलों को संभालने वाले ऑपरेशंस, जैसे Node.js के npm install या Git रिपॉजिटरी ऑपरेशंस में परफॉरमेंस में भारी गिरावट आई।

WSL2: लाइटवेट यूटिलिटी VM और पूर्ण Linux कर्नेल

WSL2 में, आर्किटेक्चर को पूरी तरह से नया रूप दिया गया था, और Microsoft द्वारा निर्मित एक वास्तविक Linux कर्नेल अब सीधे Hyper-V आर्किटेक्चर के सबसेट का उपयोग करके “लाइटवेट यूटिलिटी VM” पर चलता है। यह सिस्टम कॉल के साथ 100% अनुकूलता सुनिश्चित करता है, और Linux-नेटिव ext4 फ़ाइल सिस्टम का उपयोग करने वाले वर्चुअल डिस्क (VHDX) का उपयोग करके फ़ाइल I/O परफॉरमेंस में WSL1 की तुलना में नाटकीय रूप से सुधार हुआ है।

नीचे दिया गया Mermaid डायग्राम WSL1 और WSL2 के बीच संरचनात्मक अंतर दिखाता है।

flowchart TD
subgraph "Windows OS Environment"
A["Windows NT कर्नेल"]
A --> F["NTFS फ़ाइल सिस्टम (C: ड्राइव)"]
end
subgraph "WSL2 Architecture"
B["Hyper-V हाइपरवाइज़र"]
B --> C["लाइटवेट यूटिलिटी VM"]
C --> D["Linux कर्नेल (Microsoft)"]
D --> E["Ubuntu यूज़र स्पेस (glibc, bash, आदि)"]
D --> G["ext4 वर्चुअल डिस्क (.vhdx)"]
end
A -.->|"Plan 9 (9P) प्रोटोकॉल नेटवर्क फ़ाइल शेयर"| D
style B fill:#f9f,stroke:#333,stroke-width:2px
style D fill:#bbf,stroke:#333,stroke-width:2px

इस संरचना से सबसे महत्वपूर्ण सबक यह है कि “Linux की तरफ (VHDX के अंदर) फ़ाइलों तक पहुंच बहुत तेज़ है, लेकिन Windows की तरफ (/mnt/c/) फ़ाइलों तक पहुंच बहुत धीमी है क्योंकि यह 9P प्रोटोकॉल के माध्यम से जाती है।” इसलिए, प्रोजेक्ट के सोर्स कोड को हमेशा WSL के होम डायरेक्टरी (~) के अंतर्गत रखा जाना चाहिए।

2. परफॉरमेंस का गणितीय विश्लेषण: WSL2 इतना तेज़ क्यों है?

आइए एक गणितीय मॉडल का उपयोग करके WSL2 के परफॉरमेंस सुधार का मात्रात्मक मूल्यांकन करें। सॉफ्टवेयर डेवलपमेंट में सबसे अधिक समय लेने वाले ऑपरेशंस में से एक भारी फ़ाइल I/O (जैसे: लाइब्रेरी इंस्टॉलेशन या बिल्ड) है।

किसी भी प्रक्रिया का कुल निष्पादन समय $T_{total}$, CPU की गणना के समय $T_{compute}$ और डिस्क I/O में लगने वाले समय $T_{io}$ के योग के रूप में व्यक्त किया जा सकता है।

$$ T_{total} = T_{compute} + T_{io} $$

WSL1 के मामले में, Linux ऑपरेशंस को NTFS ऑपरेशंस में बदलने का ओवरहेड होता है, इसलिए I/O समय को इस प्रकार मॉडल किया जाता है। यहाँ, $n$ फ़ाइल ऑपरेशंस की संख्या है, $t_{ntfs\_syscall}$ Windows का सिस्टम कॉल निष्पादन समय है, और $t_{trans}$ ट्रांसलेशन लेयर का ओवरहेड है।

$$ T_{wsl1\_io} = \sum_{i=1}^{n} (t_{ntfs\_syscall_i} + t_{trans_i}) $$

दूसरी ओर, WSL2 में, कर्नेल सीधे ext4 फ़ाइल सिस्टम को I/O जारी करता है, इसलिए ओवरहेड केवल वर्चुअलाइजेशन के कारण होने वाली बहुत मामूली देरी $t_{virt}$ है।

$$ T_{wsl2\_io} = \sum_{i=1}^{n} (t_{ext4_i} + t_{virt_i}) $$

सामान्य फ़ाइल सिस्टम में, $t_{ext4} \ll t_{ntfs\_syscall} + t_{trans}$ होता है, इसलिए जब $n$ बहुत बड़ा होता है (हज़ारों से लाखों फ़ाइल ऑपरेशंस), WSL1 और WSL2 के I/O समय के बीच का अंतर घातीय (exponentially) रूप से बढ़ता है।

इसके अलावा, यदि वर्चुअलाइज्ड एनवायरनमेंट में CPU गणना ओवरहेड अनुपात $\rho$ है, तो नवीनतम हार्डवेयर-असिस्टेड वर्चुअलाइजेशन (Intel VT-x / AMD-V) के साथ, यह $\rho \approx 0.01 \sim 0.03$ (1-3%) तक सीमित रहता है। इसलिए, यहां तक कि शुद्ध कंप्यूटेशनल कार्यों में, यह एक नेटिव Linux एनवायरनमेंट के बराबर $97\% \sim 99\%$ परफॉरमेंस देता है।

3. इंस्टॉलेशन और फाउंडेशन सेटअप

Windows 10/11 पर WSL2 को इंस्टॉल करना बहुत आसान हो गया है। बस एडमिनिस्ट्रेटर अधिकारों के साथ PowerShell खोलें और निम्नलिखित कमांड चलाएँ:

1
2
3
4
5
6


# WSL2 और Ubuntu डिफ़ॉल्ट रूप से इंस्टॉल हो जाएंगे
wsl --install

# यदि कोई विशिष्ट डिस्ट्रिब्यूशन चुनना हो
# आप इसे wsl --list --online से देख सकते हैं
wsl --install -d Ubuntu-24.04

इंस्टॉलेशन के बाद, सिस्टम रीबूट होता है, और पहले बूट पर, आपको UNIX यूज़रनेम और पासवर्ड सेट करने के लिए कहा जाएगा। यह यूज़र Windows यूज़र से स्वतंत्र होता है और केवल WSL के भीतर मान्य होता है।

यदि आप पहले से ही WSL1 का उपयोग कर रहे हैं, तो आप इसे निम्न कमांड के साथ WSL2 में बदल सकते हैं:

1
2
3
4
5


# मौजूदा डिस्ट्रिब्यूशन को WSL2 में बदलें
wsl --set-version Ubuntu 2

# भविष्य में जोड़े जाने वाले डिस्ट्रिब्यूशन के लिए डिफ़ॉल्ट को WSL2 पर सेट करें
wsl --set-default-version 2

4. रिसोर्स नियंत्रण में महारत: .wslconfig और wsl.conf

WSL2 की सबसे बड़ी कमियों में से एक “अनलिमिटेड मेमोरी की खपत (Vmmem प्रक्रिया का विस्तार)” है। चूँकि WSL2 Linux कर्नेल पेज कैश का उपयोग करता है, यह I/O करते समय बिना किसी सीमा के होस्ट (Windows) की मेमोरी की खपत करता रहता है। इसे रोकने के लिए, कॉन्फ़िगरेशन फ़ाइलों के माध्यम से रिसोर्स को सीमित करना अनिवार्य है।

WSL2 की कॉन्फ़िगरेशन फ़ाइलों को दो भागों में विभाजित किया गया है: .wslconfig जो पूरे Windows को प्रभावित करता है, और wsl.conf जो प्रत्येक डिस्ट्रिब्यूशन के अंदरूनी हिस्से को प्रभावित करता है।

4.1. .wslconfig (Windows साइड)

Windows यूज़र प्रोफ़ाइल डायरेक्टरी (C:\Users\<username>\.wslconfig) में एक फ़ाइल बनाएँ और VM के रिसोर्स आवंटन को नियंत्रित करें।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# C:\Users\<username>\.wslconfig
[wsl2]
# VM को आवंटित अधिकतम मेमोरी। होस्ट की कुल मेमोरी का लगभग 50% से 75% अनुशंसित है
memory=16GB

# उपयोग किए जाने वाले CPU कोर की संख्या (यदि खाली छोड़ा गया तो सभी कोर उपयोग होंगे)
processors=8

# स्वैप फ़ाइल का आकार
swap=8GB

# स्वैप फ़ाइल का स्थान (यदि आप C ड्राइव पर स्थान बचाना चाहते हैं)
# swapfile=D:\\wsl\\swap.vhdx

# localhost फ़ॉरवर्डिंग सक्षम करें (Windows से localhost के माध्यम से WSL तक पहुँचने के लिए)
localhostForwarding=true

# स्वचालित रूप से मेमोरी मुक्त करें (केवल Windows 11)
# पेज कैश को डायनेमिक रूप से खाली करता है और Vmmem को बड़ा होने से रोकता है
autoMemoryReclaim=dropcache

[experimental]
# उन्नत नेटवर्क सुविधाएँ Windows 11 22H2 और बाद के वर्ज़न पर उपलब्ध हैं
# यह IPv6 समर्थन और WSL और Windows के बीच एक ही IP एड्रेस साझा करने की अनुमति देता है
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

4.2. wsl.conf (Linux साइड)

डिस्ट्रिब्यूशन-विशिष्ट व्यवहार को नियंत्रित करने के लिए WSL के भीतर /etc/wsl.conf को संपादित करें।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# /etc/wsl.conf (WSL के अंदर संपादित करें)
[network]
# WSL स्टार्टअप पर स्वतः उत्पन्न होने वाले /etc/resolv.conf को अक्षम करें
# यदि आप अपना स्वयं का DNS सेट करना चाहते हैं (उदा: 8.8.8.8) तो उपयोगी है
generateResolvConf=false

# अपना खुद का होस्टनाम सेट करें
hostname=WSL-DevNode

[automount]
# Windows ड्राइव को माउंट करने के लिए सेटिंग्स
enabled=true
options="metadata,uid=1000,gid=1000,umask=022"
# C ड्राइव के माउंट पॉइंट को /mnt/c से /c में बदलें (पथ को छोटा करने के लिए)
root=/

[boot]
# systemd को सक्षम करें (WSL 0.67.6 या उच्चतर)
# यह snap और विभिन्न डेमन्स (Docker, आदि) को नेटिव रूप से चलाने की अनुमति देता है
systemd=true

[user]
# डिफ़ॉल्ट लॉगिन यूज़र
default=kenji

इन सेटिंग्स को लागू करने के लिए, आपको PowerShell में wsl --shutdown चलाकर WSL VM को पूरी तरह से रोकना होगा और फिर इसे फिर से शुरू करना होगा।

5. अल्टीमेट टर्मिनल एनवायरनमेंट: Zsh + Powerlevel10k

आप डिफ़ॉल्ट bash के साथ उत्पादकता नहीं बढ़ा सकते हैं। एक बेहतरीन प्रॉम्प्ट बनाने के लिए शक्तिशाली ऑटो-कम्प्लीट और उत्कृष्ट दृश्यता वाले Zsh को अति-तीव्र थीम “Powerlevel10k” के साथ संयोजित करें।

5.1. Windows Terminal स्थापित करना और कॉन्फ़िगर करना

Microsoft Store से “Windows Terminal” इंस्टॉल करें। JSON सेटिंग्स (settings.json) खोलें, डिफ़ॉल्ट प्रोफ़ाइल को WSL (Ubuntu) पर सेट करें, और फ़ॉन्ट को डेवलपमेंट के अनुकूल Nerd Font (जैसे HackGen Console NF या MesloLGS NF) में बदलें।

5.2. Zsh और Oh My Zsh इंस्टॉल करना

WSL टर्मिनल में निम्नलिखित कमांड चलाएँ:

1
2
3
4
5
6


# पैकेज अपडेट करें और Zsh इंस्टॉल करें
sudo apt update && sudo apt upgrade -y
sudo apt install -y zsh git curl

# Oh My Zsh इंस्टॉलेशन स्क्रिप्ट चलाएँ
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

5.3. Powerlevel10k और प्लगइन्स इंस्टॉल करना

Zsh को और बेहतर बनाने वाले प्लगइन्स (सिंटैक्स हाइलाइटिंग और ऑटो-कम्प्लीट) और Powerlevel10k थीम इंस्टॉल करें।

1
2
3
4
5
6
7
8


# Powerlevel10k
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

# zsh-autosuggestions
git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

# zsh-syntax-highlighting
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

थीम और प्लगइन्स को सक्षम करने के लिए ~/.zshrc संपादित करें।

1
2
3
4
5


# ~/.zshrc में बदलाव
ZSH_THEME="powerlevel10k/powerlevel10k"

# प्लगइन्स सरणी (array) में जोड़ें
plugins=(git zsh-autosuggestions zsh-syntax-highlighting)

सहेजें और source ~/.zshrc चलाएँ, और Powerlevel10k कॉन्फ़िगरेशन विज़ार्ड (p10k configure) शुरू हो जाएगा। अपने पसंदीदा प्रॉम्प्ट (प्रॉम्प्ट शैली, आइकन, प्रदर्शित की जाने वाली जानकारी, आदि) को अनुकूलित करने के लिए ऑन-स्क्रीन निर्देशों का पालन करें। Git ब्रांच का नाम और स्थिति, Node.js वर्ज़न, कमांड निष्पादन समय आदि वास्तविक समय में प्रदर्शित किए जाएंगे, जिससे डेवलपमेंट दक्षता में नाटकीय रूप से सुधार होगा।

6. VS Code Remote - WSL का सहज एकीकरण

WSL2 में डेवलपमेंट करते समय, “Remote - WSL” एक्सटेंशन वह तंत्र है जो आपको Windows पक्ष पर इंस्टॉल किए गए IDE (Visual Studio Code) से WSL के अंदर की फ़ाइलों तक सहजता से पहुंचने की अनुमति देता है।

आर्किटेक्चर की व्याख्या

नीचे दिया गया अनुक्रम (sequence) आरेख दिखाता है कि VS Code कैसे WSL2 के साथ संचार करता है।

sequenceDiagram
autonumber
participant U as "डेवलपर"
participant V as "VS Code UI (Windows)"
participant S as "VS Code सर्वर (WSL2)"
participant F as "ext4 फ़ाइल सिस्टम (WSL2)"
U->>V: "WSL टर्मिनल में `code .` टाइप करें"
V->>S: "Vsock के माध्यम से RPC कनेक्शन स्थापित करें"
Note over V,S: TCP/IP के बजाय Hyper-V सॉकेट का उपयोग करके संचार करें
S->>F: "सोर्स फ़ाइलें पढ़ें / लिंटर चलाएँ"
F-->>S: "डेटा और विश्लेषण लौटाएं"
S-->>V: "UI पर लैंग्वेज सर्वर परिणाम स्ट्रीम करें"
V-->>U: "सिंटैक्स हाइलाइटिंग और त्रुटियां प्रदर्शित करें"

Windows पक्ष पर VS Code सिर्फ एक “पतले क्लाइंट (UI)” के रूप में कार्य करता है, और लैंग्वेज सर्वर, डिबगर, टर्मिनल निष्पादन जैसे सभी भारी कार्य WSL पक्ष पर “VS Code Server” द्वारा नियंत्रित किए जाते हैं। इससे आप Windows पक्ष पर Node.js या Python इंस्टॉल किए बिना WSL एनवायरनमेंट को साफ रख सकते हैं।

आवश्यक VS Code सेटिंग्स

VS Code के “एक्सटेंशन” से “WSL” (ms-vscode-remote.remote-wsl) इंस्टॉल करें। इसके बाद, बस WSL टर्मिनल में प्रोजेक्ट डायरेक्टरी में जाएं और code . चलाएं, और Windows पक्ष का VS Code उस डायरेक्टरी को खोले हुए प्रारंभ हो जाएगा।

महत्वपूर्ण नोट (लाइन ब्रेक कोड समस्या): Windows और Linux के लाइन ब्रेक कोड अलग-अलग होते हैं (Windows CRLF है, Linux LF है)। WSL पर डेवलप करते समय, सुनिश्चित करें कि Git की core.autocrlf सेटिंग और VS Code की डिफ़ॉल्ट फ़ाइल सेटिंग दोनों को LF पर सेट किया गया है। यदि आप ऐसा करने में विफल रहते हैं, तो शेल स्क्रिप्ट या Docker कंटेनर चलाते समय आपको अजीब त्रुटियों का सामना करना पड़ सकता है।

1
2


# WSL पर Git के लिए लाइन ब्रेक कोड सेटिंग
git config --global core.autocrlf input

अपने VS Code settings.json (रिमोट सेटिंग्स) में निम्न जोड़ें:

1
2
3
4


{
 "files.eol": "\n",
 "terminal.integrated.defaultProfile.linux": "zsh"
}

7. Docker Desktop और WSL2 एकीकरण का ऑप्टिमाइज़ेशन

WSL2 एनवायरनमेंट में Docker का उपयोग करने के मुख्य रूप से दो तरीके हैं:

Docker Desktop for Windows इंस्टॉल करें और WSL2 एकीकरण सक्षम करें।
नेटिव Docker Engine को सीधे WSL2 के अंदर इंस्टॉल करें (जैसे Ubuntu में)।

दृष्टिकोण 1: Docker Desktop (अनुशंसित)

ज्यादातर मामलों में, इसकी अनुशंसा की जाती है क्योंकि GUI के माध्यम से इसे प्रबंधित करना आसान है और Windows/WSL के बीच कंटेनरों तक पारदर्शी पहुंच प्रदान करता है। Docker Desktop की सेटिंग्स से निम्न जांचें:

General -> Use the WSL 2 based engine को चेक करें।
Resources -> WSL Integration -> Enable integration with my default WSL distro को चेक करें और जिस डिस्ट्रिब्यूशन का उपयोग करना है (Ubuntu) उसके लिए टॉगल चालू करें।

यह आपको सीधे WSL2 टर्मिनल से docker कमांड चलाने की अनुमति देता है, और Docker डेमन के साथ संचार Docker Desktop द्वारा प्रबंधित समर्पित हल्के VM (docker-desktop और docker-desktop-data) के माध्यम से किया जाता है।

दृष्टिकोण 2: नेटिव Docker Engine की प्रत्यक्ष स्थापना

यदि कॉर्पोरेट नेटवर्क प्रतिबंध (जैसे Docker Desktop के भुगतान से बचना) या यदि आप परफॉरमेंस ओवरहेड को पूरी तरह से समाप्त करना चाहते हैं, तो /etc/wsl.conf में systemd को सक्षम करें और Docker को एक शुद्ध Ubuntu सर्वर के रूप में इंस्टॉल करें।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# systemd के इनेबल होने पर WSL2 Ubuntu में Docker के आधिकारिक इंस्टॉलेशन चरणों का अंश
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# रिपॉजिटरी जोड़ना
echo \
 "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
 "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
 sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# वर्तमान यूज़र को docker समूह में जोड़ें (ताकि बिना sudo के चलाया जा सके)
sudo usermod -aG docker $USER

रीबूट करने के बाद, systemctl start docker बिल्कुल नेटिव Linux एनवायरनमेंट की तरह काम करेगा और उच्च प्रदर्शन प्रदान करेगा।

8. SSH कीज़ (Keys) का एकीकरण: Windows और WSL के बीच सहज प्रमाणीकरण

Git SSH क्लोन या रिमोट सर्वर से SSH कनेक्शन बनाते समय, Windows और WSL के लिए अलग-अलग SSH कुंजियों को प्रबंधित करना बहुत बोझिल होता है। सुरक्षा और सुविधा दोनों सुनिश्चित करने के लिए, आप Windows पर चलने वाले SSH एजेंट (या 1Password जैसे पासवर्ड मैनेजर) को WSL में ब्रिज कर सकते हैं।

यहां, सबसे सुरक्षित और आधुनिक दृष्टिकोण के रूप में, हम 1Password की SSH एजेंट सुविधा या Windows के OpenSSH ऑथेंटिकेशन एजेंट का उपयोग करने और npiperelay या socat का उपयोग करके इसे WSL2 के UNIX डोमेन सॉकेट पर फॉरवर्ड करने का तरीका बताएंगे।

ssh-agent का सॉकेट फॉरवर्डिंग

आमतौर पर, Windows के नेम्ड पाइप (Named Pipe) के रूप में प्रदान किए गए SSH एजेंट को WSL की तरफ एक सॉकेट फ़ाइल में परिवर्तित करने की आवश्यकता होती है। wsl-ssh-agent या 1Password द्वारा प्रदान की गई सुविधाओं का उपयोग करना आसान है।

1Password की सेटिंग्स स्क्रीन से, “Developer” -> “Use the SSH agent” सक्षम करें। अगला, WSL में ~/.zshrc या ~/.bashrc में निम्न सेटिंग्स जोड़ें ताकि लॉगिन करते समय सॉकेट स्वतः बाइंड हो जाए।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# ~/.zshrc में जोड़ें (1Password SSH एजेंट का उपयोग करने का उदाहरण)
export SSH_AUTH_SOCK=$HOME/.ssh/agent.sock
# यदि WSL शुरू होने पर सॉकेट मौजूद नहीं है या प्रक्रिया बंधी नहीं है, तो फॉरवर्ड करने के लिए socat और npiperelay का उपयोग करें
ALREADY_RUNNING=$(ps -aux | grep "[n]piperelay.exe -ei -s //./pipe/openssh-ssh-agent" | wc -l)
if [ $ALREADY_RUNNING -eq 0 ]; then
 if [ -S $SSH_AUTH_SOCK ]; then
 rm $SSH_AUTH_SOCK
 fi
 # socat को बैकग्राउंड में शुरू करें और Windows के Named Pipe को WSL के UNIX सॉकेट से कनेक्ट करें
 (setsid socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:"npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork &) >/dev/null 2>&1
fi

नोट: आपको Windows की तरफ npiperelay.exe इंस्टॉल करना होगा और पहले से उसका पथ (path) सेट करना होगा।

एक बार यह सेटअप पूरा हो जाने पर, WSL टर्मिनल से ssh-add -l चलाने पर 1Password या Windows में पंजीकृत SSH सार्वजनिक कुंजियों (public keys) की सूची दिखाई देगी। यह आपको निजी कुंजी (private key) फ़ाइल को WSL में कॉपी किए बिना प्रमाणीकरण (authentication) को सुरक्षित रूप से पास करने की अनुमति देता है।

9. रखरखाव: फूले हुए VHDX का ऑप्टिमाइज़ेशन (संपीड़न)

WSL2 की सबसे बड़ी खामियों में से एक यह है कि “Docker इमेज को हटाने या फ़ाइलों को हटाने पर भी Windows की तरफ वर्चुअल डिस्क (.vhdx) का फ़ाइल आकार स्वचालित रूप से कम नहीं होता है।” यदि आप लंबे समय तक विकास करते हैं, तो ext4.vhdx फ़ाइल दसियों से लेकर सैकड़ों गीगाबाइट (GB) तक फूल सकती है।

डिस्क स्पेस खाली करने के लिए, आपको समय-समय पर Windows की तरफ से VHDX को ऑप्टिमाइज़ (Compact) करना होगा।

सबसे पहले, WSL को पूरी तरह से शट डाउन करें।
1

wsl --shutdown
एडमिनिस्ट्रेटर अधिकारों के साथ PowerShell खोलें और निम्न diskpart कमांड या Hyper-V मॉड्यूल के Optimize-VHD कमांड को चलाएं (बाद वाले का उपयोग केवल तभी किया जा सकता है जब Hyper-V इनेबल हो)।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# यदि Hyper-V मॉड्यूल उपलब्ध है
Optimize-VHD -Path "$env:LOCALAPPDATA\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx" -Mode Full

# यदि diskpart का उपयोग कर रहे हैं
diskpart
# निम्न प्रॉम्प्ट के भीतर इंटरैक्टिव रूप से दर्ज करें
DISKPART> select vdisk file="C:\Users\<username>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx"
DISKPART> attach vdisk readonly
DISKPART> compact vdisk
DISKPART> detach vdisk
DISKPART> exit

नियमित रूप से यह ऑपरेशन करके, आप C ड्राइव का बर्बाद हुआ स्पेस वापस पा सकते हैं।

10. निष्कर्ष

WSL2 “Windows पर चलने वाले एक बोनस Linux” से कहीं आगे बढ़कर एक शक्तिशाली डेवलपमेंट प्लेटफ़ॉर्म के रूप में विकसित हो गया है जो MacOS और नेटिव Linux मशीनों के बराबर या उससे बेहतर है।

यहां बताई गई सभी सेटिंग्स को लागू करके (.wslconfig के माध्यम से रिसोर्स ऑप्टिमाइज़ेशन, Zsh + Powerlevel10k के साथ टर्मिनल एन्हांसमेंट, VS Code Remote के माध्यम से पारदर्शी पहुंच, और SSH एकीकरण और VHDX रखरखाव), एक तनाव-मुक्त, तेज़ और सुरक्षित “अल्टीमेट डेवलपमेंट एनवायरनमेंट” पूरा हो जाएगा।

हालाँकि एनवायरनमेंट को सेट करने में कुछ प्रयास लगता है, एक बार सेटिंग्स पक्की हो जाने के बाद, इसमें कोई संदेह नहीं है कि भविष्य के इंजीनियरिंग कार्यों की उत्पादकता में नाटकीय रूप से सुधार होगा। कृपया इस गाइड को आधार के रूप में उपयोग करके अपने प्रोजेक्ट्स और प्राथमिकताओं के अनुरूप आगे के कस्टमाइज़ेशन का पता लगाने के लिए स्वतंत्र महसूस करें।