أعماق الافتراضيّة في Windows (الجزء 3) ── آلات افتراضيّة تقلع في ثوانٍ: لماذا WSL2 وWindows Sandbox والحاويات خفيفة هكذا

آلة افتراضيّة كاملة ثقيلة، فلماذا WSL2 وWindows Sandbox خفيفان؟ يشرح الجزء الأخير من هذه السلسلة الفرق لا من «ما يُعزَل» فحسب، بل من «ما لا يجب تكراره».

عندما تُنشئ آلة Windows افتراضيّة في Hyper-V Manager، يستغرق البدء عشرات الثواني وتحجز عدّة غيغابايت من الذاكرة. على الحاسوب نفسه، كتابة wsl تعيد صدفة Linux خلال ثوانٍ، ويفتح Windows Sandbox أيضاً سطح مكتب قابلاً للرمي في ثوانٍ.¹

الأساس في كلّ حالة هو hypervisor Windows الذي رأيناه في الجزء 1. في الجزء 2 أكّدنا أنّ هذا الأساس يستطيع بناء عزل أقوى من النواة. ينظر هذا المقال منفصلاً إلى تخصّص WSL2، ومشاركة Sandbox، وأوضاع عزل الحاويات.

«أعماق الافتراضيّة في Windows» ── الأجزاء الثلاثة كلّها

ننظر إلى hypervisor Windows نفسه بترتيب الأساس → عزل الأمان → التطبيق على آلات افتراضيّة خفيفة.

مقدّمات هذا المقال

كيف تقرأ هذا المقال

1. الخلاصة أوّلاً

آلة افتراضيّة خفيفة تُبقي خطّ العزل (نواة مخصَّصة وحدّ الـ hypervisor) وتخفِّف «نسخة نظام تشغيل ضيف كاملة». يشارك Sandbox Windows المضيف نفسه، ويستبدل WSL2 الضيف بـ Linux صغير مبنيّ للغرض، وفي الحالتين ليست الذاكرة حجزاً ثابتاً بل تُشارَك ديناميّاً مع المضيف.

مصدر ثقل آلة افتراضيّة كاملة ليس العزل نفسه بل التكرار: صورة نظام تشغيل أخرى على القرص، ما يعادل نظام تشغيل آخر من الصفحات في RAM، وإقلاع كامل آخر في كلّ مرّة تبدأ. تقتطع الآلات الافتراضيّة الخفيفة هذا التكرار بسياستين: «شارك ما هو آمن للمشاركة» (Sandbox) و«إن تعذّرت المشاركة، أعد بناءه صغيراً» (WSL2).

flowchart TB
    accTitle: أنواع المشاركة الثلاثة وراء الآلات الافتراضيّة الخفيفة
    accDescr: صورة نظام التشغيل التي كرّرتها آلة افتراضيّة كاملة تُقطَع بالمشاركة في Sandbox وبالتصغير في WSL2، والذاكرة التي هي تخصيص ثابت افتراضيّاً (تكوينات Dynamic Memory الاستثناء) تصير إعارة واقتراضاً ديناميّاً مع المضيف، ويُستبدل الإقلاع بنواة خفيفة وتكوين أدنى، فيبقى حدّ العزل فقط
    heavy["مصدر ثقل آلة افتراضيّة كاملة هو التكرار"] --> d1["القرص: صورة نظام تشغيل مكرَّرة"]
    heavy --> d2["الذاكرة: تخصيص ثابت افتراضيّاً"]
    heavy --> d3["الإقلاع: إقلاع كامل آخر"]
    d1 -->|يُستبدل بـ| s1["مشاركة (Sandbox) أو تصغير (WSL2)"]
    d2 -->|يُستبدل بـ| s2["تُعار وتُقتَرَض ديناميّاً مع المضيف"]
    d3 -->|يُستبدل بـ| s3["يُقصَّر بنواة خفيفة وتكوين أدنى"]

الشكل 1: توقّفوا عن التكرار لا عن العزل، وذلك هيكل الجواب عن «الـ hypervisor نفسه، ومع ذلك خفيف».

أدناه ننظر إلى WSL2 وWindows Sandbox والحاويات بهذا الترتيب، وإلى أيّ تكرار يقتطعه كلّ منها.

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 19، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. ما تحمله آلة افتراضيّة كاملة

خطّ أساس للمقارنة، هذا ما تحمله آلة افتراضيّة تقليديّة.

• صورة نظام تشغيل مستقلّة. تمسك كلّ ملفّات نظام تشغيل الضيف داخل قرص افتراضي. حتّى إن شغَّل المضيف Windows نفسه، لا يُشارَك شيء.
• تخصيص ذاكرة خشن. تخصِّص آلة افتراضيّة تقليديّة ذاكرة المضيف بحجم ثابت افتراضيّاً. ثمّة آليّات مثل Hyper-V Dynamic Memory تنمو التخصيص وتنكمشه ضمن نطاق مضبوط، لكنّ وسائل التكيّف مع تغيّرات الطلب محدودة.²
• إقلاع كامل عامّ الغرض. يبدأ البرنامج الثابت ومحمِّل الإقلاع والخدمات بالمتتالية نفسها كما على جهاز فيزيائيّ.

flowchart TB
    accTitle: الأحمال الثلاثة التي تحملها آلة افتراضيّة كاملة
    accDescr: تحمل آلة افتراضيّة كاملة صورة نظام تشغيل مستقلّة وتخصيص ذاكرة ثابت افتراضيّاً وإقلاعاً كاملاً عامّ الغرض، وتظهر هذه تكاليف في القرص وRAM وزمن الإقلاع
    fullvm["آلة افتراضيّة كاملة"] --> b1["صورة نظام تشغيل مستقلّة"]
    fullvm --> b2["تخصيص ذاكرة ثابت افتراضيّاً"]
    fullvm --> b3["إقلاع كامل عامّ الغرض"]
    b1 -.-> c1["يستهلك قرصاً للنسخة المكرَّرة"]
    b2 -.-> c2["تميل إلى إمساك RAM لا تستخدمها"]
    b3 -.-> c3["يستغرق عشرات الثواني للبدء"]

