Windows ভার্চুয়ালাইজেশনের গভীরতা (পর্ব ৩) — সেকেন্ডে বুট হওয়া ভার্চুয়াল মেশিন: WSL2, Windows Sandbox ও কন্টেইনার এত হালকা কেন

Hyper-V Manager-এ Windows VM তৈরি করলে শুরু হতে কয়েক দশক সেকেন্ড লাগে আর কয়েক গিগাবাইট মেমরি একচেটিয়া করে। অথচ একই PC-এ wsl টাইপ করলে কয়েক সেকেন্ডে Linux শেল ফেরে, আর Windows Sandboxও কয়েক সেকেন্ডে ডিসপোজেবল ডেস্কটপ খোলে।¹

দুটোই একই Windows হাইপারভাইজারের উপর দাঁড়ায় (পর্ব ১, “আপনার Windows আসলে কোথায় চলছে?”)। পর্ব ২-এ দেখেছি এই ভিত্তি কার্নেলের চেয়ে শক্তিশালী আইসোলেশন তৈরি করতে পারে। তাহলে একটি ভারী আর অন্যটি হালকা কেন?

সিরিজের শেষ কিস্তি যে প্রশ্নের উত্তর দেয় তা একটিই।

পূর্ণ VM ভারী — তাহলে WSL2 ও Windows Sandbox এত হালকা কেন?

উদ্দিষ্ট পাঠক সেই ডেভেলপার ও অপারেটর যারা ডেভেলপমেন্ট ও যাচাইয়ে WSL2, Windows Sandbox ও Windows কন্টেইনার ব্যবহার করেন, আর তাদের হালকাতা ও সীমা যন্ত্র থেকে বুঝতে চান। পূর্বশর্ত Windows 10/11; Windows Sandbox অনুচ্ছেদ ঘুরে দেখতে Pro, Enterprise বা Education সংস্করণ দরকার (Home ও Windows Server-এ এই বৈশিষ্ট্য নেই)। পটভূমি জ্ঞান পর্ব ১-এর পার্টিশনের ধারণা। কঠিনতা মাঝারি।

১. আগে উপসংহার

হালকা 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["হালকা কার্নেল + ন্যূনতম"]

চিত্র ১: “একই হাইপারভাইজার, তবু হালকা”-এর উত্তরের কঙ্কাল তারা আইসোলেট করা বন্ধ করেনি, ডুপ্লিকেট করা বন্ধ করেছে।

নিচে WSL2, Windows Sandbox ও কন্টেইনার সেই ক্রমে দেখি, আর প্রত্যেকে কোন ধরনের ডুপ্লিকেশন কাটে।

২. পূর্ণ 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["কয়েক দশক সেকেন্ড লাগে"]

চিত্র ২: পূর্ণ VM-এর খরচের ভাঙন আইসোলেশনের জন্য নয়, সাধারণতা ও ডুপ্লিকেশনের জন্য মেটে।

এগুলো ত্রুটি নয়; “গেস্টে যেকোনো কিছু রাখা যায়” সাধারণতার দাম। Windows Server-এর পাশে পুরোনো Linux চালানোর মতো ব্যবহারে সেই সাধারণতাই মূল্য। কিন্তু “হোস্টের মতোই (বা পূর্বনির্ধারিত) OS এখনই ডেভেলপমেন্ট বা যাচাইয়ে চালাতে চাই” ব্যবহারে বেশিরভাগই অপচয় বোঝা। হালকা VM উদ্দেশ্য সংকুচিত করে সেই বোঝা নামায়।

৩. WSL2 — উদ্দেশ্য-নির্মিত কার্নেলের ইউটিলিটি VM

৩.১. কাঠামো: পরিচালিত VM ও তার ভেতরের ডিস্ট্রিবিউশন

WSL2 সেই যন্ত্র যা আসল Linux কার্নেল হালকা ইউটিলিটি VM-এর ভেতরে চালায়।³ তিনটি বিষয়।

