Windows Virtualization Internals (חלק 3) — VMs שעולות בשניות: WSL2, Windows Sandbox ו-containers

VM מלא כבד, אז למה WSL2 ו-Windows Sandbox קלים? הפרק האחרון בסדרה מסביר את ההבדל לא רק מ”מה מבודד” אלא מ”מה לא חייבים לשכפל”.

כשיוצרים Windows VM ב-Hyper-V Manager, לוקח לה עשרות שניות להתחיל והיא שומרת כמה GB של זיכרון. ובכל זאת באותו מחשב, הקלדת wsl מחזירה מעטפת Linux תוך כמה שניות, ו-Windows Sandbox פותח desktop חד-פעמי בכמה שניות גם הוא.¹

היסוד בכל המקרים הוא ה-Windows hypervisor שראינו בחלק 1. בחלק 2 אישרנו שהיסוד הזה יכול לבנות בידוד חזק מה-kernel. המאמר הזה מסתכל בנפרד על ההתמחות של WSL2, השיתוף של Sandbox, ומצבי הבידוד של containers.

“Windows Virtualization Internals” — כל 3 החלקים

מסתכלים על אותו Windows hypervisor בסדר יסוד → בידוד אבטחה → יישום ל-VMs קלות.

הנחות המאמר הזה

איך לקרוא את המאמר הזה

1. קודם המסקנה

VM קלת-משקל שומרת על קו הבידוד (kernel ייעודי וגבול ה-hypervisor) ומקלה את “העותק של guest OS שלם”. Sandbox משתף את Windows של המארח עצמו, WSL2 מחליף את האורח ב-Linux קטן שנבנה למטרה, ובשני המקרים הזיכרון אינו שמירה קבועה אלא משותף דינמית עם המארח.

מקור המשקל של VM מלא אינו הבידוד עצמו אלא שכפול: עוד image של OS בדיסק, עוד שווי ערך ל-OS של דפים ב-RAM, ועוד boot מלא בכל עלייה. ה-VMs הקלות חותכות את השכפול בשתי מדיניות: “לשתף מה שבטוח לשתף” (Sandbox) ו”אם אי אפשר לשתף, לבנות מחדש קטן” (WSL2).

flowchart TB
    accTitle: שלושת סוגי השיתוף מאחורי VMs קלות
    accDescr: ה-OS image ש-VM מלא שכפל נחתך בשיתוף ב-Sandbox ובכיווץ ב-WSL2, זיכרון שהוא הקצאה קבועה כברירת מחדל (תצורות Dynamic Memory הן החריג) הופך להשאלה ולהחזרה דינמית עם המארח, וה-startup מוחלף ב-kernel קל ובתצורה מינימלית, ונשאר רק גבול הבידוד
    heavy["מקור המשקל של VM מלא הוא שכפול"] --> d1["דיסק: OS image כפול"]
    heavy --> d2["זיכרון: הקצאה קבועה כברירת מחדל"]
    heavy --> d3["startup: עוד boot מלא"]
    d1 -->|מוחלף ב| s1["שיתוף (Sandbox) או כיווץ (WSL2)"]
    d2 -->|מוחלף ב| s2["מושאל ומוחזר דינמית עם המארח"]
    d3 -->|מוחלף ב| s3["מקוצר ב-kernel קל ובתצורה מינימלית"]

איור 1: הם הפסיקו לשכפל, לא לבודד, וזה השלד של התשובה ל”אותו hypervisor, ובכל זאת קל”.

להלן מסתכלים על WSL2, Windows Sandbox ו-containers בסדר הזה, ועל איזה שכפול כל אחד מהם חותך.

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 19, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. מה VM מלא נושא

כקו בסיס להשוואה, הנה מה ש-VM מסורתי נושא.

• OS image עצמאי. הוא מחזיק כל קובץ של ה-guest OS בתוך virtual disk. גם אם המארח רץ על אותו Windows, שום דבר אינו משותף.
• הקצאת זיכרון גסה. VM מסורתי מקצה זיכרון מארח בגודל סטטי כברירת מחדל. יש מנגנונים כמו Hyper-V Dynamic Memory שגדלים ומתכווצים את ההקצאה בתוך טווח מוגדר, אבל אמצעי ההתאמה לשינויי ביקוש מוגבלים.²
• boot מלא לשימוש כללי. firmware, boot loader ו-services עולים באותו רצף כמו במכונה פיזית.

flowchart TB
    accTitle: שלושת העומסים ש-VM מלא נושא
    accDescr: VM מלא נושא OS image עצמאי, הקצאת זיכרון שהיא סטטית כברירת מחדל, ו-boot מלא לשימוש כללי, ואלה מופיעים כעלויות בדיסק, ב-RAM ובזמן עלייה
    fullvm["VM מלא"] --> b1["OS image עצמאי"]
    fullvm --> b2["הקצאת זיכרון סטטית כברירת מחדל"]
    fullvm --> b3["boot מלא לשימוש כללי"]
    b1 -.-> c1["צורך דיסק בשביל הכפיל"]
    b2 -.-> c2["נוטה להחזיק RAM שאינו בשימוש"]
    b3 -.-> c3["לוקח עשרות שניות לעלות"]