الشكل 2: كلّ بند في تفصيل تكلفة آلة افتراضيّة كاملة يُدفَع للعموميّة والتكرار، لا للعزل.

هذه ليست عيوباً؛ إنّها ثمن عموميّة إمكان وضع أيّ شيء في الضيف. لاستخدام كتشغيل Linux قديم بجانب Windows Server، تلك العموميّة هي القيمة بالضبط. لكن عندما تكون الحاجة «شغِّل نظام التشغيل نفسه كالمضيف (أو ثابتاً) الآن، للتطوير أو التحقّق»، فمعظمه ثقل ميّت. تضع الآلات الافتراضيّة الخفيفة ذلك العتاد جانباً بتضييق غرضها.

3. WSL2 ── آلة افتراضيّة خدميّة تحمل نواة مبنيّة للغرض

أسهل تتبّع لـ WSL2 بترتيب البنية → أين تعيش الملفّات → إعادة الذاكرة. استخدام نواة Linux أصيلة ومعالجة ملفّات جانب Windows بسرعة أمران منفصلان.

3.1. البنية: آلة افتراضيّة مُدارة والتوزيعات داخلها

WSL2 آليّة تشغِّل نواة Linux أصيلة داخل آلة افتراضيّة خدميّة خفيفة.³ ثلاث نقاط.

النواة أصيلة، لكنّها متخصّصة

هي نواة Linux تبنيها Microsoft من فرع Stable، مضبوطة في الحجم والأداء لـ WSL2. بالمعيار الحالي، WSL الموزَّع عبر Microsoft Store، تُحدَّث النواة مع حزمة WSL نفسها وتُطبَّق بـ wsl --update (كان التوزيع الأقدم داخل الصندوق يتلقّاها عبر Windows Update).⁴

لأنّها نواة أصيلة، توافق استدعاءات النظام كامل، وتعمل أدوات مثل Docker كما هي.

الآلة الافتراضيّة تبقى خلف الكواليس

تدير WSL إنشاء الآلة الافتراضيّة وبدءها وإيقافها؛ المستخدم يفتح صدفة فحسب. لا شاشة إعدادات آلة افتراضيّة ولا انتظار محسوس لإقلاع.⁴

التوزيعات حاويات داخل الآلة الافتراضيّة

كلّ توزيعة، كـ Ubuntu أو Debian، تعمل حاوية معزولة داخل آلة افتراضيّة مُدارة واحدة. تشارك مساحة أسماء الشبكة والنواة، بينما تُفصَل مساحات أسماء مثل PID وmount والمستخدم.³

flowchart TB
    accTitle: هندسة WSL2
    accDescr: يجلس Windows المضيف وآلة افتراضيّة خدميّة خفيفة جنباً إلى جنب على الـ hypervisor، وتعمل نواة Linux تبنيها Microsoft داخل الآلة الافتراضيّة، وتعمل كلّ توزيعة حاوية معزولة داخلها
    hv["الـ hypervisor"] --> host["Windows المضيف"]
    hv --> uvm["آلة افتراضيّة خدميّة خفيفة"]
    uvm --> lk["نواة Linux (بناء Microsoft، تُحدَّث بـ wsl --update)"]
    lk --> u1["Ubuntu (حاوية)"]
    lk --> u2["Debian (حاوية)"]
    host <-->|"Interop (أوامر، ملفّات، شبكة)"| uvm

الشكل 3: جواب «هل WSL2 آلة افتراضيّة؟» هو «نعم، لكن آلة افتراضيّة مُدارة تبقى بعيداً عن النظر»، وحتّى مع تثبيت عدّة توزيعات ما تزال ثمّة آلة افتراضيّة واحدة فقط.

هذا ما يحدث خلف الكواليس لحظة كتابة wsl.

flowchart TB
    accTitle: من تشغيل أمر wsl إلى عودة صدفة في ثوانٍ
    accDescr: عندما يعمل wsl، تُبدأ الآلة الافتراضيّة الخفيفة ونواة Linux إن لم تكن الآلة الخدميّة تعمل بعد، وتُستخدَم الآلة القائمة كما هي إن كانت تعمل، وتعود صدفة في حاوية التوزيعة
    cmd["شغِّل wsl"] --> vmq{"هل الآلة الخدميّة تعمل أصلاً؟"}
    vmq -->|لا| bootvm["ابدأ الآلة الخفيفة ونواة Linux (ثوانٍ)"]
    vmq -->|نعم| reuse["استخدم الآلة العاملة كما هي"]
    bootvm --> shell["تعود صدفة داخل الحاوية"]
    reuse --> shell

الشكل 4: الانتظار ليس أكثر من بدء آلة افتراضيّة أدنى، وهنا يؤتي وضع عتاد الإقلاع الكامل جانباً أكله.

3.2. إدخال/إخراج الملفّات: أيّ جانب تعيش عليه الملفّات يصنع الفرق كلّه

موضع الملفّات يظهر في كلّ نقاش لأداء WSL2.

• عمليّات الملفّات في جانب Linux (القرص الافتراضي ext4) سريعة. تعالج نواة Linux نظام ملفّاتها مباشرة، وقد أُبلِغ عن تسريعات تصل إلى 20 ضعفاً مقابل WSL1 لاستخراج tarball و2 إلى 5 أضعاف لـ git clone وnpm install.⁴
• عمليّات الملفّات في جانب Windows (/mnt/c وما شابه) أبطأ لأنّها تمرّ بمشاركة ملفّات تعبر حدّ نظام التشغيل. الأداء عبر أنظمة ملفّات أنظمة التشغيل هو المجال الرئيس الوحيد الذي يتخلّف فيه WSL2 عن WSL1.⁴