• কার্নেল আসল, কিন্তু বিশেষায়িত পণ্য। Microsoft Stable ব্রাঞ্চ থেকে তৈরি 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 <-->|"ইন্টারঅপ（কমান্ড, ফাইল, নেটওয়ার্ক）"| uvm

চিত্র ৩: “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

চিত্র ৪: অপেক্ষা শুধু ন্যূনতম VM স্টার্ট, আর এখানেই পূর্ণ বুটের বোঝা নামানো দেখা যায়।

৩.২. ফাইল I/O: কোন পাশে রাখলে আলাদা জিনিস হয়ে যায়

WSL2 পারফরম্যান্সের আলোচনায় সবসময় যে বিষয় ওঠে তা ফাইল কোথায় রাখবেন।

• Linux পাশের ফাইলে (ext4 ভার্চুয়াল ডিস্ক) অপারেশন দ্রুত। কারণ Linux কার্নেল নিজের ফাইল সিস্টেমের সাথে সরাসরি কথা বলে, আর tarball এক্সট্রাকশনে WSL1-এর তুলনায় ২০ গুণ পর্যন্ত, আর git clone ও npm install-এ ২–৫ গুণ গতিবৃদ্ধি রিপোর্ট হয়েছে।⁴
• 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-এর তুলনায় ২০ গুণ পর্যন্ত উদাহরণ）"]
    p9 --> slow["ধীর হতে থাকে"]
    slow -.-> fix["সমাধান: ফাইল যে OS ব্যবহার করে সেখানে রাখুন"]

চিত্র ৫: যা ধীর তা পথ, WSL2 নয়, তাই ফাইল কোথায় রাখবেন বদলালে পারফরম্যান্স সমস্যা প্রায়ই মিলিয়ে যায়।

৩.৩. মেমরি: বাড়ে, কমে, কিন্তু সবসময় সব ফেরায় না