איור 2: כל פריט בפירוק העלות של VM מלא משולם עבור כלליות ושכפול, לא עבור בידוד.

אלה אינם פגמים; הם מחיר הכלליות של היכולת לשים כל דבר באורח. לשימוש כמו להריץ Linux ישן ליד Windows Server, הכלליות הזו היא בדיוק הערך. אבל כשהצורך הוא “להריץ את אותו OS כמו המארח (או קבוע) עכשיו, לפיתוח או לאימות”, רוב זה משקל מת. VMs קלות מורידות את המטען הזה בצמצום המטרה.

3. WSL2 — utility VM שנושא kernel שנבנה למטרה

WSL2 הכי קל לעקוב אחריו בסדר מבנה → איפה הקבצים חיים → החזרת זיכרון. שימוש ב-Linux kernel אמיתית וטיפול מהיר בקבצים בצד Windows הם שני עניינים נפרדים.

3.1. מבנה: VM מנוהלת וההפצות שבתוכה

WSL2 הוא מנגנון שמריץ Linux kernel אמיתית בתוך utility VM קלת-משקל.³ יש שלוש נקודות.

ה-kernel אמיתי, אבל מתמחה

זה Linux kernel ש-Microsoft בונה מענף Stable, מכוונן בגודל ובביצועים ל-WSL2. בסטנדרט הנוכחי, WSL שמופץ דרך Microsoft Store, ה-kernel מתעדכן יחד עם חבילת WSL עצמה ומוחל ב-wsl --update (ההפצה הישנה in-box קיבלה אותו דרך Windows Update).⁴

כי זה kernel אמיתי, תאימות system-call מלאה, וכלים כמו Docker רצים כמו שהם.

ה-VM נשאר מאחורי הקלעים

WSL מנהל יצירה, עלייה ועצירה של ה-VM; המשתמש רק פותח מעטפת. אין מסך הגדרות VM ואין המתנה מורגשת ל-boot.⁴

ההפצות הן containers בתוך ה-VM

כל הפצה, כמו Ubuntu או Debian, רצה כ-container מבודד בתוך VM מנוהלת אחת. הן חולקות את network namespace ואת ה-kernel, בעוד namespaces כמו PID, mount ו-user מופרדים.³

flowchart TB
    accTitle: ארכיטקטורת WSL2
    accDescr: Windows המארח ו-utility VM קלת-משקל יושבים זה לצד זה על ה-hypervisor, Linux kernel שבנתה Microsoft רץ בתוך ה-VM, וכל הפצה רצה כ-container מבודד בתוכה
    hv["hypervisor"] --> host["Windows המארח"]
    hv --> uvm["utility VM קלת-משקל"]
    uvm --> lk["Linux kernel (build של Microsoft, מתעדכן ב-wsl --update)"]
    lk --> u1["Ubuntu (container)"]
    lk --> u2["Debian (container)"]
    host <-->|"interop (פקודות, קבצים, רשת)"| uvm

איור 3: התשובה ל”האם WSL2 הוא VM?” היא “כן, אבל VM מנוהלת שנשארת מחוץ לראייה”, וגם עם כמה הפצות מותקנות עדיין יש רק VM אחת.

הנה מה שקורה מאחורי הקלעים ברגע שמקלידים wsl.

flowchart TB
    accTitle: מהרצת פקודת wsl עד שמעטפת חוזרת בשניות
    accDescr: כש-wsl רץ, ה-VM הקלה ו-Linux kernel עולים אם ה-utility VM עוד לא רצה, ה-VM הקיימת בשימוש כמו שהיא אם כן, ומעטפת חוזרת ב-container של ההפצה
    cmd["הרצת wsl"] --> vmq{"האם ה-utility VM כבר רצה?"}
    vmq -->|לא| bootvm["עליית ה-VM הקלה ו-Linux kernel (שניות)"]
    vmq -->|כן| reuse["שימוש ב-VM הרצה כמו שהיא"]
    bootvm --> shell["מעטפת חוזרת בתוך ה-container"]
    reuse --> shell

איור 4: ההמתנה אינה אלא עליית VM מינימלית, וכאן משתלם להוריד את המטען של boot מלא.

3.2. File I/O: באיזה צד הקבצים חיים עושה את כל ההבדל

איפה קבצים ממוקמים עולה בכל דיון על ביצועי WSL2.

• פעולות על קבצים בצד Linux (ה-virtual disk מסוג ext4) מהירות. Linux kernel מטפל במערכת הקבצים שלו ישירות, ודווחו האצות של עד 20x מעל WSL1 לחילוץ tarball ו-2 עד 5x ל-git clone ול-npm install.⁴
• פעולות על קבצים בצד Windows (/mnt/c וכדומה) איטיות יותר כי הן עוברות דרך שיתוף קבצים שחוצה את גבול ה-OS. ביצועים בין מערכות קבצים של OS הם התחום הגדול האחד שבו WSL2 נשאר מאחורי WSL1.⁴

לכן הכלל הוא: שימו קובצי פרויקט באותו צד OS כמו הכלים שעובדים עליהם.⁴ מאגר שמטופל בכלי build של Linux הולך לצד Linux; solution שנבנה ב-Visual Studio הולך לצד Windows.