لذا القاعدة: ضع ملفّات المشروع في جانب نظام التشغيل نفسه الذي تستخدمه الأدوات التي تعمل عليها.⁴ مستودع تعالجه أدوات بناء Linux يذهب إلى جانب Linux؛ وحلّ يُبنى في Visual Studio يذهب إلى جانب Windows.

flowchart TB
    accTitle: التفرّع في مسارات إدخال/إخراج ملفّات WSL2
    accDescr: الوصول إلى القرص الافتراضي ext4 في جانب Linux سريع لأنّ نواة Linux تصله مباشرة، بينما الوصول إلى ملفّات جانب Windows بطيء لأنّه يمرّ بمشاركة ملفّات تعبر حدّ نظام التشغيل
    io["عمليّة ملفّ داخل WSL2"] --> place{"في أيّ جانب الملفّ؟"}
    place -->|"جانب Linux (دليل home، إلخ)"| ext4["إدخال/إخراج مباشر إلى القرص الافتراضي ext4"]
    place -->|"جانب Windows (/mnt/c، إلخ)"| p9["عبر مشاركة تعبر حدّ نظام التشغيل"]
    ext4 --> fast["سريع (حتّى 20 ضعفاً مقابل WSL1 في مثال)"]
    p9 --> slow["يميل إلى البطء"]
    slow -.-> fix["الإصلاح: ضع الملفّ على نظام التشغيل الذي يستخدمه"]

الشكل 5: ما هو بطيء هو المسار لا WSL2، لذا مجرّد تغيير مكان الملفّات غالباً ما يجعل مشكلة الأداء تختفي.

3.3. الذاكرة: تنمو، تنكمش، لكنّها لا تعيد كلّ شيء

استخدام ذاكرة WSL2 (ظاهر بوصفه عمليّة vmmem في مدير المهام) ليس حجزاً ثابتاً؛ ينمو وينكمش مع الاستخدام.

إعادة الذاكرة التي أطلقتها العمليّات

الذاكرة التي أطلقتها العمليّات تُعاد إلى Windows تلقائيّاً تحت إعداد pageReporting، المفعَّل افتراضيّاً.⁵

استرداد ذاكرة التخزين المؤقّت للملفّات

صفحات ممسوكة ذاكرة تخزين مؤقّت للملفّات لم تكن تعود إلى Windows حتّى تخرج الآلة الافتراضيّة.⁴ في WSL الحالي، يستردّ إعداد .wslconfig التجريبي autoMemoryReclaim (الافتراضي dropCache) ذاكرة التخزين المؤقّت تلقائيّاً أيضاً.⁵

في بيئات يكون فيها هذا الإعداد disabled، أو على WSL أقدم، يمكن أن تبقى ذاكرة التخزين المؤقّت من جلسة طويلة حتّى تخرج الآلة الافتراضيّة وتضغط على ذاكرة المضيف.

flowchart TB
    accTitle: كيف تنمو ذاكرة WSL2 وتنكمش وتُعاد
    accDescr: ارتفاع الطلب داخل WSL2 يرفع استخدام ذاكرة الآلة الافتراضيّة، والذاكرة التي تطلقها العمليّات تُعاد إلى Windows تحت pageReporting المفعَّل افتراضيّاً، وذاكرة التخزين المؤقّت للملفّات تُستردّ تلقائيّاً بـ autoMemoryReclaim افتراضيّاً، لكن مع تعطيلها أو على WSL أقدم تبقى حتّى تخرج الآلة، ويعيد wsl shutdown كلّ شيء
    grow["ينمو طلب الذاكرة داخل WSL2"] --> vm["ينمو استخدام vmmem"]
    vm --> freed{"هل أُطلقت تلك الصفحة؟"}
    freed -->|"أطلقتها عمليّة (مع pageReporting مفعَّل)"| ret["تُعاد إلى Windows تلقائيّاً"]
    freed -->|ممسوكة ذاكرة تخزين مؤقّت للملفّات| amr["تُستردّ تلقائيّاً بـ autoMemoryReclaim (الافتراضي)"]
    amr -.-> old2["تبقى حتّى تخرج الآلة إن عُطِّل أو على WSL أقدم"]
    old2 --> sd["يعيد wsl --shutdown كلّ شيء"]

الشكل 6: ما يبدو «لا ينمو إلّا» هو أساساً ذاكرة التخزين المؤقّت (ومع pageReporting معطَّل تبقى أيضاً الذاكرة التي أطلقتها العمليّات)، لذا تعلّم مسارات الإعادة قبل أن تسمّيه تسرّباً.

ضبط سقف للذاكرة

إن أردت سقفاً صريحاً، يتحكّم %UserProfile%\.wslconfig في الذاكرة وعدد المعالجات وswap للآلة الافتراضيّة ككلّ.⁵

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

بعد تغيير الإعدادات، أعد تشغيل الآلة الافتراضيّة بـ wsl --shutdown كي تسري. هذا التخصيص الدينامي، حيث يقرِّر إعداد السقف ويقرِّر الطلب الاستخدام الفعلي، يدفعه Windows Sandbox الذي يأتي بعد ذلك أبعد.

4. Windows Sandbox ── استخدام Windows المضيف مرّة أخرى

تنقسم خفّة Sandbox إلى ثلاثة أجزاء: مشاركة ملفّات نظام التشغيل على القرص، ومشاركة صفحات نظام التشغيل في RAM، وتنسيق تخصيص الذاكرة مع المضيف.

4.1. الصورة الأساسيّة الديناميّة: Windows كامل في 500 ميغابايت

Windows Sandbox سطح مكتب Windows قابل للرمي معزول بالـ hypervisor. أغلقه فيختفي كلّ شيء؛ وفي المرّة التالية يبدأ في ثوانٍ من حالة نقيّة.¹

اللغز الأوّل هو القرص. يستطيع إقلاع Windows كامل، ومع ذلك صورة Sandbox الأساسيّة نحو 500 ميغابايت فقط بعد التثبيت و30 ميغابايت مضغوطة للتوزيع.² السرّ هو الصورة الأساسيّة الديناميّة.

