מעמקי הווירטואליזציה של Windows (חלק 3) — מכונות וירטואליות שעולות בשניות: למה WSL2, Windows Sandbox וקונטיינרים כל כך קלים

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

שניהם נשענים על אותו היפרווייזור של Windows (חלק 1, “היכן Windows שלכם באמת רץ?”). בחלק 2 ראינו שהיסוד הזה יכול ליצור בידוד חזק מהליבה. אז למה האחד כבד והאחר קל?

השאלה שהפרק האחרון של הסדרה עונה עליה היא אחת בלבד.

מכונות וירטואליות מלאות כבדות — אז למה WSL2 ו-Windows Sandbox כל כך קלים?

קהל היעד הוא מפתחות, מפתחים ומפעילים שמשתמשים ב-WSL2, ב-Windows Sandbox ובקונטיינרים של Windows לפיתוח ולאימות, ורוצים להבין את הקלילות ואת האילוצים שלהם מהמנגנונים ומעלה. דרישות מוקדמות הן Windows 10/11; מעבר על סעיף Windows Sandbox דורש מהדורת Pro, Enterprise או Education (ל-Home ול-Windows Server אין את התכונה הזו). ידע רקע הוא מושג המחיצות מחלק 1. רמת הקושי היא בינונית.

1. השורה התחתונה קודם

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

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

flowchart TB
    accTitle: שלושה סוגי שיתוף שתומכים במכונות וירטואליות קלות
    accDescr: תמונת מערכת ההפעלה שמכונה וירטואלית מלאה נהגה לשכפל נחתכת בשיתוף ב-Sandbox ובכיווץ ב-WSL2; זיכרון שהוא הקצאה קבועה כברירת מחדל （זיכרון דינמי הוא החריג） הופך להשאלה והחזרה דינמית עם המארח; האתחול מוחלף בליבה קלה ובהקמה מינימלית; רק גבול הבידוד נשאר
    heavy["מכונה מלאה: שכפול"] --> d1["דיסק: עותק תמונת מערכת"]
    heavy --> more{"זיכרון או אתחול?"}
    more --> d2["זיכרון: ברירת מחדל קבועה"]
    more --> d3["אתחול: אתחול מלא"]
    d1 -->|מוחלף ב| s1["שיתוף（Sandbox）"]
    s1 -.-> s1b["או כיווץ（WSL2）"]
    d2 -->|מוחלף ב| s2["השאלה דינמית מהמארח"]
    d3 -->|מוחלף ב| s3["ליבה קלה + מינימום"]

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

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

2. מה מכונה וירטואלית מלאה נושאת

כבסיס להשוואה, הנה מה שמכונה וירטואלית מסורתית נושאת.

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

flowchart TB
    accTitle: שלושת העומסים שמכונה וירטואלית מלאה נושאת
    accDescr: מכונה וירטואלית מלאה נושאת תמונת מערכת הפעלה עצמאית, הקצאת זיכרון שהיא סטטית כברירת מחדל, ואתחול מלא למטרות כלליות, ואלה מופיעים כעלויות בדיסק, ב-RAM ובזמן אתחול
    fullvm["מכונה מלאה"] --> b1["תמונת מערכת עצמאית"]
    fullvm --> more{"זיכרון או אתחול?"}
    more --> b2["ברירת מחדל סטטית לזיכרון"]
    more --> b3["אתחול למטרות כלליות"]
    b1 -.-> c1["דיסק נוסף לעותק"]
    b2 -.-> c2["מחזיק גם RAM לא בשימוש"]
    b3 -.-> c3["לוקח עשרות שניות"]

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

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

3. WSL2 — מכונה וירטואלית שירותית עם ליבה ייעודית

3.1. מבנה: מכונה וירטואלית מנוהלת וההפצות שבתוכה

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

• הליבה אמיתית, אבל היא מוצר מתמחה. זו ליבת Linux ש-Microsoft בונה מענף Stable, שכבר כווננה בגודל ובביצועים ל-WSL2. בתקן הנוכחי, WSL המופץ מ-Microsoft Store, הליבה מתעדכנת יחד עם חבילת WSL עצמה ומוחלת עם wsl --update (בהפצה הישנה יותר שבתוך הקופסה היא הגיעה דרך Windows Update).⁴ מכיוון שזו ליבה אמיתית, תאימות קריאות המערכת שלמה, וכלים כמו Docker רצים כמות שהם.
• המכונה הווירטואלית מאחורי הקלעים. יצירה, הפעלה ועצירה של המכונה הווירטואלית מנוהלות על ידי WSL; המשתמש רק פותח מעטפת. אין מסך הגדרות מכונה וירטואלית ואין המתנה מורגשת לאתחול.⁴
• הפצה היא קונטיינר בתוך המכונה הווירטואלית. הפצות כמו Ubuntu ו-Debian רצות כקונטיינרים מבודדים בתוך מכונה וירטואלית מנוהלת אחת. הן חולקות את מרחב השמות של הרשת ואת הליבה, בעוד שמרחבי שמות כמו PID, mount ו-user מופרדים.³