flowchart TB
    accTitle: הפיצול בנתיבי file I/O של WSL2
    accDescr: גישה ל-ext4 virtual disk בצד Linux מהירה כי Linux kernel מגיע אליו ישירות, בעוד גישה לקבצים בצד Windows איטית כי היא עוברת דרך שיתוף שחוצה את גבול ה-OS
    io["פעולת קובץ בתוך WSL2"] --> place{"באיזה צד הקובץ?"}
    place -->|"צד Linux (תיקיית home וכו')"| ext4["I/O ישיר ל-ext4 virtual disk"]
    place -->|"צד Windows (/mnt/c וכו')"| p9["דרך שיתוף שחוצה את גבול ה-OS"]
    ext4 --> fast["מהיר (עד 20x מעל WSL1 בדוגמה אחת)"]
    p9 --> slow["נוטה להיות איטי"]
    slow -.-> fix["תיקון: לשים את הקובץ ב-OS שמשתמש בו"]

איור 5: מה שאיטי הוא הנתיב, לא WSL2, כך שפשוט שינוי איפה הקבצים חיים לעיתים קרובות גורם לבעיית הביצועים להיעלם.

3.3. זיכרון: הוא גדל, הוא מתכווץ, אבל הוא לא מחזיר הכול

שימוש הזיכרון של WSL2 (נראה כ-process vmmem ב-Task Manager) אינו שמירה קבועה; הוא גדל ומתכווץ עם השימוש.

החזרת זיכרון ש-processes שחררו

זיכרון ש-processes שחררו מוחזר ל-Windows אוטומטית תחת ההגדרה pageReporting, שמופעלת כברירת מחדל.⁵

תביעת file cache בחזרה

דפים שמוחזקים כ-file cache פעם לא חזרו ל-Windows עד שה-VM נסגרה.⁴ ב-WSL הנוכחי, ההגדרה הניסיונית autoMemoryReclaim ב-.wslconfig (ברירת מחדל dropCache) תובעת גם את ה-cache אוטומטית.⁵

בסביבות שבהן ההגדרה הזו היא disabled, או ב-WSL ישן יותר, ה-cache מסשן ארוך יכול להישאר עד שה-VM נסגרת וללחוץ על זיכרון המארח.

flowchart TB
    accTitle: איך זיכרון WSL2 גדל, מתכווץ ומוחזר
    accDescr: ביקוש גדל בתוך WSL2 מעלה את שימוש הזיכרון של ה-VM, זיכרון ש-processes שחררו מוחזר ל-Windows תחת pageReporting שמופעל כברירת מחדל, ה-file cache נתבע אוטומטית על ידי autoMemoryReclaim כברירת מחדל, אבל עם אלה מושבתים או ב-WSL ישן הוא נשאר עד שה-VM נסגרת, ו-wsl shutdown מחזיר הכול
    grow["ביקוש הזיכרון גדל בתוך WSL2"] --> vm["שימוש vmmem גדל"]
    vm --> freed{"האם הדף הזה שוחרר?"}
    freed -->|"שוחרר על ידי process (עם pageReporting מופעל)"| ret["מוחזר ל-Windows אוטומטית"]
    freed -->|מוחזק כ-file cache| amr["נתבע אוטומטית על ידי autoMemoryReclaim (ברירת מחדל)"]
    amr -.-> old2["נשאר עד שה-VM נסגרת אם מושבת או ב-WSL ישן"]
    old2 --> sd["wsl --shutdown מחזיר הכול"]

איור 6: מה שנראה כמו “זה רק גדל” הוא בעיקר ה-cache (עם pageReporting מושבת, גם זיכרון ש-processes שחררו נשאר), לכן לומדים את נתיבי ההחזרה לפני שקוראים לזה leak.

קביעת תקרת זיכרון

אם רוצים תקרה מפורשת, %UserProfile%\.wslconfig שולט בזיכרון, במספר המעבדים וב-swap של ה-VM כולה.⁵

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

אחרי שינוי ההגדרות, מפעילים מחדש את ה-VM ב-wsl --shutdown כדי שייכנסו לתוקף. ההקצאה הדינמית הזו, שבה הגדרה מחליטה על התקרה והביקוש מחליט על השימוש בפועל, נלקחת עוד צעד קדימה על ידי Windows Sandbox, שבא בהמשך.

4. Windows Sandbox — להשתמש ב-Windows של המארח עוד פעם אחת

הקלות של Sandbox מתפרקת לשלושה חלקים: שיתוף קובצי OS בדיסק, שיתוף דפי OS ב-RAM, ו-תיאום הקצאת זיכרון עם המארח.

4.1. Dynamic base image: Windows שלם ב-500 MB

Windows Sandbox הוא desktop Windows חד-פעמי שמבודד על ידי ה-hypervisor. סוגרים אותו והכול נעלם; בפעם הבאה הוא עולה בשניות ממצב נקי.¹

החידה הראשונה היא הדיסק. הוא יכול לעשות boot ל-Windows שלם, ובכל זאת ה-base image של Sandbox הוא רק כ-500 MB אחרי התקנה ו-30 MB דחוס להפצה.² הסוד הוא ה-dynamic base image.