• معظم ملفّات نظام التشغيل غير قابلة للتغيير ويمكن مشاركتها كما هي من المضيف.
• العدد الصغير فقط من الملفّات القابلة للتغيير لا يمكن مشاركته، لذا تُحفَظ نسخة نظيفة منها داخل الصورة الأساسيّة.
• عند البدء، تُجمَع ملفّات المضيف غير القابلة للتغيير والنسخ المحلّيّة للملفّات القابلة للتغيير في صورة Windows كاملة.²

بعبارة أخرى، لا ينزّل Sandbox نسخة من Windows ولا يخزّنها؛ إنّه يبدأ بـ إعادة استخدام Windows المثبَّت أصلاً على المضيف.

flowchart TB
    accTitle: كيف تُجمَّع الصورة الأساسيّة الديناميّة
    accDescr: تُشارَك ملفّات نظام التشغيل غير القابلة للتغيير من Windows المضيف، وتُحفَظ الملفّات القابلة للتغيير فقط نسخة نظيفة في الصورة الأساسيّة، ويُجمَع الاثنان في صورة Windows الكاملة لـ Sandbox
    hostw["Windows الكامل للمضيف"] --> imm["ملفّات نظام تشغيل غير قابلة للتغيير (الغالبية العظمى)"]
    hostw --> mut["ملفّات نظام تشغيل قابلة للتغيير (قلّة)"]
    imm -->|تُشارَك كما هي| img["صورة إقلاع Sandbox"]
    mut -->|تُحفَظ نسخة نظيفة| img
    img --> boot["تقلع بوصفها Windows كاملاً"]
    img -.-> size["نحو 500 ميغابايت فقط تحتاج التخزين"]

الشكل 7: ليس «أبقِ Windows آخر» بل «جمِّع واحداً من Windows المضيف» هو ما يبدو عليه التخلّي عن تكرار القرص.

هذا التركيب بالضبط ما يجعل دورة الحياة التالية ممكنة.

لاحظ أنّ ما يُرمى هو الحالة المحلّيّة داخل Sandbox.

إن عيَّنت مجلّداً قابلاً للكتابة من المضيف في ملفّ إعداد .wsb، تبقى التغييرات التي تُجرى هناك في جانب المضيف.⁶

flowchart TB
    accTitle: دورة حياة Windows Sandbox
    accDescr: يبدأ الإعداد Windows نقيّاً في ثوانٍ، وبعد تحقّق تطبيق أو تجارب يغلق فيرمي كلّ الحالة داخل Sandbox فيصير البدء التالي نقيّاً مرّة أخرى، لكنّ تغييرات مجلّد مضيف معيَّن قابلاً للكتابة تبقى
    launch["ابدأ (ثوانٍ)"] --> clean["Windows نقيّ"]
    clean --> work["تحقّق تطبيق أو تجارب"]
    work --> close2["أغلق"]
    close2 --> discard["ارمِ كلّ الحالة داخل Sandbox"]
    discard -.-> mapped["التغييرات في مجلّد معيَّن قابل للكتابة تبقى على المضيف"]
    discard -->|البدء التالي| launch

الشكل 8: يستطيع العودة إلى حالة نقيّة في كلّ مرّة لأنّ الجزء القابل للتغيير نسخة قابلة للرمي، ورميها جزء من التصميم.

4.2. Direct Map: الـ ntdll.dll نفسه هو الصفحة الفيزيائيّة نفسها

لا القرص فحسب بل RAM أيضاً تُشارَك. لأنّ Sandbox يشغِّل صورة نظام التشغيل نفسها كالمضيف، تُستخدَم تقنيّة تُسمَّى «direct map» بحيث تستخدم، لملفّات نظام التشغيل التنفيذيّة، صفحات الذاكرة الفيزيائيّة نفسها كالمضيف. عندما يُحمَّل ntdll.dll في الذاكرة داخل Sandbox، يشير إلى الصفحات الفيزيائيّة نفسها كالملفّ التنفيذي نفسه المحمَّل على المضيف.

يحقِّق هذا بصمة ذاكرة أصغر بكثير من آلة افتراضيّة تقليديّة دون تعريض أسرار المضيف للخطر.²

«شارك الصفحة الفيزيائيّة نفسها بين عدّة مستخدمين» الفكرة نفسها كمشاركة DLL عبر كائنات القسم، التي تبعناها في الجزء 3 من سلسلة الذاكرة («كائنات القسم والنسخ عند الكتابة»). تلك الآليّة شاركت بين العمليّات؛ Sandbox يفعلها عبر حدّ الآلة الافتراضيّة.

flowchart TB
    accTitle: مشاركة الصفحات الفيزيائيّة عبر direct map
    accDescr: تطبيق على المضيف وتطبيق داخل Sandbox يشاركان صفحات الذاكرة الفيزيائيّة نفسها لملفّات نظام التشغيل التنفيذيّة مثل ntdll، فيقلّ استخدام الذاكرة
    happ["تطبيق على المضيف"] --> hva["عنوان افتراضي في جانب المضيف"]
    sapp["تطبيق داخل Sandbox"] --> sva["عنوان افتراضي في جانب Sandbox"]
    hva --> phys["الصفحة الفيزيائيّة نفسها (ملفّات نظام تشغيل تنفيذيّة مثل ntdll.dll)"]
    sva --> phys
    phys -.-> save["لا حاجة لتكرار حصّة نظام التشغيل من RAM"]

الشكل 9: يأخذ direct map فكرة مشاركة الصفحات المستخدمة طويلاً بين العمليّات ويطبّقها عبر حدّ الآلة الافتراضيّة.

4.3. إعارة الذاكرة واقتراضها: أشبه بعمليّة منه بآلة افتراضيّة