WSL2-এর মেমরি ব্যবহার (টাস্ক ম্যানেজারে 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 সব ফেরায়"]

চিত্র ৬: যা “শুধুই বেড়েছে” মনে হয় তা মূলত ক্যাশ (আর pageReporting বন্ধ থাকলে প্রক্রিয়া-ছাড়া পেজও), তাই লিক সিদ্ধান্ত নেওয়ার আগে ফেরার পথ জানুন।

স্পষ্ট উর্ধ্বসীমা চাইলে %UserProfile%\.wslconfig VM-এর সামগ্রিক মেমরি, CPU সংখ্যা ও সোয়াপ নিয়ন্ত্রণ করতে পারে।⁵

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

সেটিং বদলানোর পর কার্যকর করতে wsl --shutdown দিয়ে VM রিস্টার্ট করুন। এই গতিশীল বরাদ্দ — “উর্ধ্বসীমা সেটিং, আসল ব্যবহার চাহিদা অনুসরণ করে” — পরের বিষয়ে, Windows Sandbox-এ, আরও এগোয়।

৪. Windows Sandbox — হোস্টের Windows পুনর্ব্যবহার

৪.১. ডায়নামিক বেস ইমেজ: ৫০০ MB-এ সম্পূর্ণ Windows

Windows Sandbox হাইপারভাইজার-বিচ্ছিন্ন ডিসপোজেবল Windows ডেস্কটপ। বন্ধ করলে সব মিলিয়ে যায়; পরেরবার পরিষ্কার অবস্থা থেকে কয়েক সেকেন্ডে শুরু হয়।¹

প্রথম ধাঁধা ডিস্ক। সম্পূর্ণ Windows বুট করতে পারে, অথচ Sandbox-এর বেস ইমেজ ইনস্টলের পর মাত্র প্রায় ৫০০ MB, ডিস্ট্রিবিউশন সময়ে সংকুচিত ৩০ 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["সংরক্ষণ করতে হয় মাত্র প্রায় ৫০০ MB"]

চিত্র ৭: ডিস্ক ডুপ্লিকেশন ছেড়ে দেওয়ার রূপ “আরেকটি 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

চিত্র ৮: প্রতিবার পরিষ্কারে ফেরা যায় কারণ পরিবর্তনযোগ্য অংশ ডিসপোজেবল কপি, আর ফেলা ডিজাইনের অংশ।

৪.২. ডাইরেক্ট ম্যাপ: একই ntdll.dll একই ফিজিক্যাল পেজ

শুধু ডিস্ক নয়, RAMও ভাগ হয়। Sandbox হোস্টের মতোই একই OS ইমেজ চালায় বলে “ডাইরেক্ট ম্যাপ” নামের কৌশল ব্যবহার হয় যাতে OS বাইনারির জন্য হোস্টের একই ফিজিক্যাল মেমরি পেজ ব্যবহার করে। Sandbox-এর ভেতরে ntdll.dll মেমরিতে লোড হলে হোস্টে ইতিমধ্যে লোড থাকা একই বাইনারির একই ফিজিক্যাল পেজের দিকে নির্দেশ করে। হোস্টের গোপন জিনিস বিপদে না ফেলে পুরোনো VM-এর চেয়ে অনেক ছোট মেমরি ফুটপ্রিন্ট অর্জন করে।²

“একই ফিজিক্যাল পেজ কয়েকজন ব্যবহারকারীর মধ্যে ভাগ” — সেটা সেকশন অবজেক্ট দিয়ে DLL শেয়ারিংয়ের একই ধারণা, যা মেমরি সিরিজের পর্ব ৩-এ অনুসরণ করেছিলাম (“সেকশন অবজেক্ট ও 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 ডুপ্লিকেট করতে হয় না"]

চিত্র ৯: ডাইরেক্ট ম্যাপ সেই পেজ-শেয়ারিং ধারণা যা প্রক্রিয়ার মধ্যে ব্যবহৃত হয়েছে, VM সীমানা পেরিয়ে প্রয়োগ।

৪.৩. মেমরি ধার ও ফেরত: 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-এ সাজানোর উপায় সীমিত"]

চিত্র ১০: মেমরি ধার ও ফেরতে Sandbox VM পাশে নয় প্রক্রিয়া পাশে দাঁড়ায়, আর হোস্ট বিপদে মেমরি তুলে দেয়।

পর্ব ১-এ বলেছিলাম “VM-এর পারফরম্যান্স হোস্ট পাশের উপরও নির্ভর করে”, কিন্তু হালকা VM-এ আরও এক ধাপ: মেমরি বরাদ্দ নিজেই হোস্টের সাথে যৌথ কাজ। Sandbox “ভারী ভার্চুয়ালাইজেশন পণ্য” নয় “আরেকটি অ্যাপ” অনুভূতিতে ব্যবহার করা যায় কারণ এই সহযোগিতা।

ব্যবসায়িক অ্যাপ যাচাইয়ে Sandbox ব্যবহারের কংক্রিট পদ্ধতি আগের “Windows Sandbox দিয়ে অ্যাপ যাচাই কীভাবে দ্রুত করবেন“-এ আছে। এই নিবন্ধ তার তলার যন্ত্র।

৫. কন্টেইনার — আইসোলেশন রেখা কোথায় আঁকবেন

৫.১. প্রসেস আইসোলেশন ও Hyper-V আইসোলেশন

Windows কন্টেইনারের রান টাইমে দুটি আইসোলেশন মোড আছে। ইমেজ ভাগ; শুরুতে ফ্ল্যাগ দিয়ে বেছে নেন।⁷

• প্রসেস আইসোলেশন: কয়েকটি কন্টেইনার হোস্টের সাথে কার্নেল ভাগ করে এবং ফাইল সিস্টেম, রেজিস্ট্রি, নেটওয়ার্ক পোর্ট, প্রক্রিয়া-ID স্পেস, Object Manager নেমস্পেস ইত্যাদির নেমস্পেস-প্রতি ভার্চুয়ালাইজেশন দিয়ে আলাদা করে। Linux কন্টেইনারের সাথে মূলত একই পথ।
• Hyper-V আইসোলেশন: প্রতিটি কন্টেইনার উচ্চ-অপ্টিমাইজড VM-এর ভেতরে চলে এবং কার্যত নিবেদিত কার্নেল পায়। VM-এর উপস্থিতি কন্টেইনার ও হোস্টের মধ্যে হার্ডওয়্যার-স্তর আইসোলেশন রাখে।⁷

নেমস্পেস দিয়ে আইসোলেশনকে রেজিস্ট্রি ভার্চুয়ালাইজেশন নিবন্ধে দেখা কৌশলের (“Windows-এ রেজিস্ট্রি রিডাইরেকশন ও ভার্চুয়ালাইজেশন”) পূর্ণাঙ্গ সংস্করণ বলা যায় — “একই 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

চিত্র ১১: একই কন্টেইনার ইমেজ থাকলেও আইসোলেশন রেখা কার্নেলের উপরে আঁকবেন নাকি কার্নেল নিজে ভাগ করবেন তা শুরুতেই বেছে নেন।

৫.২. কোনটিকে “নিরাপত্তা সীমানা” বলা যায়

এই দুই মোডের পার্থক্য শুধু পারফরম্যান্সের গল্প নয়। Microsoft প্রসেস-আইসোলেটেড কন্টেইনারকে মজবুত নিরাপত্তা সীমানা মনে করে না। নিরাপত্তা সীমানা হিসেবে রক্ষণাবেক্ষণ করা (দুর্বলতা সাড়াসহ) কন্টেইনার হাইপারভাইজার-আইসোলেটেড কন্টেইনার, আর প্রতিকূল মাল্টি-টেন্যান্ট পরিস্থিতিতে Hyper-V আইসোলেশনই বেছে নেওয়া উচিত।⁸

পর্ব ২-এ দেখা VBSও সেই ডিজাইন যা “কার্নেল ভাঙতে পারে” ধরে হাইপারভাইজার সীমানায় সরে। একই মাপকাঠি কন্টেইনারের জগতেও প্রযোজ্য। অবিশ্বস্ত কোড আটকানোর রেখা হাইপারভাইজার সীমানায় আঁকা হয়, ভাগ করা কার্নেলের ভেতরে নয়।

flowchart TB
    accTitle: কোড কতটা বিশ্বাস করেন তা থেকে আইসোলেশন বেছে নেওয়া
    accDescr: ওয়ার্কলোড বিশ্বস্ত হলে প্রসেস আইসোলেশন দিয়ে ঘনত্ব ও পারফরম্যান্স নিন; কোড অবিশ্বস্ত বা অন্য কারও হলে Hyper-V আইসোলেটেড কন্টেইনার, নেটওয়ার্ক নিষ্ক্রিয় করা শক্তিশালী Windows Sandbox, অথবা বিচ্ছিন্ন VM-এর মতো হাইপারভাইজার সীমানা বেছে নিন
    trust{"সেই কোড বিশ্বাস করা যায়?"} -->|হ্যাঁ| dens["প্রসেস আইসোলেশন（ঘনত্ব ও গতি আগে）"]
    trust -->|না / অন্য কারও কোড| bound["হাইপারভাইজার সীমানা বেছে নিন"]
    bound --> opt1["Hyper-V আইসোলেটেড কন্টেইনার"]
    bound --> opt2["শক্তিশালী Sandbox বা বিচ্ছিন্ন VM"]

চিত্র ১২: আইসোলেশন মোড পারফরম্যান্সের আগে নিরাপত্তার গল্প, আর বিশ্বাস ঠিক করে রেখা কোথায় আঁকবেন।

প্রসঙ্গত, Hyper-V VM-এর ভেতরে Hyper-V আইসোলেটেড কন্টেইনার চালালে হাইপারভাইজার দুই স্তর গভীর হয় — নেস্টেড ভার্চুয়ালাইজেশন। শর্ত পূরণ করা পরিবেশে এক স্তর নেস্টিং প্রোডাকশনে সমর্থিত (Intel প্রসেসর ও Windows 10 / Windows Server 2016 বা পরের হোস্ট, অথবা AMD প্রসেসর ও Windows 11 / Windows Server 2022 বা পরের হোস্ট, আর প্রতিটি ক্ষেত্রে সংশ্লিষ্ট VM কনফিগারেশন সংস্করণ), আর আরও একটি পূর্বশর্ত বাইরের VM-এ ভার্চুয়ালাইজেশন এক্সটেনশন প্রকাশ করার সেটিং (Set-VMProcessor-এ ExposeVirtualizationExtensions)। VM-এর ভেতরে WSL2 চালানো একইভাবে সমর্থিত।⁹ ক্লাউডের ডেভেলপমেন্ট VM-এ WSL2 বা Docker ব্যবহার করা যাবে কি নাও সেই VM সাইজ ও কনফিগারেশন নেস্টেড ভার্চুয়ালাইজেশন প্রকাশ করে কি না তাই ঠিক করে।

flowchart TB
    accTitle: নেস্টেড ভার্চুয়ালাইজেশনের কাঠামো
    accDescr: ক্লাউড VM ফিজিক্যাল হোস্টের হাইপারভাইজারের উপর বসে, আর তার ভেতরে আরেকটি হাইপারভাইজার（সমর্থিত নেস্টিং এক স্তর）WSL2 ও Hyper-V আইসোলেটেড কন্টেইনার সমর্থন করতে চলে
    phys3["ফিজিক্যাল হোস্টের হাইপারভাইজার"] --> cvm["ক্লাউড VM（ডেভ মেশিন）"]
    cvm --> nhv["VM-এর ভেতরের হাইপারভাইজার（নেস্টিং স্তর ১）"]
    nhv --> w2["WSL2"]
    nhv --> hvc["Hyper-V আইসোলেটেড কন্টেইনার"]
    nhv -.-> limit["সমর্থিত নেস্টিং এক স্তর"]

চিত্র ১৩: ক্লাউড VM-এর ভেতরে wsl চলে কারণ নেস্টেড ভার্চুয়ালাইজেশন অফিসিয়ালি শুধু এক স্তরের জন্য সমর্থিত।

৫.৩. আইসোলেশন ও হালকাতার বর্ণালী

এখন পর্যন্ত কাস্টকে একটি অক্ষে সাজালে এমন দেখায়।

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["সীমানা: হাইপারভাইজার + সম্পূর্ণ স্বাধীনতা"]

চিত্র ১৪: হালকা-VM দল সেই মাঝামাঝি সমাধান যা হাইপারভাইজার সীমানা রেখে ডুপ্লিকেশন কেটেছে; কাটার উপায় Sandbox-এ ভাগ ও WSL2-এ উদ্দেশ্য-নির্মিত কার্নেলে ভাগ হয়।

৬. নিজে দেখুন

হালকাতা ও ভাগ সামনের মেশিনে পর্যবেক্ষণ করা যায়।

স্টার্টআপ সময় ও মেমরির ওঠানামা (WSL2)। টাস্ক ম্যানেজার খোলা রেখে নিচেরগুলো চেষ্টা করুন।

# 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 বা এক্সট্রাকশনের সময় তুলনা করুন, আর অনুচ্ছেদ ৩.২-এর পার্থক্য সংখ্যায় দেখা যায়।

ডাইরেক্ট ম্যাপের পটভূমি (Sandbox)। Sandbox শুরু করে হোস্টে টাস্ক ম্যানেজারে মেমরির বৃদ্ধি দেখুন। বৃদ্ধি “আরেকটি Windows” কল্পনা করলে যা ভাবা যায় তার চেয়ে অনেক ছোট থাকা ভাগের প্রভাবই গল্প বলে। হোস্ট-পাশের মেমরি ভাঙনে আরও খুঁজতে RAMMap ও VMMap ব্যবহার ঢাকা Sysinternals টুলের নিবন্ধ (“Process Explorer / Handle / VMMap ব্যবহারিকভাবে”) কাজে লাগে। তবে এগুলো হোস্ট-পাশের প্রক্রিয়া ও ফিজিক্যাল মেমরির শ্রেণি দেখার টুল; গেস্টের সাথে ভাগ সরাসরি পর্যবেক্ষণ করে না।

কন্টেইনার আইসোলেশন মোড (Docker / Windows কন্টেইনার)। Windows কন্টেইনার পরিবেশ থাকলে একই ইমেজ docker run --isolation=process ও --isolation=hyperv দিয়ে শুরু করে স্টার্টআপ সময় ও টাস্ক ম্যানেজারে কেমন দেখায় তুলনা করুন (প্রসেস আইসোলেশনে কন্টেইনারের ভেতরের প্রক্রিয়া হোস্টের প্রক্রিয়া তালিকায় দেখা যায়), আর আইসোলেশন রেখা কোথায় বসে অনুভব করা যায়।⁷ তবে প্রসেস আইসোলেশন হোস্ট ও ইমেজ সংস্করণ মেলানো ধরে, আর ক্লায়েন্ট OS-এ ডেভেলপমেন্ট ও পরীক্ষা ব্যবহারে সীমিত। Hyper-V আইসোলেশন আরও বিস্তৃত মিল অনুমোদন করে, তাই তুলনা সামঞ্জস্যপূর্ণ জোড়ায় করুন।¹⁰

৭. ব্যবহারে এড়ানোর তিনটি ভুলপাঠ

৭.১. “WSL2 ধীর”

যা ধীর তা WSL2 নয়, OS সীমানা পেরোনো ফাইল-I/O পথ। প্রজেক্ট Linux পাশে সরালেই অনুভূতি আলাদা জিনিস হয়ে যাওয়ার অনেক কেস আছে।⁴ উল্টোদিকে Windows টুল ছুঁবে এমন ফাইল Linux পাশে রাখা একই কারণে সমান প্রতিকূল। বিচার করুন “যে পাশ ব্যবহার করে সেই OS-এ রাখুন” দিয়ে।

৭.২. “vmmem বড় হয়ে যাওয়া মেমরি লিক”

WSL2 মেমরি চাহিদায় বাড়ে ও কমে, আর ছাড়া অংশ ফেরে। বর্তমান WSL-এ ফাইল ক্যাশও autoMemoryReclaim (ডিফল্ট dropCache) স্বয়ংক্রিয় পুনরুদ্ধার করে, তাই “বড় থেকে গেছে” প্রায়ই সময়ের সাথে সমাধান হয়।⁵ তবু থাকলে নিশ্চিত করুন autoMemoryReclaim disabled করা হয়নি এবং ছাড়া অংশ ফেরানোর দায়িত্বে থাকা pageReporting বন্ধ করা হয়নি (অথবা পুরোনো WSL-এ নন), তারপর .wslconfig-এ memory দিয়ে উর্ধ্বসীমা স্পষ্ট করুন অথবা সেশন সীমানায় wsl --shutdown দিয়ে সব ফেরান। লিক ও লিক-নয় আলাদা করার চিন্তা মেমরি সিরিজের পরিচয় কিস্তির মতোই, “Windows-এর “মেমরি ব্যবহার” আসলে কী বোঝায়?“।

৭.৩. “কন্টেইনারে আছে, তাই নিরাপদ”

প্রসেস-আইসোলেটেড কন্টেইনার কার্নেল ভাগ করে, আর Microsoft-এর মাপকাঠিতে নিরাপত্তা সীমানা নয়।⁸ অবিশ্বস্ত কোড বা নমুনা চালাতে Hyper-V আইসোলেটেড কন্টেইনার, Windows Sandbox, অথবা নিবেদিত VM-এর মতো হাইপারভাইজার সীমানাযুক্ত আইসোলেশন বেছে নিন। তবে হাইপারভাইজার সীমানা কম্বল ছাড় নয়। Windows Sandbox-এর ডিফল্ট সেটিংসে নেটওয়ার্ক সংযোগ চালু, আর অবিশ্বস্ত অ্যাপকে অভ্যন্তরীণ নেটওয়ার্কে প্রকাশ করতে পারে।¹ নমুনা চালাতে ব্যবহার করলে .wsb কনফিগারেশন ফাইলে নেটওয়ার্ক ও ক্লিপবোর্ড রিডাইরেকশন নিষ্ক্রিয় করে আইসোলেশন শক্ত করুন, অথবা বিচ্ছিন্ন নেটওয়ার্কে নিবেদিত VM ব্যবহার করুন।

৮. সারসংক্ষেপ — সিরিজ বন্ধ করা

পর্ব ৩-এর বিষয়গুলো।

• হালকা VM-এর হালকাতা “ডুপ্লিকেশন বন্ধ করা”-এর ফল, “আইসোলেশন দুর্বল করা”-এর নয়।
• WSL2 পরিচালিত হালকা ইউটিলিটি VM-এ আসল Linux কার্নেল চালায়, আর ডিস্ট্রিবিউশন সেই VM-এর ভেতরে কন্টেইনার হিসেবে আলাদা।³ পারফরম্যান্সের নিয়ম ফাইল যে OS ব্যবহার করে সেখানে রাখা, আর মেমরি গতিশীল বাড়ে ও কমে, উর্ধ্বসীমা .wslconfig-এ নিয়ন্ত্রণযোগ্য।⁴⁵
• Windows Sandbox ডায়নামিক বেস ইমেজ দিয়ে হোস্টের অপরিবর্তনীয় OS ফাইল ভাগ করে এবং ডাইরেক্ট ম্যাপ দিয়ে লক্ষ্য OS বাইনারির ফিজিক্যাল পেজও ভাগ করে, তাই সম্পূর্ণ Windows-এর কপি ধরে না।² পরিবর্তনযোগ্য ফাইলের জন্য এখনও প্রায় ৫০০ MB দরকার, প্লাস ভেতরে চালানো অ্যাপের মেমরি।
• কন্টেইনার আইসোলেশন মোড শুরুতে বেছে নেওয়া হয়, আর নিরাপত্তা সীমানা বলা যায় সেই পাশ Hyper-V আইসোলেশন।⁷⁸

আর পুরো সিরিজ এক পাতায় রাখলে এমন দেখায়।

• পর্ব ১: Windows-এর তলায় হাইপারভাইজার স্তর আছে, আর হোস্ট OS নিজেই রুট পার্টিশন হিসেবে চলে। CPU ও মেমরির (SLAT) সালিশি এই স্তর সরাসরি করে, আর সিন্থেটিক ডিভাইসের I/O VMBus-এর ওপারে রুট পার্টিশন (VSP) মধ্যস্থতা করে।
• পর্ব ২: সেই স্তর শুধু VM পরস্পর থেকে আলাদা করতে নয়, একই OS-এর ভেতরে কার্নেলের চেয়ে শক্তিশালী সীমানা (VTL) আঁকতেও ব্যবহৃত হয়। Windows 11-এর ডিফল্ট নিরাপত্তা এর উপর গড়া।
• পর্ব ৩: একই স্তরে ডুপ্লিকেশন কাটাই “সেকেন্ডে শুরু হওয়া ভার্চুয়াল মেশিন” সম্ভব করে। আইসোলেশন রেখা রাখা হয়েছে, আর তা দৈনন্দিন হাতিয়ার হয়ে উঠেছে।

flowchart TB
    accTitle: পুরো সিরিজের একটি ছবি
    accDescr: হার্ডওয়্যারের উপর সরাসরি হাইপারভাইজার পর্ব ১; হোস্ট Windows-এর ভেতরে VTL0 ও VTL1-এর ভাগ পর্ব ২; একই স্তরে WSL2, Sandbox ও Hyper-V আইসোলেশনের হালকাতা পর্ব ৩; প্রসেস-আইসোলেটেড কন্টেইনার হোস্ট কার্নেল ভাগ করে; Sandbox ভাগ করে হালকা করে, WSL2 উদ্দেশ্য-নির্মিত কার্নেল দিয়ে
    hw3["হার্ডওয়্যার"] --> hv3["হাইপারভাইজার（পর্ব ১）"]
    hv3 --> rp3["হোস্ট Windows（VTL আইসোলেশন পর্ব ২）"]
    hv3 --> lw3["WSL2, Sandbox, Hyper-V আইসোলেশন（পর্ব ৩）"]
    rp3 --> pc3["প্রসেস-আইসোলেটেড কন্টেইনার（ভাগ করা কার্নেল）"]
    lw3 -.-> mech3["Sandbox ভাগ করে; WSL2 উদ্দেশ্য-নির্মিত কার্নেল দিয়ে হালকা করে"]

চিত্র ১৫: তিন কিস্তি স্তূপ করলে বর্তমান Windows-এর তলার সামগ্রিক ছবি পাওয়া যায়।

ভার্চুয়ালাইজেশন আর সার্ভার-রুমের প্রযুক্তি নয়, শুধু VM দাঁড় করানো মানুষের প্রযুক্তিও নয়। আপনার Windows-এর তলায় এটি নিঃশব্দে নিরাপত্তা ও ডেভেলপমেন্ট অভিজ্ঞতা দুটোই ধরে — আমরা এখন সেখানেই আছি।

সম্পর্কিত নিবন্ধ

• Windows ভার্চুয়ালাইজেশনের গভীরতা (পর্ব ১) — আপনার Windows আসলে কোথায় চলছে? হাইপারভাইজার ও পার্টিশন
• Windows ভার্চুয়ালাইজেশনের গভীরতা (পর্ব ২) — কার্নেলও দেখতে পায় না এমন মেমরি: VBS, HVCI ও Credential Guard কীভাবে কাজ করে
• Windows মেমরির গভীরতা (পর্ব ৩) — সেকশন অবজেক্ট ও Copy-on-Write: DLL ও ফাইল ম্যাপিং আসলে কী
• Windows Sandbox দিয়ে অ্যাপ যাচাই কীভাবে দ্রুত করবেন
• রেজিস্ট্রি ৩২-বিট/৬৪-বিট রিডাইরেকশন ও ভার্চুয়ালাইজেশনের ফাঁদ — Wow6432Node ও “আমি যে মান লিখেছি সেটা নেই” সমস্যা

সম্পর্কিত পরামর্শ ক্ষেত্র

KomuraSoft LLC WSL2 ও কন্টেইনার ব্যবহার করা ডেভেলপমেন্ট পরিবেশ গোছানো, Windows অ্যাপ যাচাই পরিবেশ ডিজাইন, আর ভার্চুয়ালাইজড পরিবেশে পারফরম্যান্স ও সামঞ্জস্য অনুসন্ধান সামলায়।

• 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 সফটওয়্যার ডেভেলপমেন্ট, প্রযুক্তিগত পরামর্শ ও বাগ তদন্তে বিশেষজ্ঞ, বিশেষ করে বিদ্যমান সিস্টেমযুক্ত প্রকল্প ও পুনরুৎপাদন করা কঠিন বাগে।