• רוב קובצי ה-OS בלתי-משתנים ואפשר לשתף אותם כמו שהם מהמארח.
• רק המספר הקטן של קבצים משתנים אינו ניתן לשיתוף, ולכן נשמר עותק נקי שלהם בתוך ה-base image.
• בעלייה, הקבצים הבלתי-משתנים של המארח והעותקים המקומיים של הקבצים המשתנים מורכבים ל-image Windows שלם.²

כלומר, Sandbox אינו מוריד ואינו מאחסן עותק של Windows; הוא עולה ב-שימוש חוזר ב-Windows שכבר מותקן במארח.

flowchart TB
    accTitle: איך ה-dynamic base image מורכב
    accDescr: קובצי ה-OS הבלתי-משתנים של Windows המארח משותפים, רק הקבצים המשתנים נשמרים כעותק נקי ב-base image, ושניהם מורכבים ל-image Windows השלם של Sandbox
    hostw["Windows השלם של המארח"] --> imm["קובצי OS בלתי-משתנים (הרוב המכריע)"]
    hostw --> mut["קובצי OS משתנים (מעטים)"]
    imm -->|משותפים כמו שהם| img["image העלייה של Sandbox"]
    mut -->|עותק נקי נשמר| img
    img --> boot["עולה כ-Windows שלם"]
    img -.-> size["רק כ-500 MB צריך לאחסן"]

איור 7: לא “לשמור עוד Windows” אלא “להרכיב אחד מ-Windows של המארח” הוא איך נראה ויתור על שכפול דיסק.

ההרכבה הזו היא בדיוק מה שמאפשר את מחזור החיים הבא.

שימו לב שמה שנזרק הוא המצב המקומי בתוך Sandbox.

אם ממפים תיקייה ברת-כתיבה מהמארח בקובץ התצורה .wsb, שינויים שנעשו שם נשארים בצד המארח.⁶

flowchart TB
    accTitle: מחזור החיים של Windows Sandbox
    accDescr: עלייה מכינה Windows נקי בשניות, אחרי אימות אפליקציה או ניסויים סגירה זורקת את כל המצב בתוך Sandbox כך שהעלייה הבאה נקייה שוב, אבל שינויים לתיקיית מארח שממופה כברת-כתיבה נשארים
    launch["עלייה (שניות)"] --> clean["Windows נקי"]
    clean --> work["אימות אפליקציה או ניסויים"]
    work --> close2["סגירה"]
    close2 --> discard["זריקת כל המצב בתוך Sandbox"]
    discard -.-> mapped["שינויים בתיקייה ברת-כתיבה שממופה נשארים במארח"]
    discard -->|עלייה הבאה| launch

איור 8: הוא יכול לחזור למצב נקי בכל פעם כי החלק המשתנה הוא עותק חד-פעמי, וזריקתו היא חלק מהתכנון.

4.2. Direct map: אותו ntdll.dll הוא אותו דף פיזי

לא רק הדיסק אלא גם RAM משותף. כי Sandbox מריץ את אותו OS image כמו המארח, משתמשים בטכניקה שנקראת “direct map” כך של-OS binaries הוא משתמש ב-אותם דפי זיכרון פיזיים כמו המארח. כש-ntdll.dll נטען לזיכרון בתוך Sandbox, הוא מצביע לאותם דפים פיזיים כמו אותו binary שנטען במארח.

זה משיג memory footprint קטן בהרבה מ-VM מסורתי בלי לחשוף את סודות המארח לסיכון.²

“לשתף את אותו דף פיזי בין כמה משתמשים” הוא אותו רעיון כמו שיתוף DLL דרך section objects, שעקבנו אחריו בחלק 3 של סדרת הזיכרון (“Windows Memory Internals (חלק 3) — Section objects ו-Copy-on-Write”). המנגנון ההוא שיתף בין processes; Sandbox עושה זאת מעבר לגבול ה-VM.

flowchart TB
    accTitle: שיתוף דפים פיזיים דרך direct map
    accDescr: אפליקציה במארח ואפליקציה בתוך Sandbox חולקות את אותם דפי זיכרון פיזיים ל-OS binaries כמו ntdll, ומקטינות שימוש בזיכרון
    happ["אפליקציה במארח"] --> hva["כתובת וירטואלית בצד המארח"]
    sapp["אפליקציה בתוך Sandbox"] --> sva["כתובת וירטואלית בצד Sandbox"]
    hva --> phys["אותו דף פיזי (OS binaries כמו ntdll.dll)"]
    sva --> phys
    phys -.-> save["אין צורך לשכפל את חלק ה-OS ב-RAM"]

איור 9: Direct map לוקח את רעיון שיתוף הדפים ששימש זמן רב בין processes ומחיל אותו מעבר לגבול ה-VM.

4.3. השאלת זיכרון והחזרתו: יותר כמו process מאשר כמו VM

בניגוד להקצאת זיכרון סטטית של VM מסורתי, טכנולוגיית ה-container שמתחת ל-Sandbox מחליטה על הקצאת משאבים דינמית בתיאום עם המארח. אם המארח מתקצר בזיכרון, הוא יכול לתבוע זיכרון מה-container בדיוק כמו שהוא תובע אותו מ-process רגיל.² גם Hyper-V Dynamic Memory גדל ומתכווץ הקצאה של VM בתוך טווח מוגדר, אבל Sandbox הולך צעד נוסף: הוא משתף זיכרון באותו מעמד כמו ניהול הזיכרון של המארח עצמו.