بخلاف تخصيص الذاكرة الثابت لآلة افتراضيّة تقليديّة، تقرِّر تقنيّة الحاويات تحت Sandbox تخصيص الموارد ديناميّاً بالتنسيق مع المضيف. إن نقصت ذاكرة المضيف، يستطيع استرداد ذاكرة من الحاوية كما يستردّها من عمليّة عاديّة.² ينمو Hyper-V Dynamic Memory أيضاً تخصيص آلة افتراضيّة وينكمشه ضمن نطاق مضبوط، لكن Sandbox يذهب خطوة أبعد: يشارك الذاكرة على القدم نفسها كإدارة ذاكرة المضيف نفسه.

flowchart TB
    accTitle: تنسيق الذاكرة بين المضيف وSandbox
    accDescr: تحجز آلة افتراضيّة تقليديّة حجماً ثابتاً افتراضيّاً بوسائل تعديل محدودة، بينما يصير Sandbox هدفاً للاسترداد استجابة لضغط ذاكرة المضيف ويشارك الذاكرة على القدم نفسها كالعمليّات العاديّة
    pressure["يرتفع ضغط ذاكرة المضيف"] --> from{"من أين يُستردّ؟"}
    from --> proc["مجموعات العمل للعمليّات العاديّة"]
    from --> sbx["ما يستخدمه Sandbox (الحاوية)"]
    proc --> relief["تُؤمَّن ذاكرة حرّة"]
    sbx --> relief
    relief -.-> contrast["لآلة افتراضيّة تقليديّة وسائل تعديل محدودة"]

الشكل 10: عندما يتعلّق الأمر بمشاركة الذاكرة، يقف Sandbox في جانب العمليّات لا الآلات الافتراضيّة، ويتنازل عن الذاكرة عندما يكون المضيف تحت ضغط.

في الجزء 1 قلنا إنّ أداء آلة افتراضيّة يعتمد أيضاً على جانب المضيف؛ مع الآلات الافتراضيّة الخفيفة يذهب هذا خطوة أبعد، ويصير تخصيص الذاكرة نفسه جهداً مشتركاً مع المضيف. هذا التنسيق سبب أنّ Sandbox يبدو أقلّ «برمجيّة افتراضيّة ثقيلة» وأكثر مجرّد تطبيق آخر.

الخطوات الملموسة لاستخدام Sandbox للتحقّق من تطبيقات أعمال مشمولة في المقالة السابقة «كيف تسرِّع التحقّق من التطبيقات بـ Windows Sandbox». يغطّي هذا المقال الآليّة تحتها.

5. الحاويات ── أين ترسم خطّ العزل

هنا لا نحكم بالأمان باسم «حاوية» وحده؛ نفحص هل تشارك الحاوية النواة مع المضيف أم تملك نواة خاصّة بها.

5.1. عزل العمليّة وعزل Hyper-V

لحاويات Windows وضعا عزل وقت تشغيل. الصورة نفسها؛ تختار الوضع بعلم عند البدء.⁷

• عزل العمليّة: عدّة حاويات تشارك النواة مع المضيف وتُعزَل بافتراضيّة لكلّ مساحة أسماء لنظام الملفّات والسجلّ ومنافذ الشبكة وفضاء معرّف العمليّة ومساحة أسماء مدير الكائنات وما شابه. هذه مقاربة شبه مطابقة لحاويات Linux.
• عزل Hyper-V: تعمل كلّ حاوية داخل آلة افتراضيّة محسَّنة جدّاً وتملك ما هو فعليّاً نواة مخصَّصة. وجود الآلة الافتراضيّة يضع عزلاً على مستوى العتاد بين الحاويات وبينها وبين المضيف.⁷

يمكن رؤية العزل القائم على مساحة الأسماء النسخة المتشدّدة للتقنيّة من مقالة افتراضيّة السجلّ («إعادة توجيه السجلّ والافتراضيّة على Windows»): إظهار كيان مختلف تحت الواجهة نفسها.

flowchart TB
    accTitle: عزل العمليّة مقابل عزل Hyper-V
    accDescr: تحت عزل العمليّة تشارك الحاويات النواة مع المضيف وتُعزَل بمساحات الأسماء، بينما تحت عزل Hyper-V تملك كلّ حاوية نواة مخصَّصة داخل آلة افتراضيّة محسَّنة
    subgraph pi ["عزل العمليّة"]
        c1["الحاوية A"] --> sk1["نواة مشتركة مع المضيف"]
        c2["الحاوية B"] --> sk1
    end
    subgraph hi ["عزل Hyper-V"]
        c3["الحاوية C"] --> k3["نواة مخصَّصة (داخل آلة افتراضيّة محسَّنة)"]
        c4["الحاوية D"] --> k4["نواة مخصَّصة (داخل آلة افتراضيّة محسَّنة)"]
    end
    sk1 ~~~ c3

الشكل 11: حتّى مع صورة الحاوية نفسها، هل يُرسَم خطّ العزل فوق النواة أم النواة نفسها منفصلة يُختار عند البدء.

5.2. أيّهما يمكن تسميته «حدّ أمان»

الفرق بين الوضعين ليس عن الأداء فحسب. لا تعتبر Microsoft الحاويات المعزولة بالعمليّة حدّ أمان متيناً. الحاويات المحافظ عليها حدّ أمان (مع خدمة الثغرات) هي المعزولة بالـ hypervisor، وفي سيناريوهات متعدّدة المستأجرين المعادية عزل Hyper-V هو الوضع الذي يُختار.⁸

كان VBS الذي رأيناه في الجزء 2 مصمَّماً كذلك على مقدّمة أنّ «النواة يمكن أن تُخترَق»، متراجعاً إلى حدّ الـ hypervisor. المعيار نفسه يسري في عالم الحاويات. الخطّ الذي يحصر شيفرة غير موثوق بها يُرسَم عند حدّ الـ hypervisor، لا داخل نواة مشتركة.