flowchart TB
    accTitle: ארכיטקטורת WSL2
    accDescr: Windows מארח ומכונה וירטואלית שירותית קלת-משקל יושבים זה לצד זה על ההיפרווייזור; ליבת Linux שבונה Microsoft רצה בתוך המכונה הווירטואלית; וכל הפצה רצה כקונטיינר מבודד בתוכה
    hv["היפרווייזור"] --> 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. I/O של קבצים: באיזה צד שמים את זה הופך את זה לדבר אחר

הנושא שתמיד עולה בשיחה על ביצועי 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: ההתפצלות בנתיבי I/O של קבצים ב-WSL2
    accDescr: גישה לדיסק הווירטואלי ext4 בצד Linux היא ישירה מליבת Linux ולכן מהירה; גישה לקבצים בצד Windows עוברת דרך שיתוף קבצים שחוצה גבול מערכת הפעלה ולכן איטית
    io["פעולות קבצים בתוך WSL2"] --> place{"באיזה צד הקובץ?"}
    place -->|"צד Linux （home וכדומה）"| ext4["I/O ישיר לדיסק הווירטואלי ext4"]
    place -->|"צד Windows （/mnt/c וכדומה）"| p9["דרך שיתוף שחוצה גבול מערכת"]
    ext4 --> fast["מהיר （דוגמאות של עד פי 20 מול WSL1）"]
    p9 --> slow["נוטה להיות איטי"]
    slow -.-> fix["תיקון: שימו את הקובץ במערכת שמשתמשת בו"]

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

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