flowchart TB
    accTitle: תיאום זיכרון בין המארח ל-Sandbox
    accDescr: VM מסורתי שומר גודל סטטי כברירת מחדל עם אמצעי התאמה מוגבלים, ואילו Sandbox הופך ליעד תביעה בתגובה ללחץ זיכרון במארח ומשתף זיכרון באותו מעמד כמו processes רגילים
    pressure["לחץ זיכרון במארח עולה"] --> from{"מאיפה לתבוע?"}
    from --> proc["Working Sets של processes רגילים"]
    from --> sbx["מה ש-Sandbox (container) משתמש בו"]
    proc --> relief["זיכרון פנוי מובטח"]
    sbx --> relief
    relief -.-> contrast["ל-VM מסורתי אמצעי התאמה מוגבלים"]

איור 10: כשמדובר בשיתוף זיכרון, Sandbox עומד בצד של processes ולא של VMs, ומוותר על זיכרון כשהמארח בלחץ.

בחלק 1 אמרנו שביצועי VM תלויים גם בצד המארח; עם VMs קלות זה הולך צעד נוסף, ו-הקצאת הזיכרון עצמה הופכת למאמץ משותף עם המארח. התיאום הזה הוא למה Sandbox מרגיש פחות כמו “תוכנת וירטואליזציה כבדה” ויותר כמו עוד אפליקציה.

השלבים הקונקרטיים לשימוש ב-Sandbox לאימות אפליקציות עסקיות מכוסים במאמר הקודם “איך מאיצים אימות אפליקציות עם Windows Sandbox”. המאמר הזה מכסה את המנגנון שמתחת.

5. Containers — איפה למתוח את קו הבידוד

כאן לא שופטים בטיחות לפי השם “container” לבדו; בודקים אם ה-container חולק את ה-kernel עם המארח או שיש לו kernel משלו.

5.1. Process isolation ו-Hyper-V isolation

ל-Windows containers יש שני מצבי בידוד בזמן ריצה. ה-image זהה; בוחרים את המצב ב-flag בעלייה.⁷

• Process isolation: כמה containers חולקים את ה-kernel עם המארח ומבודדים בווירטואליזציה לפי namespace של מערכת הקבצים, registry, פורטי רשת, מרחב process ID, Object Manager namespace וכדומה. זו כמעט אותה גישה כמו Linux containers.
• Hyper-V isolation: כל container רץ בתוך VM ממוטב מאוד ויש לו מה שהוא בפועל kernel ייעודי. נוכחות ה-VM שמה בידוד ברמת חומרה בין containers וביניהם לבין המארח.⁷

בידוד מבוסס-namespace אפשר לראות כגרסה היסודית של הטכניקה ממאמר וירטואליזציית registry (“הפניה מחדש ווירטואליזציה של Registry ב-Windows”): להראות ישות שונה תחת אותו API.

flowchart TB
    accTitle: בידוד תהליכים מול בידוד Hyper-V
    accDescr: תחת process isolation, containers חולקים את ה-kernel עם המארח ומבודדים ב-namespaces, ואילו תחת Hyper-V isolation לכל container יש kernel ייעודי בתוך VM ממוטב
    subgraph pi ["בידוד תהליכים"]
        c1["מיכל A"] --> sk1["kernel משותף עם המארח"]
        c2["מיכל B"] --> sk1
    end
    subgraph hi ["בידוד Hyper-V"]
        c3["מיכל C"] --> k3["kernel ייעודי (בתוך VM ממוטב)"]
        c4["מיכל D"] --> k4["kernel ייעודי (בתוך VM ממוטב)"]
    end
    sk1 ~~~ c3

איור 11: גם עם אותו container image, אם קו הבידוד מצויר מעל ה-kernel או שה-kernel עצמו נפרד נבחר בעלייה.

5.2. איזה מהם אפשר לקרוא לו “גבול אבטחה”

ההבדל בין שני המצבים אינו רק על ביצועים. Microsoft אינה מחשיבה containers ב-process isolation כגבול אבטחה חזק. ה-containers שמתוחזקים כגבול אבטחה (עם טיפול בפגיעויות) הם אלה שמבודדים ב-hypervisor, ובתרחישי multi-tenant עוינים Hyper-V isolation הוא המצב לבחור.⁸

ה-VBS שראינו בחלק 2 תוכנן גם הוא בהנחה ש”ה-kernel עלול להיפגע”, ונסוג לגבול ה-hypervisor. אותו קריטריון מחזיק בעולם ה-containers. הקו שכולא קוד לא מהימן מצויר בגבול ה-hypervisor, לא בתוך kernel משותף.