flowchart TB
    accTitle: اختيار العزل بمدى الوثوق بالشيفرة
    accDescr: حمل عمل موثوق يأخذ الكثافة والأداء بعزل العمليّة، بينما شيفرة غير موثوق بها أو شيفرة شخص آخر تحصل على حدّ hypervisor كحاوية معزولة بـ Hyper-V أو Windows Sandbox مقوّى معطَّل الشبكة وما شابه أو آلة افتراضيّة معزولة
    trust{"هل يمكن الوثوق بتلك الشيفرة؟"} -->|نعم| dens["عزل العمليّة (الكثافة والسرعة أوّلاً)"]
    trust -->|"لا، أو شيفرة شخص آخر"| bound["اختر حدّ hypervisor"]
    bound --> opt1["حاوية معزولة بـ Hyper-V"]
    bound --> opt2["Sandbox مقوّى أو آلة افتراضيّة معزولة"]

الشكل 12: وضع العزل شأن أمان قبل أن يكون شأن أداء، ومستوى الثقة يقرِّر أين يذهب الخطّ.

ملاحظة: داخل آلة افتراضيّة، افحص متطلّبات الافتراضيّة المتداخلة

تشغيل حاويات معزولة بـ Hyper-V داخل آلة Hyper-V افتراضيّة يعني طبقتين من hypervisor: افتراضيّة متداخلة.

مستوى واحد من التداخل مدعوم في الإنتاج على بيئات تستوفي الشروط (مضيف Windows 10 / Windows Server 2016 أو أحدث لمعالجات Intel، ومضيف Windows 11 / Windows Server 2022 أو أحدث لمعالجات AMD، زائد إصدار تكوين الآلة الافتراضيّة المقابل في كلّ حالة)، ويتطلّب إضافيّاً الإعداد الذي يعرِّض امتدادات الافتراضيّة للآلة الافتراضيّة الخارجيّة (ExposeVirtualizationExtensions على Set-VMProcessor لـ Hyper-V).

تشغيل WSL2 داخل آلة افتراضيّة مدعوم بالطريقة نفسها.⁹ هل تستطيع استخدام WSL2 أو Docker على آلة تطوير افتراضيّة في السحابة يعتمد كذلك على ما إذا كان حجم تلك الآلة وتكوينها يعرِّضان الافتراضيّة المتداخلة.

flowchart TB
    accTitle: بنية الافتراضيّة المتداخلة
    accDescr: تجلس آلة سحابة افتراضيّة على hypervisor المضيف الفيزيائيّ، وداخلها يعمل hypervisor آخر (التداخل مدعوم لمستوى واحد فقط) لدعم WSL2 والحاويات المعزولة بـ Hyper-V
    phys3["hypervisor المضيف الفيزيائيّ"] --> cvm["آلة سحابة افتراضيّة (جهاز تطوير)"]
    cvm --> nhv["hypervisor داخل الآلة (المستوى الأوّل من التداخل)"]
    nhv --> w2["WSL2"]
    nhv --> hvc["حاوية معزولة بـ Hyper-V"]
    nhv -.-> limit["التداخل مدعوم لمستوى واحد فقط"]

الشكل 13: سبب عمل wsl داخل آلة سحابة افتراضيّة أنّ الافتراضيّة المتداخلة مدعومة رسميّاً لمستوى واحد بالضبط.

5.3. طيف العزل والخفّة

صفّ كلّ ما غُطِّي حتّى الآن على محور واحد يعطي التالي.

flowchart TB
    accTitle: طيف قوّة العزل والخفّة
    accDescr: الحاويات المعزولة بالعمليّة الأخفّ لكنّها تشارك النواة، وWSL2 وSandbox والحاويات المعزولة بـ Hyper-V آلات افتراضيّة خفيفة بنواة مخصَّصة (Sandbox خُفِّف بمشاركة المضيف، وWSL2 بنواة مبنيّة للغرض)، وآلة افتراضيّة كاملة الأثقل لكنّها عامّة الغرض
    ax["خفيف ← → ثقيل"] ~~~ p1
    p1["حاوية معزولة بالعمليّة (نواة مشتركة)"] --> p2["WSL2 وSandbox وعزل Hyper-V (آلات خفيفة بنواة مخصَّصة)"]
    p2 --> p3["آلة افتراضيّة كاملة (تشغِّل أيّ شيء، تمسك كلّ تكرار)"]
    p1 -.-> n1["الحدّ: مساحات الأسماء"]
    p2 -.-> n2["الحدّ: الـ hypervisor"]
    p3 -.-> n3["الحدّ: الـ hypervisor + استقلال كامل"]

الشكل 14: الآلات الافتراضيّة الخفيفة الأرض الوسطى التي أبقت حدّ الـ hypervisor بينما قطعت التكرار؛ كيفيّة القطع تختلف، مشاركة لـ Sandbox ونواة مبنيّة للغرض لـ WSL2.

6. انظر بعينك

يمكن مراقبة الخفّة والمشاركة على جهازك.

6.1. زمن بدء WSL2 ونموّ الذاكرة وانكماشها

مع مدير المهام مفتوحاً، جرِّب التالي.

# زمن البدء المحسوس (التشغيل الأوّل يبدأ الآلة الافتراضيّة؛ واللاحق أسرع أيضاً)
Measure-Command { wsl -e true }

# استخدام ذاكرة آلة WSL2 الافتراضيّة (vmmem / Virtual Machine Memory)
Get-Process -Name vmmem* | Select-Object Name, WorkingSet64

# أوقف الآلة الافتراضيّة كلّها وشاهد عودة الذاكرة
wsl --shutdown

شغِّل بناء كبيراً أو عمليّة ملفّ داخل WSL2 فينمو vmmem؛ يعيده wsl --shutdown دفعة واحدة، ويمكنك مشاهدة ذلك يحدث.

6.2. فروق السرعة من موضع ملفّات WSL2

ضع المستودع نفسه في جانب Linux (~/repo) وفي جانب Windows (/mnt/c/repo)، قارن الزمن الذي يستغرقه git status أو استخراج، فيظهر فرق القسم 3.2 أرقاماً.

6.3. زيادة ذاكرة جانب المضيف عندما يبدأ Sandbox