שימוש הזיכרון של WSL2 (רואים אותו כתהליך vmmem במנהל המשימות) אינו שמורה קבועה; הוא גדל ומתכווץ עם השימוש. זיכרון שתהליכים שחררו מוחזר אוטומטית ל-Windows תחת ההגדרה pageReporting, שמופעלת כברירת מחדל.⁵ דפים שמוחזקים כמטמון קבצים נהגו לא לחזור ל-Windows עד שהמכונה הווירטואלית יצאה.⁴ ב-WSL הנוכחי, ההגדרה הניסיונית autoMemoryReclaim ב-.wslconfig (ברירת המחדל היא 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 של המארח

4.1. תמונת בסיס דינמית: Windows שלם ב-500 מגה-בתים

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

החידה הראשונה היא הדיסק. הוא יכול לאתחל 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 דרך אובייקטי section, שעקבנו אחריו בחלק 3 של סדרת הזיכרון (“אובייקטי Section ו-Copy-on-Write”). המנגנון ההוא היה שיתוף בין תהליכים; 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["Working Sets של תהליכים רגילים"]
    from --> sbx["השימוש של ה-Sandbox （הקונטיינר）"]
    proc --> relief["זיכרון פנוי מובטח"]
    sbx --> relief
    relief -.-> contrast["למכונה מסורתית אמצעי התאמה מוגבלים"]

איור 10: בהשאלה ובהחזרה של זיכרון, Sandbox עומד בצד התהליך ולא בצד המכונה הווירטואלית, ומציע זיכרון כשהמארח בצרה.

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

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

5. קונטיינרים — היכן משרטטים את קו הבידוד

5.1. בידוד תהליך ובידוד Hyper-V

לקונטיינרים של Windows יש שני מצבי בידוד בזמן ריצה. התמונה משותפת; בוחרים עם דגל בהפעלה.⁷

• בידוד תהליך: כמה קונטיינרים חולקים את הליבה עם המארח ומבודדים דרך וירטואליזציה לפי-מרחב-שמות של מערכת הקבצים, הרישום, פורטי רשת, מרחב מזהי תהליכים, מרחב השמות של Object Manager וכדומה. זו בעצם אותה גישה כמו קונטיינרים של Linux.
• בידוד Hyper-V: כל קונטיינר רץ בתוך מכונה וירטואלית ממוטבת מאוד ויש לו מה שבפועל ליבה ייעודית. נוכחות המכונה הווירטואלית שמה בידוד ברמת חומרה בין הקונטיינרים למארח.⁷

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

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 לא מחשיבה קונטיינר מבודד-תהליך כגבול אבטחה חזק. הקונטיינרים שמתוחזקים (עם תגובה לפגיעויות) כגבול אבטחה הם קונטיינרים מבודדי-היפרווייזור, ובידוד Hyper-V הוא מה שצריך לבחור בתרחיש רב-דייר עוין.⁸

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

flowchart TB
    accTitle: איך לבחור בידוד לפי כמה סומכים על הקוד
    accDescr: אם עומס העבודה מהימן, לוקחים צפיפות וביצועים עם בידוד תהליך; אם הקוד לא מהימן או של מישהו אחר, בוחרים גבול היפרווייזור כמו קונטיינר מבודד-Hyper-V, Windows Sandbox מוקשח עם רשת כבויה, או מכונה וירטואלית מבודדת
    trust{"אפשר לסמוך על הקוד הזה?"} -->|כן| dens["בידוד תהליך （עדיפות לצפיפות ומהירות）"]
    trust -->|לא / קוד של מישהו אחר| bound["בחירת גבול היפרווייזור"]
    bound --> opt1["קונטיינרים מבודדי Hyper-V"]
    bound --> opt2["Sandbox מוקשח או מכונה מבודדת"]

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

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

flowchart TB
    accTitle: המבנה של וירטואליזציה מקוננת
    accDescr: מכונה וירטואלית בענן יושבת על ההיפרווייזור של המארח הפיזי, ובתוכה רץ היפרווייזור אחר （קינון נתמך הוא רמה אחת） כדי לתמוך ב-WSL2 ובקונטיינרים מבודדי Hyper-V
    phys3["ההיפרווייזור של המארח הפיזי"] --> cvm["מכונה בענן （מחשב פיתוח）"]
    cvm --> nhv["היפרווייזור בתוך המכונה （רמת קינון 1）"]
    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["גבול: היפרווייזור"]
    p3 -.-> n3["גבול: היפרווייזור + עצמאות שלמה"]

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

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

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

זמן הפעלה ועלייה וירידה של זיכרון (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.

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

רקע ל-direct map ‏(Sandbox). הפעילו Sandbox והסתכלו על הגידול בזיכרון במנהל המשימות במארח. שהגידול נשאר קטן בהרבה ממה ש”עוד Windows” היה מוביל לדמיין הוא אפקט השיתוף שמספר את סיפורו. כדי לחפור הלאה לפירוק הזיכרון בצד המארח, המאמר על כלי Sysinternals שמכסה איך להשתמש ב-RAMMap וב-VMMap (“Process Explorer / Handle / VMMap בפועל”) שימושי. אלה, עם זאת, כלים להסתכלות על סיווג תהליכים וזיכרון פיזי בצד המארח; הם לא צופים ישירות בשיתוף עם האורח עצמו.

מצבי בידוד קונטיינר (Docker / קונטיינרים של Windows). אם יש לכם סביבת קונטיינרים של Windows, הפעילו את אותה תמונה עם docker run --isolation=process ועם --isolation=hyperv והשוו זמן הפעלה ואיך זה נראה במנהל המשימות (תחת בידוד תהליך, תהליכים בתוך הקונטיינר מופיעים ברשימת התהליכים של המארח), ותוכלו להרגיש היכן קו הבידוד יושב.⁷ בידוד תהליך, עם זאת, מניח שגרסאות המארח והתמונה תואמות, ובמערכת הפעלה לקוח הוא מוגבל לשימוש בפיתוח ובבדיקה. בידוד Hyper-V מתיר קבוצה רחבה יותר של שילובים, אז עשו את ההשוואה על זוג תואם.¹⁰

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

7.1. “WSL2 איטי”

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

7.2. “vmmem שגדל גדול הוא דליפת זיכרון”

זיכרון WSL2 גדל ומתכווץ עם הביקוש, וחלקים ששוחררו מוחזרים. ב-WSL הנוכחי, גם מטמון קבצים נתבע בחזרה אוטומטית על ידי autoMemoryReclaim (ברירת המחדל היא dropCache), כך ש”הוא נשאר גדול” לעיתים קרובות נפתר עם הזמן.⁵ אם הוא עדיין נשאר, אשרו ש-autoMemoryReclaim לא הוגדר ל-disabled וש-pageReporting, שאחראי להחזרת חלקים ששוחררו, לא כובה (או שאתם לא על WSL ישן), ואז או עשו את התקרה מפורשת עם memory ב-.wslconfig או החזירו הכול עם wsl --shutdown בגבול סשן. דרך החשיבה על הבחנה בין דליפה ללא-דליפה זהה לזו שבפרק המבוא של סדרת הזיכרון, “מה “שימוש בזיכרון” של Windows באמת אומר?”.

7.3. “זה בקונטיינר, אז זה בטוח”

קונטיינר מבודד-תהליך חולק את הליבה, ולפי הקריטריון של Microsoft הוא אינו גבול אבטחה.⁸ להרצת קוד לא מהימן או דגימה, בחרו בידוד שיש לו גבול היפרווייזור, כמו קונטיינר מבודד-Hyper-V, Windows Sandbox או מכונה וירטואלית ייעודית. גבול היפרווייזור, עם זאת, אינו פטור כולל. להגדרות ברירת המחדל של Windows Sandbox יש קישוריות רשת מופעלת, והן יכולות לחשוף יישום לא מהימן לרשת הפנימית.¹ אם משתמשים בו להרצת דגימה, חזקו את הבידוד בהשבתת רשת והפניית לוח בלוח בקובץ התצורה .wsb, או השתמשו במכונה וירטואלית ייעודית ברשת מבודדת.

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

נקודות חלק 3.

• הקלילות של מכונה וירטואלית קלת-משקל היא תוצאה של “הפסקת שכפול”, לא של “החלשת בידוד”.
• WSL2 מריץ ליבת Linux אמיתית במכונה וירטואלית שירותית קלת-משקל מנוהלת, והפצות מבודדות כקונטיינרים בתוך המכונה הווירטואלית הזו.³ כלל הביצועים הוא לשים קבצים במערכת ההפעלה שמשתמשת בהם, והזיכרון גדל ומתכווץ באופן דינמי, עם תקרה שניתן לשלוט בה ב-.wslconfig.⁴⁵
• Windows Sandbox משתף את קובצי מערכת ההפעלה הבלתי-משתנים של המארח דרך תמונת בסיס דינמית וגם משתף את הדפים הפיזיים של קבצי מערכת היעד דרך direct map, כך שהוא לא מחזיק עותק של Windows שלם.² עדיין צריך כ-500 מגה-בתים לקבצים המשתנים, ועוד את הזיכרון של היישומים שמריצים בתוכו.
• מצב בידוד הקונטיינר נבחר בהפעלה, והצד שאפשר לקרוא לו גבול אבטחה הוא בידוד Hyper-V.⁷⁸

ואם שמים את כל הסדרה על דף אחד, זה נראה כך.

• חלק 1: יש שכבת היפרווייזור מתחת ל-Windows, ומערכת ההפעלה המארחת עצמה רצה כמחיצת השורש. בוררות המעבד והזיכרון (SLAT) נעשית ישירות על ידי השכבה הזו, ו-I/O של התקנים סינתטיים מתווך על ידי מחיצת השורש (VSP) מעבר ל-VMBus.
• חלק 2: השכבה הזו משמשת לא רק לבידוד מכונות וירטואליות זו מזו אלא גם לשרטוט גבול חזק מהליבה (VTL) בתוך אותה מערכת הפעלה. אבטחת ברירת המחדל של Windows 11 בנויה מעל זה.
• חלק 3: על אותה שכבה, חיתוך שכפול הוא מה שמאפשר “מכונה וירטואלית שעולה בשניות”. קו הבידוד נשמר, והוא הפך לכלי יומיומי.

flowchart TB
    accTitle: תמונה אחת של כל הסדרה
    accDescr: ההיפרווייזור ישירות על החומרה הוא חלק 1; פיצול VTL0 ו-VTL1 בתוך Windows המארח הוא חלק 2; הקלילות של WSL2, Sandbox ובידוד Hyper-V על אותה שכבה היא חלק 3; קונטיינרים מבודדי-תהליך חולקים את ליבת המארח; Sandbox מקל בשיתוף, WSL2 בליבה ייעודית
    hw3["חומרה"] --> hv3["היפרווייזור （חלק 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 שלכם באמת רץ? ההיפרווייזור והמחיצות
• מעמקי הווירטואליזציה של Windows (חלק 2) — זיכרון שאפילו הליבה לא יכולה לראות: איך VBS, HVCI ו-Credential Guard עובדים
• מעמקי הזיכרון של Windows (חלק 3) — אובייקטי Section ו-Copy-on-Write: מה DLL ומיפויי קבצים באמת הם
• איך להאיץ אימות יישומים עם Windows Sandbox
• מלכודות הפניה מחדש ווירטואליזציה של הרישום 32/64 סיביות — Wow6432Node ובעיית “הערך שכתבתי לא שם”

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

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

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

קישורים

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

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

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

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

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

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

שאלות נפוצות

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

האם WSL2 הוא מכונה וירטואלית?

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

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

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

האם שימוש גדול בזיכרון של תהליך vmmem הוא דליפה?

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

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

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

האם קונטיינרים בטוחים יותר ממכונות וירטואליות?

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

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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