flowchart TB
    accTitle: בחירת בידוד לפי עד כמה אפשר לסמוך על הקוד
    accDescr: עומס מהימן לוקח צפיפות וביצועים עם process isolation, בעוד קוד לא מהימן או קוד של מישהו אחר מקבל גבול hypervisor כמו Hyper-V isolated container, Windows Sandbox מוקשח עם רשת וכדומה כבויים, או VM מבודד
    trust{"אפשר לסמוך על הקוד הזה?"} -->|כן| dens["Process isolation (צפיפות ומהירות קודם)"]
    trust -->|"לא, או קוד של מישהו אחר"| bound["לבחור גבול hypervisor"]
    bound --> opt1["Hyper-V isolated container"]
    bound --> opt2["Sandbox מוקשח או VM מבודד"]

איור 12: מצב בידוד הוא עניין אבטחה לפני שהוא עניין ביצועים, ורמת האמון מחליטה איפה הקו עובר.

הערה: בתוך VM, בדקו את דרישות nested virtualization

הרצת Hyper-V isolated containers בתוך Hyper-V VM פירושה שתי שכבות hypervisor: nested virtualization.

רמה אחת של קינון נתמכת בייצור בסביבות שעומדות בתנאים (מארח Windows 10 / Windows Server 2016 ואילך למעבדי Intel, מארח Windows 11 / Windows Server 2022 ואילך למעבדי AMD, ועוד גרסת תצורת VM מתאימה בכל מקרה), והיא דורשת בנוסף את ההגדרה שחושפת את הרחבות הווירטואליזציה ל-VM החיצוני (ExposeVirtualizationExtensions ב-Set-VMProcessor ל-Hyper-V).

הרצת WSL2 בתוך VM נתמכת באותו אופן.⁹ אם אפשר להשתמש ב-WSL2 או ב-Docker על VM פיתוח בענן תלוי גם כן אם גודל ה-VM והתצורה הזו חושפים nested virtualization.

flowchart TB
    accTitle: מבנה nested virtualization
    accDescr: VM בענן יושב על ה-hypervisor של המארח הפיזי, ובתוכו hypervisor נוסף (הקינון נתמך לרמה אחת בלבד) רץ כדי לתמוך ב-WSL2 וב-Hyper-V isolated containers
    phys3["ה-hypervisor של המארח הפיזי"] --> cvm["VM בענן (מכונת פיתוח)"]
    cvm --> nhv["hypervisor בתוך ה-VM (רמת הקינון הראשונה)"]
    nhv --> w2["WSL2"]
    nhv --> hvc["Hyper-V isolated container"]
    nhv -.-> limit["הקינון נתמך לרמה אחת בלבד"]

איור 13: הסיבה ש-wsl רץ בתוך VM בענן היא ש-nested virtualization נתמך רשמית בדיוק לרמה אחת.

5.3. הספקטרום של בידוד וקלות

סידור כל מה שכוסה עד כאן על ציר אחד נותן את הבא.

flowchart TB
    accTitle: הספקטרום של חוזק בידוד וקלות
    accDescr: containers ב-process isolation הם הקלים ביותר אבל חולקים את ה-kernel, WSL2, Sandbox ו-Hyper-V isolated containers הם VMs קלות עם kernel ייעודי (Sandbox הוקל בשיתוף מארח, WSL2 ב-kernel שנבנה למטרה), ו-VM מלא הוא הכבד ביותר אבל לשימוש כללי
    ax["קל ← → כבד"] ~~~ p1
    p1["Process-isolated container (kernel משותף)"] --> p2["WSL2, Sandbox, Hyper-V isolation (VMs קלות עם kernel ייעודי)"]
    p2 --> p3["VM מלא (מריץ הכול, מחזיק כל שכפול)"]
    p1 -.-> n1["גבול: namespaces"]
    p2 -.-> n2["גבול: hypervisor"]
    p3 -.-> n3["גבול: hypervisor + עצמאות מלאה"]

איור 14: ה-VMs הקלות הן אמצע הדרך ששמר על גבול ה-hypervisor תוך חיתוך שכפול; איך הן חותכות אותו שונה, עם שיתוף ל-Sandbox ו-kernel שנבנה למטרה ל-WSL2.

6. ראו זאת בעצמכם

קלות ושיתוף אפשר לצפות במכונה שלכם.

6.1. זמן עלייה של WSL2 וגידול והתכווצות זיכרון

עם Task Manager פתוח, נסו את הבא.

# תחושת זמן העלייה (בהרצה הראשונה ה-VM עולה; בהרצות הבאות זה מהיר יותר)
Measure-Command { wsl -e true }

# שימוש בזיכרון של ה-VM של WSL2 (vmmem / Virtual Machine Memory)
Get-Process -Name vmmem* | Select-Object Name, WorkingSet64

# מכבים את כל ה-VM ורואים את הזיכרון חוזר
wsl --shutdown

מריצים build גדול או פעולת קבצים בתוך WSL2 ו-vmmem גדל; wsl --shutdown מחזיר הכול בבת אחת, ואפשר לראות את זה קורה.

6.2. הבדלי מהירות ממיקום קבצים ב-WSL2

שמים את אותו מאגר בצד Linux (~/repo) ובצד Windows (/mnt/c/repo), משווים את הזמן שלוקחים git status או חילוץ, וההבדל מסעיף 3.2 עולה כמספרים.

6.3. עליית זיכרון בצד המארח כש-Sandbox עולה

מפעילים Sandbox וצופים בעליית הזיכרון ב-Task Manager של המארח. זה שנשאר קטן בהרבה ממה ש”Windows שני שלם” היה מציע הוא אפקט השיתוף.