ابدأ Sandbox وراقب زيادة الذاكرة في مدير مهام المضيف. أنّها تبقى أصغر بكثير ممّا يوحي به «Windows ثانٍ كامل» أثر المشاركة.

للحفر أبعد في تفصيل ذاكرة جانب المضيف، مقالة أدوات Sysinternals التي تغطّي كيفيّة استخدام RAMMap وVMMap («Process Explorer / Handle / VMMap في الممارسة») مرجع مفيد.

غير أنّ هذه أدوات لتصنيف عمليّات جانب المضيف والذاكرة الفيزيائيّة؛ وهي لا تراقب المشاركة مع الضيف نفسه مباشرة.

6.4. الفروق بين أوضاع عزل حاويات Windows

إن كان لديك بيئة حاويات Windows، ابدأ الصورة نفسها بـ docker run --isolation=process وبـ --isolation=hyperv، ثمّ قارن زمن البدء وما يعرضه مدير المهام (تحت عزل العمليّة، تظهر العمليّات داخل الحاوية في قائمة عمليّات المضيف) لتحسّ أين يجلس خطّ العزل.⁷

غير أنّ عزل العمليّة يتطلّب تطابق إصداري المضيف والصورة، وعلى نظام تشغيل عميل يقتصر على استخدام التطوير والاختبار. يتيح عزل Hyper-V نطاقاً أوسع من التركيبات، لذا اجعل المقارنة بزوج متوافق.¹⁰

7. ثلاث قراءات خاطئة تُتجنَّب في الممارسة

7.1. «WSL2 بطيء»

ما هو بطيء ليس WSL2 بل مسار إدخال/إخراج الملفّات الذي يعبر حدّ نظام التشغيل. في حالات كثيرة، مجرّد نقل المشروع إلى جانب Linux يحوِّل التجربة.⁴ بالمقابل، وضع ملفّات تلمسها أدوات Windows في جانب Linux عيب للسبب نفسه. قرِّر بـ «ضعه على نظام التشغيل نفسه الذي يستخدمه».

7.2. «نموّ vmmem كبيراً تسرّب ذاكرة»

تنمو ذاكرة WSL2 وتنكمش مع الطلب، وتُعاد الذاكرة المطلقة. على WSL الحالي، يستردّ autoMemoryReclaim (الافتراضي dropCache) أيضاً ذاكرة التخزين المؤقّت للملفّات تلقائيّاً، لذا «بقي كبيراً» عادة يحلّ نفسه مع الوقت.⁵

إن بقي مع ذلك، افحص أنّ autoMemoryReclaim ليس disabled وأنّ pageReporting، الذي يعيد الذاكرة المطلقة، لم يُعطَّل (وأنّك لست على WSL أقدم)؛ ثمّ إمّا اضبط سقفاً صريحاً بـ memory في .wslconfig أو أعد كلّ شيء بـ wsl --shutdown في نهاية الجلسة.

مقاربة تقرير هل هو تسرّب هي نفسها كما في الجزء التمهيدي من سلسلة الذاكرة، «ماذا تعني «استخدام الذاكرة» في Windows فعليّاً؟».

7.3. «إنّه في حاوية، إذن هو آمن»

الحاويات المعزولة بالعمليّة تشارك النواة، وبمعيار Microsoft ليست حدّ أمان.⁸ لتشغيل شيفرة غير موثوق بها أو عيّنات، اختر عزلاً يملك حدّ hypervisor: حاوية معزولة بـ Hyper-V، أو Windows Sandbox، أو آلة افتراضيّة مخصَّصة.

غير أنّ حدّ hypervisor ليس تصريحاً حرّاً عامّاً.

إعدادات Windows Sandbox الافتراضيّة تملك شبكة ممكَّنة، وهو ما يمكن أن يعرِّض تطبيقاً غير موثوق به لشبكتك الداخليّة.¹ إن استخدمته لتشغيل عيّنات، إمّا قوِّ العزل بتعطيل الشبكة وإعادة توجيه الحافظة في ملفّ إعداد .wsb، أو استخدم آلة افتراضيّة مخصَّصة على شبكة معزولة.

8. الخلاصة ── إغلاق السلسلة

النقاط الرئيسة للجزء 3.

• خفّة الآلات الافتراضيّة الخفيفة نتيجة «إيقاف التكرار»، لا «إضعاف العزل».
• يشغِّل WSL2 نواة Linux أصيلة في آلة افتراضيّة خدميّة خفيفة مُدارة، والتوزيعات معزولة حاويات داخل تلك الآلة.³ قاعدة الأداء وضع الملفّات على نظام التشغيل الذي يستخدمها؛ وتنمو الذاكرة وتنكمش ديناميّاً، ويتحكّم .wslconfig في السقف.⁴⁵
• يشارك Windows Sandbox ملفّات نظام التشغيل غير القابلة للتغيير للمضيف عبر الصورة الأساسيّة الديناميّة والصفحات الفيزيائيّة لملفّات نظام التشغيل التنفيذيّة المنطبقة عبر direct map، لذا لا يمسك نسخة من Windows كامل.² نحو 500 ميغابايت من الملفّات القابلة للتغيير وذاكرة التطبيقات التي تشغِّلها داخله ما تزال لازمة على حدة.
• يُختار وضع عزل الحاوية عند البدء، والجانب الذي يمكن تسميته حدّ أمان هو عزل Hyper-V.⁷⁸

ووضع السلسلة كلّها في صفحة واحدة يعطي هذا.

• الجزء 1: تحت Windows طبقة hypervisor، ونظام التشغيل المضيف نفسه يعمل بوصفه القسم الجذر. تتوسّط تلك الطبقة المعالج والذاكرة (SLAT) مباشرة، وإدخال/إخراج الأجهزة الاصطناعيّة يتوسّطه القسم الجذر (VSP) في الطرف البعيد من VMBus.
• الجزء 2: تُستخدَم تلك الطبقة لا لعزل الآلات الافتراضيّة بعضها عن بعض فحسب، بل أيضاً لرسم حدّ أقوى من النواة (VTL) داخل نظام التشغيل نفسه. أمان Windows 11 الافتراضي مبنيّ فوقها.
• الجزء 3: على الطبقة نفسها، قطع التكرار هو ما يجعل «آلة افتراضيّة تقلع في ثوانٍ» ممكناً. خطّ العزل محفوظ، وقد صار أداة يوميّة.

flowchart TB
    accTitle: السلسلة كلّها في صورة واحدة
    accDescr: الـ hypervisor مباشرة على العتاد هو الجزء 1، وفصل VTL0 وVTL1 داخل Windows المضيف هو الجزء 2، وخفّة WSL2 وSandbox وعزل Hyper-V على الطبقة نفسها هي الجزء 3، مع مشاركة الحاويات المعزولة بالعمليّة نواة المضيف، وتخفيف Sandbox بالمشاركة، وWSL2 بنواة مبنيّة للغرض
    hw3["العتاد"] --> hv3["الـ hypervisor (الجزء 1)"]
    hv3 --> rp3["Windows المضيف (فصل VTL هو الجزء 2)"]
    hv3 --> lw3["WSL2 وSandbox وعزل Hyper-V (الجزء 3)"]
    rp3 --> pc3["حاوية معزولة بالعمليّة (نواة مشتركة)"]
    lw3 -.-> mech3["Sandbox خُفِّف بالمشاركة، وWSL2 بنواة مبنيّة للغرض"]

الشكل 15: صفّ الأجزاء الثلاثة فتحصل على الصورة الكلّيّة لما يقع تحت Windows اليوم.

لم تعد الافتراضيّة تقنيّة غرفة خوادم، ولا لمن يُقيم آلات افتراضيّة فقط. تحت Windows لديك، تدعم بهدوء الأمان وتجربة التطوير كليهما. هناك تقف الأمور اليوم.

مقالات ذات صلة

• أعماق الافتراضيّة في Windows (الجزء 1) ── أين يعمل Windows فعليّاً؟ الـ hypervisor والأقسام
• أعماق الافتراضيّة في Windows (الجزء 2) ── ذاكرة لا تستطيع النواة حتّى رؤيتها: كيف يعمل VBS وHVCI وCredential Guard
• أعماق ذاكرة Windows (الجزء 3) — كائنات القسم والنسخ عند الكتابة: حقيقة DLL وتعيين الملف
• كيف تسرِّع التحقّق من التطبيقات بـ Windows Sandbox
• إعادة توجيه السجلّ والافتراضيّة على Windows

مجالات الاستشارة ذات الصلة

تتعامل شركة كومورا سوفت ذ.م.م. مع إعداد بيئات تطوير تستخدم WSL2 والحاويات، وتصميم بيئات تحقّق لتطبيقات Windows، وتحقيق الأداء والتوافق في البيئات المُفتَرَضة.

• تطوير تطبيقات Windows
• تحقيق الأعطال وتحليل الأسباب
• إعادة استخدام الأصول القائمة ودعم الترحيل
• التواصل معنا

روابط مرجعيّة

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

هل WSL2 آلة افتراضيّة؟

نعم. يشغِّل WSL2 نواة Linux أصيلة تبنيها Microsoft داخل آلة افتراضيّة خدميّة خفيفة. غير أنّ WSL تدير الآلة الافتراضيّة خلف الكواليس، لذا لا يجعل التصميم المستخدم يفكِّر في إعدادات آلة افتراضيّة أو ينتظر إقلاعاً. يعمل كلّ توزيعة Linux حاويةً معزولة داخل هذه الآلة الافتراضيّة المُدارة.

لماذا عمليّات الملفّات تحت /mnt/c بطيئة في WSL2؟

لأنّ الوصول من نواة Linux في WSL2 إلى نظام ملفّات جانب Windows يمرّ بمشاركة ملفّات تعبر حدّ نظام التشغيل. عمليّات نظام ملفّات Linux (قرص افتراضي ext4) سريعة، لذا القاعدة إبقاء ملفّات المشروع في جانب نظام التشغيل نفسه الذي تستخدمه الأدوات التي تعمل عليها.

هل استخدام ذاكرة كبير لعمليّة vmmem تسرّب؟

في معظم الحالات ليس تسرّباً. تنمو ذاكرة WSL2 وتنكمش مع الاستخدام، والذاكرة التي أطلقتها العمليّات تُعاد إلى Windows تحت إعداد pageReporting، المفعَّل افتراضيّاً. ذاكرة التخزين المؤقّت للملفّات أيضاً تُستعاد تلقائيّاً عبر autoMemoryReclaim في .wslconfig (الافتراضي dropCache) على WSL الحالي. في بيئات عُطِّلت فيها هذه الإعدادات، أو على WSL أقدم، يمكن أن تبقى الذاكرة حتّى تخرج الآلة الافتراضيّة؛ في تلك الحالة اضبط حدّاً أعلى بإعداد memory أو أعدها بـ wsl --shutdown.

كيف يستطيع Windows Sandbox إقلاع Windows كامل من بضع مئات ميغابايت من القرص؟

عبر آليّة تُسمَّى الصورة الأساسيّة الديناميّة. تشارك ملفّات نظام التشغيل غير القابلة للتغيير من Windows المثبَّت أصلاً على المضيف، وتحتفظ بنسخة نظيفة من العدد الصغير فقط من الملفّات القابلة للتغيير. ذلك يجمّع صورة كاملة قابلة للإقلاع دون تخزين نسخة كاملة من Windows.

هل الحاويات أكثر أماناً من الآلات الافتراضيّة؟

يعتمد على وضع العزل. الحاويات المعزولة بالعمليّة تشارك النواة مع المضيف، ولا تعتبر Microsoft هذا حدّ أمان متيناً. عندما تتعامل مع شيفرة معادية، تحتاج اختيار عزل Hyper-V، الذي يعطي كلّ حاوية نواة مخصَّصة.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.