כדי לחפור הלאה בפירוק הזיכרון בצד המארח, מאמר כלי Sysinternals שמכסה איך להשתמש ב-RAMMap וב-VMMap (“Process Explorer / Handle / VMMap בפועל”) הוא הפניה שימושית.

אלה, עם זאת, כלים לסיווג processes וזיכרון פיזי בצד המארח; הם אינם צופים ישירות בשיתוף עם האורח עצמו.

6.4. הבדלים בין מצבי בידוד של Windows containers

אם יש סביבת Windows container, מעלים את אותו image ב-docker run --isolation=process וב---isolation=hyperv, ואז משווים את זמן העלייה ומה ש-Task Manager מראה (תחת process isolation, ה-processes בתוך ה-container מופיעים ברשימת ה-processes של המארח) כדי לקבל תחושה איפה קו הבידוד יושב.⁷

Process isolation, עם זאת, דורש שגרסאות המארח וה-image יתאימו, וב-OS לקוח הוא מוגבל לשימוש פיתוח ובדיקה. Hyper-V isolation מתיר טווח רחב יותר של שילובים, לכן עושים את ההשוואה עם זוג תואם.¹⁰

7. שלוש קריאות שגויות להימנע מהן בפועל

7.1. “WSL2 איטי”

מה שאיטי אינו WSL2 אלא נתיב ה-file I/O שחוצה את גבול ה-OS. במקרים רבים, פשוט העברת הפרויקט לצד Linux משנה את החוויה.⁴ ולהפך, מיקום קבצים שכלי Windows נוגעים בהם בצד Linux הוא חיסרון מאותה סיבה. מחליטים לפי “לשים באותו OS כמו מי שמשתמש בזה”.

7.2. “vmmem שגדל גדול הוא memory leak”

זיכרון WSL2 גדל ומתכווץ עם הביקוש, וזיכרון משוחרר מוחזר. ב-WSL הנוכחי, autoMemoryReclaim (ברירת מחדל dropCache) תובע גם את ה-file cache אוטומטית, כך ש”זה נשאר גדול” בדרך כלל נפתר מעצמו עם הזמן.⁵

אם זה עדיין נשאר, בודקים ש-autoMemoryReclaim אינו disabled וש-pageReporting, שמחזיר זיכרון משוחרר, לא כובה (ושאינכם על WSL ישן); ואז או קובעים תקרה מפורשת עם memory ב-.wslconfig או מחזירים הכול עם wsl --shutdown בסוף סשן.

הגישה להחלטה אם זו leak זהה לזו שבחלק המבוא של סדרת הזיכרון, “מה באמת אומר Memory Usage ב-Windows”.

7.3. “זה ב-container, אז זה בטוח”

containers ב-process isolation חולקים את ה-kernel, ולפי הסטנדרט של Microsoft הם אינם גבול אבטחה.⁸ להרצת קוד לא מהימן או דגימות, בוחרים בידוד שיש לו גבול hypervisor: Hyper-V isolated container, Windows Sandbox, או VM ייעודי.

גבול hypervisor, עם זאת, אינו כרטיס חופשי אוניברסלי.

הגדרות ברירת המחדל של Windows Sandbox כוללות רשת מופעלת, מה שיכול לחשוף אפליקציה לא מהימנה לרשת הפנימית שלכם.¹ אם משתמשים בו להרצת דגימות, או מחזקים את הבידוד בכיבוי רשת והפניית clipboard בקובץ התצורה .wsb, או משתמשים ב-VM ייעודי ברשת מבודדת.

8. סיכום — סגירת הסדרה

נקודות המפתח של חלק 3.

• הקלות של VMs קלות היא תוצאה של “הפסקת שכפול”, לא של “החלשת בידוד”.
• WSL2 מריץ Linux kernel אמיתית ב-utility VM מנוהלת קלת-משקל, וההפצות מבודדות כ-containers בתוך ה-VM הזו.³ כלל הביצועים הוא לשים קבצים ב-OS שמשתמש בהם; הזיכרון גדל ומתכווץ דינמית, ו-.wslconfig שולט בתקרה.⁴⁵
• Windows Sandbox משתף את קובצי ה-OS הבלתי-משתנים של המארח דרך dynamic base image ואת הדפים הפיזיים של OS binaries רלוונטיים דרך direct map, כך שהוא אינו מחזיק עותק של Windows שלם.² כ-500 MB של קבצים משתנים וזיכרון האפליקציות שמריצים בתוכו עדיין נדרשים בנפרד.
• מצב בידוד של container נבחר בעלייה, והצד שאפשר לקרוא לו גבול אבטחה הוא Hyper-V isolation.⁷⁸

ושמים את כל הסדרה בעמוד אחד נותן את זה.

• חלק 1: מתחת ל-Windows יש שכבת hypervisor, ו-OS המארח עצמו רץ כ-root partition. השכבה הזו מתווכת CPU וזיכרון (SLAT) ישירות, ו-I/O ל-synthetic devices מתווך על ידי ה-root partition (VSP) בקצה הרחוק של VMBus.
• חלק 2: השכבה הזו משמשת לא רק לבידוד VMs זה מזה אלא גם למתוח גבול חזק מה-kernel (VTL) בתוך אותו OS. אבטחת ברירת המחדל של Windows 11 בנויה מעליה.
• חלק 3: על אותה שכבה, חיתוך שכפול הוא מה שמאפשר “virtual machine שעולה בשניות”. קו הבידוד נשמר, וזה הפך לכלי יומיומי.

flowchart TB
    accTitle: כל הסדרה בתמונה אחת
    accDescr: ה-hypervisor ישירות על החומרה הוא חלק 1, הפרדת VTL0 ו-VTL1 בתוך Windows המארח היא חלק 2, והקלות של WSL2, Sandbox ו-Hyper-V isolation על אותה שכבה היא חלק 3, עם containers ב-process isolation שחולקים את kernel המארח, Sandbox שהוקלה בשיתוף, ו-WSL2 ב-kernel שנבנה למטרה
    hw3["חומרה"] --> hv3["hypervisor (חלק 1)"]
    hv3 --> rp3["Windows המארח (הפרדת VTL היא חלק 2)"]
    hv3 --> lw3["WSL2, Sandbox, Hyper-V isolation (חלק 3)"]
    rp3 --> pc3["Process-isolated container (kernel משותף)"]
    lw3 -.-> mech3["Sandbox הוקל בשיתוף, WSL2 ב-kernel שנבנה למטרה"]

איור 15: עורמים את שלושת החלקים ומקבלים את התמונה הכוללת של מה שיושב מתחת ל-Windows של היום.

וירטואליזציה כבר אינה טכנולוגיית חדר שרתים, וגם לא רק למי שמעמיד VMs. מתחת ל-Windows שלכם, היא תומכת בשקט גם באבטחה וגם בחוויית הפיתוח. זה המצב היום.

מאמרים קשורים

• Windows Virtualization Internals (חלק 1) — איפה Windows שלכם באמת רץ: hypervisor ו-partitions
• Windows Virtualization Internals (חלק 2) — זיכרון שאפילו ה-kernel לא רואה: VBS, HVCI ו-Credential Guard
• Windows Memory Internals (חלק 3) — Section objects ו-Copy-on-Write
• איך מאיצים אימות אפליקציות עם Windows Sandbox
• הפניה מחדש ווירטואליזציה של Registry ב-Windows

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בהקמת סביבות פיתוח שמשתמשות ב-WSL2 וב-containers, בתכנון סביבות אימות לאפליקציות Windows, ובחקירת ביצועים ותאימות בסביבות וירטואליזציה.

• פיתוח אפליקציות Windows
• חקירת תקלות ואיתור גורמים
• מינוף נכסים קיימים והגירה
• יצירת קשר

קישורים

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

האם WSL2 הוא virtual machine?

כן. WSL2 מריץ Linux kernel אמיתית שבונה Microsoft בתוך utility VM קלת-משקל. ה-VM מנוהלת על ידי WSL מאחורי הקלעים, כך שהתכנון לעולם לא גורם למשתמש לחשוב על הגדרות VM או על המתנה ל-boot. כל הפצת Linux רצה כ-container מבודד בתוך ה-VM המנוהלת הזו.

למה פעולות קבצים תחת /mnt/c איטיות ב-WSL2?

כי גישה מ-Linux kernel של WSL2 למערכת הקבצים בצד Windows עוברת דרך שיתוף קבצים שחוצה גבול OS. פעולות על מערכת הקבצים של Linux (virtual disk מסוג ext4) מהירות, ולכן הכלל הוא לשמור קובצי פרויקט בצד ה-OS שבו הכלים שעובדים עליהם נמצאים.

האם שימוש גדול בזיכרון של process vmmem הוא leak?

ברוב המקרים זו אינה leak. זיכרון WSL2 גדל ומתכווץ עם השימוש, וזיכרון ש-processes שחררו מוחזר ל-Windows תחת ההגדרה pageReporting, שמופעלת כברירת מחדל. גם דפי file cache נתבעים בחזרה אוטומטית על ידי WSL הנוכחי דרך autoMemoryReclaim ב-.wslconfig (ברירת המחדל היא dropCache). בסביבות שבהן ההגדרות האלה הושבתו, או ב-WSL ישן יותר, הזיכרון יכול להישאר עד שה-VM יוצאת; במקרה כזה קבעו תקרה עם ההגדרה memory, או החזירו אותו עם wsl --shutdown.

איך Windows Sandbox יכול לאתחל Windows שלם מכמה מאות MB של דיסק?

דרך מנגנון שנקרא dynamic base image. הוא משתף את קובצי ה-OS הבלתי-משתנים מ-Windows שכבר מותקן במארח, ושומר עותק נקי רק של המספר הקטן של קבצים משתנים. זה מאפשר להרכיב image שלמה וברת-boot בלי לאחסן עותק מלא של Windows.

האם containers בטוחים יותר מ-virtual machines?

זה תלוי במצב הבידוד. containers ב-process isolation חולקים את ה-kernel עם המארח, ו-Microsoft לא מחשיבה זאת כגבול אבטחה חזק. כשמטפלים בקוד עוין, צריך Hyper-V isolation, שנותן לכל container kernel ייעודית משלו.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.