כשמפעילים Hyper-V, היכן Windows המארח באמת רץ?

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

האם "וירטואליזציה: מופעלת" במנהל המשימות אומר ש-Hyper-V רץ?

לא. התצוגה הזו מראה אם הרחבות הווירטואליזציה של המעבד (Intel VT-x/AMD-V) מופעלות בקושחה. כדי לראות אם היפרווייזור באמת רץ, חפשו "A hypervisor has been detected" ב-systeminfo, או בדקו את Win32_ComputerSystem.HypervisorPresent.

למה ההיפרווייזור רץ אף שמעולם לא יצרתי מכונה וירטואלית?

ב-Windows 11, אבטחה מבוססת וירטואליזציה (VBS) מופעלת כברירת מחדל במכשירים שעומדים בתנאים — למשל התקנה נקייה על חומרה תואמת — ו-VBS בנוי על ההיפרווייזור של Windows. אותו דבר אם משתמשים ב-WSL2 או ב-Windows Sandbox. זה לא חריג שההיפרווייזור רץ בלי קשר לכך שמישהו משתמש במכונות וירטואליות.

מהו SLAT, ולמה Hyper-V דורש אותו?

SLAT ‏(Second Level Address Translation) הוא המנגנון שבו המעבד מתרגם כתובות פיזיות של האורח לכתובות פיזיות אמיתיות; Intel EPT ו-AMD RVI הם המימושים. בלי זה ההיפרווייזור היה צריך לתחזק את טבלאות התרגום בתוכנה, וזה לא ריאלי מבחינת ביצועים, ולכן Hyper-V הנוכחי מתייחס אליו כדרישה קשיחה.

אם אפעיל Hyper-V, VirtualBox ו-VMware יפסיקו לעבוד?

מכיוון שההיפרווייזור משתמש בהרחבות הווירטואליזציה של המעבד באופן בלעדי, היפרווייזור צד שלישי לא יכול לרוץ בדרך המסורתית. עם זאת, ל-VirtualBox ול-VMware הנוכחיים יש מצב שרץ מעל ההיפרווייזור של Windows (דרך Windows Hypervisor Platform), כך שגרסאות עדכניות של כל אחד יכולות לדור בכפיפה אחת.

מעמקי הווירטואליזציה של Windows (חלק 1) — היכן Windows שלכם באמת רץ? ההיפרווייזור והמחיצות

22 Aug 2026 02:00 · Go Komura · Windows, וירטואליזציה, Hyper-V, היפרווייזור, SLAT, VMBus

פתחו את מידע המערכת (msinfo32) ב-Windows 11 ולעיתים קרובות תראו “Running” בשדה “Virtualization-based security” — גם במחשב שמעולם לא יצרתם בו מכונה וירטואלית.

מה שזה אומר הוא העובדה הבאה. במחשב הזה, Windows המארח עצמו כבר רץ מעל היפרווייזור. “וירטואליזציה” כבר אינה טכנולוגיה רק למי שיוצרים מכונות וירטואליות במנהל Hyper-V. ב-Windows 11, אבטחה מבוססת וירטואליזציה (VBS) מופעלת כברירת מחדל בתצורות שעומדות בתנאים — למשל התקנה נקייה על חומרה תואמת¹ — וגם WSL2 וגם Windows Sandbox בנויים על אותו היפרווייזור של Windows. מתחת ל-Windows שאתם משתמשים בו כל יום כבר יש עוד שכבת תוכנה אחת.

הסדרה הזו, “מעמקי הווירטואליזציה של Windows”, עוקבת אחרי מה שקורה בשכבה הזו, החל מהיסודות.

“מעמקי הווירטואליזציה של Windows” — כל 3 החלקים

חלק 1 (המאמר הזה): ההיפרווייזור והמחיצות
אנחנו עוקבים אחרי לאן Windows המארח מגיע לרוץ כשמפעילים Hyper-V.
חלק 2: זיכרון שאפילו הליבה לא יכולה לראות — VBS,‏ HVCI ו-Credential Guard
אנחנו עוקבים אחרי לאן Windows שם סודות שאף מנהל ואף הליבה לא יכולים לקרוא.
חלק 3: מכונות וירטואליות שעולות בשניות — WSL2,‏ Windows Sandbox וקונטיינרים
אנחנו עוקבים, מאופן שיתוף הזיכרון והתמונות, למה WSL2 ו-Sandbox קלים אף שמכונה וירטואלית מלאה כבדה.

השאלה שחלק 1 עונה עליה היא אחת בלבד.

כשמפעילים Hyper-V, היכן Windows המארח מגיע לרוץ?

קהל היעד הוא מפתחות, מפתחים ומפעילים שמשתמשים ב-Hyper-V, ב-WSL2 או ב-Windows Sandbox ורוצים להבין מהמנגנון ומעלה מה רץ מתחת. דרישות מוקדמות הן Windows 10/11 x64 או Windows Server עדכני (דיון הטבעות, VT-x/AMD-V ו-EPT/RVI במאמר הזה מניח x64; ל-Arm64 יש מנגנון אחר כמו רמות חריגה). הרקע הנדרש הוא בערך ההבחנה בין מצב ליבה למצב משתמש; אין צורך בניסיון תפעול מכונות וירטואליות או בידע בפיתוח היפרווייזור. רמת הקושי היא בינונית. אנחנו מכסים את מושג הרחבות הווירטואליזציה של המעבד, אבל לא נכנסים לפרטי ערכת ההוראות.

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

כשאנשים שומעים Hyper-V, הם עשויים לדמיין “תוכנת הרצת מכונות וירטואליות שיושבת מעל Windows”. המבנה בפועל הפוך.

מרגע שמפעילים Hyper-V ומאתחלים, זה ההיפרווייזור ששולט במעבדים ובזיכרון הפיזיים, ו-Windows המארח רץ מעליו כמחיצה הראשונה, בעלת ההרשאות — “מחיצת השורש”.

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

flowchart TB
    accTitle: המבנה הכללי אחרי הפעלת Hyper-V
    accDescr: ההיפרווייזור יושב ישירות על החומרה הפיזית, ומעליו יושבות מחיצת השורש שמחזיקה את Windows המארח ומחיצות הבת שמחזיקות מכונות וירטואליות
    hw["חומרה פיזית"] --> hv["היפרווייזור"]
    hv --> root["מחיצת השורש （Windows המארח）"]
    hv --> child1["מחיצות בת （מכונות וירטואליות）"]
    root -.-> stack["מחזיק את מחסנית ניהול הווירטואליזציה ומנהלי ההתקנים"]

איור 1: Hyper-V אינו “תוכנת מכונות וירטואליות מעל Windows” אלא שכבה שנכנסת מתחת ל-Windows, ומערכת ההפעלה המארחת עצמה רצה בתוך מחיצת השורש.

אפשר לחשוב, “אם לא מרגישים שום הבדל אחרי ההפעלה, האם באמת התרחש היפוך כה גדול?” כן. זו בדיוק הסיבה שהמבנה הזה בדרך כלל לא מורגש. במאמר הזה מפרקים את התרשים היחיד הזה לאורך שלושה צירים: מעבד, זיכרון ו-I/O של התקנים.

2. מצד המעבד — עוד הרשאה אחת מתחת לטבעות

2.1. חזרה על הגנת טבעות

למעבדי x64 יש רמות הרשאה (טבעות), ו-Windows מריץ מצב ליבה בטבעת 0 ומצב משתמש בטבעת 3. יישומים לא יכולים לגעת בחומרה ישירות כי אי אפשר לבצע הוראות בעלות הרשאה מטבעת 3.

אז איך מאחסנים בבטחה כמה ליבות מערכת הפעלה, שכל אחת רצה בטבעת 0, על אותו מעבד פיזי? כל ליבה כתובה מתוך הנחה ש”אני שולטת במעבד”. תנו טבעת 0 לכולן והן מתנגשות; תמנעו אותה והן לא ירוצו.

flowchart TB
    accTitle: הבעיה של כמה ליבות מערכת הפעלה שדורשות טבעת 0
    accDescr: גם ליבת המארח וגם ליבת האורח כתובות מתוך הנחת סמכות מלאה בטבעת 0, כך שסולם הטבעות המסורתי לבדו לא יכול לאחסן אותן בבטחה על אותו מעבד פיזי
    k1["ליבת המארח （מניחה טבעת 0）"] --> want["דורשת שליטה במעבד הפיזי"]
    k2["ליבת האורח （מניחה טבעת 0）"] --> want
    want --> conflict["הטבעות המסורתיות לא יכולות ליישב זאת"]
    conflict --> need["נדרש מתווך מעל טבעת 0"]

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

2.2. הרחבות וירטואליזציה — מצב השמור להיפרווייזור

מה שפותר את הבעיה הזו הוא הרחבות הווירטואליזציה של המעבד (Intel VT-x/AMD-V). Hyper-V דורש מעבד שיש לו את התכונה הזו.² הרחבות וירטואליזציה מוסיפות, על ציר נפרד מהטבעות המסורתיות, “מצב ביצוע להיפרווייזור” ו”מצב ביצוע לאורחים”. זו הרשאה חזקה אף יותר מטבעת 0, שלפעמים מכונה בכינוי “טבעת ‎-1”.

ליבת האורח ממשיכה לרוץ בטבעת 0, כמו קודם. אין צורך בכתיבה מחדש.
עם זאת, טבעת 0 הזו היא “טבעת 0 בתוך מצב אורח”, והיא לא שולטת במעבד הפיזי כולו.
כשהאורח פוגע בפעולה מסוימת שדורשת התערבות היפרווייזור (הוראה שהוגדרה כיירוט, או חריגה או הפרה), המעבד מעביר שליטה אוטומטית להיפרווייזור (VM Exit). כשההיפרווייזור מסיים לטפל, הוא חוזר לאורח (VM Entry). גישות זיכרון רגילות עוברות בלי VM Exit, כל עוד תרגום SLAT מצליח.

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

flowchart TB
    accTitle: זרימת ביצוע האורח ו-VM Exit
    accDescr: ליבת האורח והיישומים רצים בטבעת 0 ובטבעת 3 במצב אורח; גישות זיכרון רגילות עוברות דרך תרגום SLAT, ואילו יירוטים וחריגות שהוגדרו גורמים ל-VM Exit שמעביר שליטה להיפרווייזור, שחוזר לאורח דרך VM Entry
    guest["ריצה במצב אורח （כולל ליבה בטבעת 0）"] --> op{"פעולה שצריכה התערבות? （יירוטים/חריגות שהוגדרו）"}
    op -->|לא| cont["המשך ביצוע כמות שהוא"]
    op -->|כן| exitEv["VM Exit （המעבד מעביר שליטה）"]
    exitEv --> hvp["ההיפרווייזור מטפל"]
    hvp --> entry["חזרה לאורח דרך VM Entry"]
    entry --> guest

איור 3: מערכת ההפעלה האורחת ממשיכה לרוץ בטבעת 0 בלי כתיבה מחדש, והמעבד קורא להיפרווייזור רק כשצריך.

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

2.3. Type 1 ו-Type 2 — ההבדל הוא איפה זה יושב

היפרווייזורים מחולקים בגדול ל-Type 1 (bare-metal), שרץ ישירות על החומרה, ול-Type 2 (hosted), שרץ מעל מערכת הפעלה מארחת. Hyper-V הוא Type 1.³ VirtualBox ו-VMware Workstation (כשרצים עצמאית) מסווגים כ-Type 2.

כששומעים Type 1, אנשים נוטים לדמיין “תצורת שרת בלבד בלי מערכת הפעלה מארחת”, אבל Hyper-V שונה. Windows המארח לא נעלם — הוא “עובר דירה” למחיצת השורש. כשמפעילים Hyper-V ומאתחלים, ההיפרווייזור מתחיל ראשון במהלך האתחול, ואז Windows המארח עולה כמחיצת השורש מעליו.

flowchart TB
    accTitle: ההבדל בין היפרווייזור Type 1 ל-Type 2
    accDescr: ב-Type 2 מערכת ההפעלה המארחת יושבת על החומרה וההיפרווייזור והמכונות הווירטואליות יושבים על מערכת ההפעלה המארחת, ואילו ב-Type 1 של Hyper-V ההיפרווייזור יושב ישירות על החומרה ומערכת ההפעלה המארחת עצמה נכנסת למחיצת השורש מעליו
    subgraph t2 ["Type 2 （hosted）"]
        hw2["חומרה"] --> hostos["מערכת הפעלה מארחת"]
        hostos --> hv2["היפרווייזור"]
        hv2 --> vm2["מכונה וירטואלית"]
    end
    subgraph t1 ["Type 1 （Hyper-V）"]
        hw1["חומרה"] --> hv1["היפרווייזור"]
        hv1 --> root1["מחיצת השורש （מערכת מארחת）"]
        hv1 --> vm1["מכונה וירטואלית"]
    end
    vm2 ~~~ hw1

איור 4: ב-Type 2 ההיפרווייזור יושב על מערכת ההפעלה המארחת, ואילו ב-Type 1 של Hyper-V הסדר הפוך ומערכת ההפעלה המארחת עצמה יושבת על השכבה צעד אחד מתחת.

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

flowchart TB
    accTitle: סדר האתחול אחרי הפעלת Hyper-V
    accDescr: אחרי הפעלה, ההיפרווייזור מתחיל ראשון במהלך האתחול, Windows המארח עולה אז כמחיצת השורש מעליו, ומכונות וירטואליות, VBS וכדומה מתחילים אחרי זה
    poweron["הפעלה והתחלת אתחול"] --> bhv["ההיפרווייזור מתחיל ראשון"]
    bhv --> broot["Windows המארח עולה כמחיצת השורש"]
    broot --> blater["מכונות וירטואליות, VBS, WSL2 וכדומה עולים מעל זה"]
    broot -.-> feel["חוויית המשתמש לא משתנה"]

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

3. מחיצות — יחידת הבידוד

3.1. תפקידים שיש רק למחיצת השורש

מחיצה היא יחידת בידוד לוגית שההיפרווייזור מספק.² עם זאת, לא כל המחיצות שוות. יש דברים שיש רק למחיצת השורש.

גישה ישירה להתקנים פיזיים. מנהלי התקנים לדיסקים, לכרטיסי רשת, ל-GPU וכדומה חיים ב-Windows שבתוך מחיצת השורש, לא בהיפרווייזור. ל-Hyper-V ב-Windows Server יש תצורה שמקצה התקן PCIe מסוים ישירות למחיצת בת (Discrete Device Assignment); במקרה כזה השורש מרפה מההתקן הזה (זה אינו זמין ב-Windows הלקוח).⁴
מחסנית ניהול הווירטואליזציה. VMMS ‏(Virtual Machine Management Service), ששולט ביצירה, בהפעלה ובעצירה של מכונות וירטואליות, ותהליך העבודה לכל מכונה (vmwp.exe) רצים במצב משתמש במחיצת השורש.⁵ אלה חלק מתכונות ניהול המכונות הווירטואליות של Hyper-V, ולכן הן עשויות להיעדר במארח שבו רק ההיפרווייזור רץ עבור VBS או WSL2.
הזכות ליצור מחיצות בת. מחיצת השורש יוצרת מחיצות בת דרך ה-API של hypercall (ממשק הקריאה אל ההיפרווייזור).²

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

flowchart TB
    accTitle: חלוקת התפקידים בין מחיצת השורש למחיצות בת
    accDescr: מחיצת השורש מחזיקה את מחסנית ניהול הווירטואליזציה ואת מנהלי ההתקנים הפיזיים ויוצרת מחיצות בת דרך hypercall; מחיצת בת רואה בדרך כלל רק התקנים וירטואליים, ותחת Discrete Device Assignment ב-Windows Server היא ניגשת להתקן שהוקצה ישירות
    subgraph rootp ["מחיצת השורש"]
        vmms["VMMS ותהליכי עבודה"]
        drv["מנהלי התקנים פיזיים"]
    end
    subgraph childp ["מחיצת בת"]
        gos["מערכת הפעלה אורחת"]
        vdev["בתצורה הרגילה נראים רק התקנים וירטואליים"]
    end
    vmms -->|יצירה וניהול דרך hypercall| childp
    hv2["היפרווייזור （מצמצם עצמו לתיווך מעבד וזיכרון）"] --- rootp
    hv2 --- childp

איור 6: הנחת מנהלי התקנים ומחסנית הניהול בצד מחיצת השורש היא מה ששומר על ההיפרווייזור עצמו דק.

3.2. העולם כפי שנראה ממחיצת בת

מערכת ההפעלה האורחת במחיצת בת לא יכולה לראות חומרה פיזית ישירות בתצורת ההתקנים הווירטואליים הרגילה (החריג היחיד הוא התקן שהוקצה דרך Discrete Device Assignment ב-Windows Server, כפי שתואר בסעיף הקודם). מה שהיא יכולה לראות הם מעבדים וירטואליים, מרחב זיכרון שנראה כשלה, והתקנים וירטואליים. בקשות להתקנים וירטואליים מועברות למחיצת השורש דרך VMBus או ההיפרווייזור.² הקצאת זמן מעבד ותרגום זיכרון דרך SLAT, לעומת זאת, מטופלים ישירות על ידי ההיפרווייזור בלי לעבור דרך השורש. מה שהשורש מתווך הוא I/O של התקנים, לא כל משאב פיזי.

flowchart TB
    accTitle: העולם כפי שנראה ממחיצת בת
    accDescr: מה שמערכת ההפעלה האורחת רואה הוא מעבדים וירטואליים, מרחב זיכרון פרטי למחיצה והתקנים וירטואליים; בקשות להתקנים וירטואליים מועברות למחיצת השורש דרך VMBus וכדומה, זמן מעבד ותרגום זיכרון מטופלים ישירות על ידי ההיפרווייזור, ובתצורת Discrete Device Assignment ב-Windows Server רק התקנים שהוקצו נגישים ישירות
    gos2["מערכת אורחת（בת）"] --> vcpu["מעבדים וירטואליים"]
    gos2 --> rest{"זיכרון או התקנים?"}
    rest --> gpa2["מרחב זיכרון פרטי"]
    rest --> vdev2["התקנים וירטואליים"]
    vdev2 --> rootx["מועבר לשורש"]
    rootx -.-> vbus["דרך VMBus וכדומה"]
    gos2 -.-> phys2["מעבד, RAM, התקנים פיזיים"]
    phys2 -.-> hid["לא נראים ישירות"]
    phys2 -.-> dda2["DDA: התקנים שהוקצו"]
    dda2 -.-> ddaN["Windows Server"]
    vcpu ~~~ phys2

איור 7: בתצורת ההתקנים הווירטואליים הרגילה כל מה שהאורח רואה הוא חלון וירטואלי והנתיב לפיזי עובר דרך מתווך; רק התקן שהוקצה דרך DDA ב-Windows Server הוא החריג.

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

4. מצד הזיכרון — לתרגום הכתובות מתווספת עוד רמה

4.1. שלושה סוגי כתובת

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

כתובת	קיצור	מי מנהל אותה
כתובת וירטואלית של האורח	GVA	טבלת הדפים של מערכת ההפעלה האורחת
כתובת פיזית של האורח	GPA	הכתובת שמערכת ההפעלה האורחת מאמינה שהיא “פיזית”
כתובת פיזית של המערכת	SPA	ההיפרווייזור (המיקום האמיתי ב-RAM)

מערכת ההפעלה האורחת מתרגמת GVA ל-GPA עם טבלת הדפים שלה. עם זאת, ה-GPA שהאורח רואה אינו כתובת פיזית אמיתית; זהו מרחב זיכרון פרטי שמוקדש לכל מחיצה.² מיפוי GPA על המיקום האמיתי ב-RAM ‏(SPA) הוא עבודת ההיפרווייזור.

4.2. SLAT — תרגום דו-רמתי בחומרה

אם עושים את התרגום ברמה השנייה בתוכנה בלבד, ההיפרווייזור צריך לעקוב אחרי כל עדכון טבלת דפים של האורח אחד אחד, וזה לא ריאלי מבחינת ביצועים. לכן המעבד מספק מנגנון שעובר על טבלאות התרגום ברמה השנייה בחומרה. זהו SLAT ‏(Second Level Address Translation); Intel EPT ‏(Extended Page Tables) ו-AMD RVI הם המימושים. Hyper-V הנוכחי דורש מעבד 64 סיביות בעל יכולת SLAT.⁴

flowchart TB
    accTitle: תרגום כתובות דו-רמתי דרך SLAT
    accDescr: כתובת וירטואלית של האורח מתורגמת לכתובת פיזית של האורח על ידי טבלת הדפים של מערכת ההפעלה האורחת, ואז מתורגמת הלאה לכתובת פיזית של המערכת על ידי SLAT, שההיפרווייזור מנהל, ומגיעה ל-RAM האמיתי
    gva["כתובת וירטואלית של האורח （GVA）"] -->|טבלת הדפים של מערכת האורח| gpa["כתובת פיזית של האורח （GPA）"]
    gpa -->|"SLAT （טבלאות תרגום EPT/RVI）"| spa["כתובת פיזית של המערכת （SPA）"]
    spa --> ram["RAM פיזי"]
    gpa -.-> note["שכבה שהאורח רק מאמין שהיא פיזית"]

איור 8: עוד טבלת תרגום, שמנוהלת על ידי ההיפרווייזור, יושבת מתחת לטבלת הדפים של האורח, והמעבד עובר על שתיהן בחומרה.

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

5. מצד I/O של התקנים — VMBus ושני סוגי התקן

5.1. גבולות ההתקנים המדומים

הדרך הקלאסית להראות התקן למחיצת בת היא לחקות במלואה חומרה אמיתית (למשל בקר IDE ישן) בתוכנה. התאימות גבוהה כי מנהלי ההתקנים המובנים של מערכת ההפעלה האורחת עובדים כמות שהם, אבל VM Exit מתרחש בכל פעם שהאורח פוגע בפורט I/O, והביצועים לא מסתלמים.

flowchart TB
    accTitle: למה I/O להתקן מדומה איטי
    accDescr: בכל פעם שהאורח מפעיל פורט I/O, השליטה עוברת לצד ההיפרווייזור דרך VM Exit, ההתקן מדומה בתוכנה, והאורח מוחזר, כך שההלוך-ושוב חוזר ואיטי
    gio["האורח מפעיל פורט I/O"] --> vex["מתרחש VM Exit"]
    vex --> emu2["ההתקן מדומה בתוכנה"]
    emu2 --> back["חזרה לאורח דרך VM Entry"]
    back -->|חוזר בפעולת הפורט הבאה| gio

איור 9: ההלוך-ושוב הזה רץ פעמים רבות מאחורי גישת דיסק אחת, ומחיר התאימות משולם בביצועים.

5.2. VMBus ו-VSP/VSC — נתיב מהיר שתוכנן לווירטואליזציה

לכן ל-Hyper-V יש מנגנון “התקן סינתטי” שתוכנן מתוך הנחת וירטואליזציה. יש שלושה שחקנים.²

VMBus: ערוץ תקשורת לוגי בין מחיצות. הוא מספק תקשורת מהירה בין מחיצות שמשתמשת בזיכרון משותף.³
VSP ‏(Virtualization Service Provider): שירות שיושב בצד מחיצת השורש, מקבל בקשות התקן מהבת, ומגשר אותן למחסנית ההתקן/הצד האחורי בצד השורש. בקשה עשויה להגיע להתקן פיזי, או להיות מטופלת על ידי צד אחורי בצד המארח כמו דיסק וירטואלי או מתג וירטואלי.
VSC ‏(Virtualization Service Consumer): מנהל התקן סינתטי שנכנס למערכת ההפעלה האורחת בצד מחיצת הבת. הוא שולח בקשות ל-VSP דרך VMBus.

אם לוקחים בקשת אחסון של מערכת הפעלה אורחת כדוגמה, הזרימה נראית כך. WriteFile של יישום האורח יורד במחסנית ה-I/O של ליבת האורח, ובתחתית מגיע ל-VSC (במקום לחומרה אמיתית). ה-VSC שם את הבקשה על VMBus ומוסר אותה ל-VSP במחיצת השורש, וה-VSP מזרים את הבקשה למחסנית ה-I/O בצד השורש. בתצורת דיסק וירטואלי (VHDX), הכתיבה הזו מטופלת ככתיבה לקובץ VHDX במארח ובסופו של דבר מגיעה לדיסק הפיזי. הגישה הזו נקראת Enlightened I/O ‏(I/O שמודע לווירטואליזציה), והיא מעלה יעילות בעקיפת שכבת חיקוי ההתקן.²

flowchart TB
    accTitle: נתיב I/O להתקן סינתטי
    accDescr: בקשת I/O מיישום במחיצת הבת מגיעה ל-VSC דרך ליבת האורח, חוצה את VMBus אל ה-VSP במחיצת השורש, ועל מחסנית ה-I/O בצד השורש שה-VSP מגשר אליה היא עשויה להגיע להתקן אמיתי דרך מנהל התקן פיזי, או להיות מטופלת על ידי צד אחורי בצד המארח כמו דיסק וירטואלי או מתג וירטואלי
    app["יישום במחיצת הבת"] --> gk["מחסנית I/O של ליבת האורח"]
    gk --> vsc["VSC （מנהל התקן סינתטי）"]
    vsc -->|VMBus| vsp["VSP （צד מחיצת השורש）"]
    vsp --> rio["מחסנית I/O בצד השורש"]
    rio --> pdrv["מנהל התקן פיזי"]
    rio --> hb["צד אחורי במארח （דיסק וירטואלי, מתג וירטואלי ועוד）"]
    pdrv --> dev["התקן פיזי"]

איור 10: עם התקן סינתטי, I/O של האורח חוצה למחיצת השורש דרך VMBus, ודרך המחסנית בצד השורש מגיע להתקן אמיתי או לצד אחורי במארח.

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

flowchart TB
    accTitle: התקנים מדומים מול התקנים סינתטיים
    accDescr: התקן מדומה מחקה חומרה אמיתית כדי שמנהלי התקנים מובנים של האורח יעבדו אבל הוא איטי; התקן סינתטי הוא מנהל התקן ייעודי שמניח VMBus והוא מהיר
    dev2{"התקן שמוצג למחיצת הבת"} --> emu["התקן מדומה"]
    dev2 --> syn["התקן סינתטי"]
    emu -.-> emuP["מחקה חומרה אמיתית; תאימות קודם"]
    emuP -.-> emuC["צריך התערבות בכל I/O; איטי"]
    syn -.-> synP["תוכנן סביב VMBus; מהיר"]
    synP -.-> synC["דורש מנהל התקן תואם באורח"]

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

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

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

אבטחה מבוססת וירטואליזציה (VBS). היא משתמשת בהיפרווייזור של Windows כדי ליצור סביבה מבודדת ומשכנת שם תכונות אבטחה. ב-Windows 11 היא מופעלת כברירת מחדל כשמתקיימים תנאים כמו התקנה נקייה על חומרה תואמת.¹ הפרטים בחלק 2.
WSL2. הוא מריץ ליבת Linux אמיתית בתוך מכונה וירטואלית שירותית קלת-משקל.⁶
Windows Sandbox. סביבת Windows חד-פעמית המבודדת על ידי ההיפרווייזור.⁷ שניהם מכוסים בחלק 3.

flowchart TB
    accTitle: תכונות יומיומיות שיושבות על אותו היפרווייזור
    accDescr: לא רק מכונות וירטואליות של Hyper-V אלא גם VBS, שמופעל כברירת מחדל במכשירים שעומדים בתנאים כמו התקנה נקייה, יחד עם WSL2 ו-Windows Sandbox, כולם בנויים על אותו היפרווייזור של Windows
    base["ההיפרווייזור של Windows"] --> f1["מכונות וירטואליות של Hyper-V"]
    base --> f2["VBS （ברירת מחדל בהתקנה נקייה）"]
    base --> f3["WSL2"]
    base --> f4["Windows Sandbox"]
    f2 -.-> daily["למה זה רץ גם בלי VM"]

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

עוד דבר שאנשים דורכים עליו לעיתים קרובות בפועל הוא דו-קיום עם תוכנת וירטואליזציה צד שלישי. מכיוון שההיפרווייזור משתמש בהרחבות הווירטואליזציה של המעבד באופן בלעדי, בסביבה שבה ההיפרווייזור של Windows רץ, VirtualBox וכדומה לא יכולים לרוץ בדרך המסורתית (הדרך שמשתמשת בהרחבות הווירטואליזציה של המעבד בעצמה). לשם כך מסופק API ציבורי בשם Windows Hypervisor Platform, ומחסנית וירטואליזציה צד שלישי יכולה לרוץ בישיבה מעל ההיפרווייזור של Windows.⁸ VirtualBox/VMware הנוכחיים יכולים לדור בכפיפה אחת עם WSL2 בזכות המנגנון הזה, אבל הבדלי ביצועים ותכונות שבאים עם החלפת מצבים נצפים לפעמים כ”אחרי שהפעלתי Hyper-V (או VBS), תוכנת הווירטואליזציה התחילה להתנהג אחרת”.

flowchart TB
    accTitle: מי הבעלים של הרחבות הווירטואליזציה של המעבד, והנתיב לתוכנת וירטואליזציה צד שלישי
    accDescr: בזמן שההיפרווייזור של Windows רץ הוא הבעלים הבלעדי של הרחבות הווירטואליזציה של המעבד; תוכנת וירטואליזציה צד שלישי שתומכת ב-WHP רצה מעליו דרך Windows Hypervisor Platform, ואילו מימושים שלא תומכים ב-WHP לא יכולים לרוץ או מוגבלים בתכונות
    vt["הרחבות וירטואליזציה של המעבד （VT-x/AMD-V）"] --> hvon{"האם ההיפרווייזור של Windows רץ?"}
    hvon -->|לא| direct["תוכנת צד שלישי יכולה להשתמש ישירות"]
    hvon -->|כן| own["ההיפרווייזור משתמש באופן בלעדי"]
    own --> whp["Windows Hypervisor Platform"]
    whp --> third["תוכנת צד שלישי תומכת-WHP רצה מעליו"]
    third -.-> nowhp["מימושים לא-תומכים לא רצים, או מוגבלים"]

איור 13: יש בעלים אחד להרחבות הווירטואליזציה, ותוכנת הצד השלישי היחידה שיכולה לדור בכפיפה אחת בזמן שההיפרווייזור רץ היא תוכנה שתומכת ב-API הציבורי (WHP).

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

אפשר לאשר במחשב שלכם אם היפרווייזור רץ.

ראשית, בדיקה שאפשר להריץ בלי הרשאות מנהל.

# האם אנחנו רצים מעל היפרווייזור
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent

# מצב VBS (אותו מקור כמו "Virtualization-based security" ב-msinfo32)
Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus

VirtualizationBasedSecurityStatus מחזיר את מצב הריצה של VBS כמספר (2 הוא “Running”).⁹

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

אחר כך, הקלאסיקה משורת הפקודה.

systeminfo

הסתכלו על “Hyper-V Requirements” בסוף הפלט. במחשב שבו ההיפרווייזור עדיין לא רץ, הדרישות הבודדות — תמיכה ב-SLAT, האם הרחבות וירטואליזציה מופעלות וכדומה — רשומות. במחשב שבו ההיפרווייזור כבר רץ, במקום הדרישות מתקבלת שורה אחת: “A hypervisor has been detected. Features required for Hyper-V will not be displayed.”⁴ לכן השורה האחת הזו היא הצהרה שWindows שלכם רץ מעל איזה היפרווייזור. כמו עם HypervisorPresent, צריך לקרוא זאת כ”בתוך מחיצת השורש” במחשב פיזי, או “כמחיצת בת” בתוך מכונה וירטואלית.

גם אם כל דרישת systeminfo היא “Yes”, זה אומר רק שצד החומרה מוכן. תכונת Hyper-V עצמה זמינה במהדורות Pro, Enterprise ו-Education, ואינה במהדורת Home.¹⁰

בממשק הגרפי, בדקו את השורה “Virtualization-based security” תחת “System Summary” ב-msinfo32. שימו לב ש”Virtualization: Enabled” בחלונית המעבד של מנהל המשימות מראה רק אם הרחבות וירטואליזציה מופעלות בקושחה, וזו מידע נפרד מהשאלה אם היפרווייזור רץ.

flowchart TB
    accTitle: איך לבדוק אם ההיפרווייזור רץ
    accDescr: אם systeminfo אומר שהיפרווייזור זוהה אתם רצים על היפרווייזור （בתוך מחיצת השורש במחשב פיזי）; אם מופיעה רשימת Hyper-V Requirements הוא עדיין לא רץ ולכן בודקים כל דרישה כמו SLAT, VM Monitor Mode Extensions ו-DEP, אבל כל Yes אומר רק שצד החומרה מוכן ולתכונת Hyper-V יש גם דרישת מהדורה
    start2["הריצו systeminfo"] --> q1{"שדה הדרישות?"}
    q1 -->|זוהה| running["ההיפרווייזור רץ"]
    running -.-> runN["בתוך השורש"]
    runN -.-> runN2["במחשב פיזי"]
    q1 -->|רשום| notyet["עדיין לא רץ"]
    notyet --> q2{"כל הדרישות Yes?"}
    q2 -->|הכול Yes| can["צד החומרה מוכן"]
    can -.-> ed["צריך Pro / Ent / Edu"]
    q2 -->|חלק No| uefi["בדקו פריטי UEFI/BIOS"]

איור 14: שדה “Hyper-V Requirements” ב-systeminfo משמש כפול גם כבדיקת מצב ריצה וגם כבדיקת דרישות מוקדמות.

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

8.1. “לא הפעלנו Hyper-V, אז לווירטואליזציה אין קשר למחשבים שלנו”

גם אם לא הפעלתם את תכונת Hyper-V (כלי הניהול וסביבת הרצת המכונות הווירטואליות), ההיפרווייזור של Windows רץ אם VBS מופעל. כשחוקרים בעיית תאימות מנהל התקן, בדיקת ביצועים או תקלה בתוכנת וירטואליזציה צד שלישי, בדקו את HypervisorPresent ואת מצב הריצה של VBS — לא אם התכונה מופעלת.

8.2. “מנהל המשימות אומר ‘Virtualization: Enabled’, אז Hyper-V רץ”

התצוגה הזו היא על הגדרת הקושחה (האם VT-x/AMD-V זמין). שפטו את מצב הריצה של ההיפרווייזור מ”A hypervisor has been detected” ב-systeminfo. ולהפך, אם מנהל המשימות אומר “Disabled”, אי אפשר להפעיל גם Hyper-V או WSL2, אז בדקו קודם את הגדרות ה-UEFI/BIOS.

flowchart TB
    accTitle: שלוש בדיקות שקל לבלבל ביניהן
    accDescr: שדה הווירטואליזציה במנהל המשימות מראה את הגדרת הקושחה, רשימת תכונות Windows מראה את מצב ההתקנה, ו-systeminfo או HypervisorPresent מראים את מצב הריצה; כל אחד עונה על שאלה אחרת
    q3{"איזו שאלה?"}
    q3 --> fw{"קושחה או Windows?"}
    q3 --> c3["האם ההיפרווייזור רץ?"]
    fw --> a3["הרחבות קושחה?"]
    fw --> b3["תכונת Hyper-V דולקת?"]
    a3 -.-> a3t["חלונית המעבד במנהל המשימות"]
    b3 -.-> b3t["ממשק תכונות Windows"]
    c3 -.-> c3t["systeminfo"]
    c3 -.-> c3tp["HypervisorPresent"]

איור 15: אלה שלוש שאלות עצמאיות, והסקת השתיים האחרות מכל תצוגה אחת היא קריאה שגויה.

8.3. “אם המכונה הווירטואלית איטית, זו בעיית מערכת ההפעלה האורחת”

I/O של התקן סינתטי חוצה את VMBus אל ה-VSP במחיצת השורש ועובר דרך מחסנית ההתקן/הצד האחורי בצד השורש (מנהלים פיזיים, ועוד עיבוד מתג וירטואלי ודיסק וירטואלי). אם רק צופים במונים בתוך האורח, לא תמצאו צוואר בקבוק שיושב באחסון בצד המארח או בכרטיס רשת. העיקרון לבעיות ביצועים של מכונות וירטואליות הוא לצפות משני הצדדים: האורח והמארח (מחיצת השורש).

9. סיכום

כשמפעילים Hyper-V, ההיפרווייזור רץ ישירות על החומרה ו-Windows המארח רץ כמחיצת השורש.²
ליבת מערכת ההפעלה האורחת ממשיכה לרוץ בטבעת 0, ורק פעולות שהוגדרו כיירוטים, ועוד חריגות, נמסרות להיפרווייזור דרך VM Exit. גישות זיכרון רגילות עוברות דרך תרגום SLAT.
רק מחיצת השורש מחזיקה מנהלי התקנים פיזיים ואת מחסנית ניהול הווירטואליזציה, והיא יוצרת מחיצות בת דרך hypercall.²
הזיכרון הופך לתרגום דו-רמתי של GVA→GPA→SPA, והרמה השנייה מטופלת בחומרה על ידי SLAT ‏(EPT/RVI). Hyper-V הנוכחי דורש SLAT.⁴
I/O של התקנים נשלט על ידי נתיב ההתקן הסינתטי VSC→VMBus→VSP, והביצועים תלויים גם במחסנית ה-I/O בצד המארח.²
ב-Windows 11, מכיוון ש-VBS מופעל כברירת מחדל במכשירים שעומדים בתנאים כמו התקנה נקייה, זה לא חריג שההיפרווייזור רץ גם במחשב שמעולם לא משתמש במכונה וירטואלית.¹ אפשר לאשר את מצב הריצה עם HypervisorPresent ועם systeminfo.

התמונה הגדולה של חלק 1 מתכנסת לתרשים האחד הזה.

flowchart TB
    accTitle: התמונה הגדולה של חלק 1
    accDescr: ההיפרווייזור יושב מתחת למחיצת השורש ולמחיצות הבת; מעבדים מוקצים בתיזמון מעבדים וירטואליים （VM Exit רק ביירוטים ובחריגות שהוגדרו）, זיכרון מתווך על ידי תרגום SLAT דו-רמתי, I/O של התקן סינתטי מועבר דרך VMBus ומטופל על ידי ה-VSP של מחיצת השורש, ולהתקנים מדומים ול-Discrete Device Assignment יש נתיבים אחרים
    up["מחיצת שורש + מחיצות בת"] --> hvS["היפרווייזור"]
    hvS --> cpuS["מעבד: תיזמון VP"]
    hvS --> memS["זיכרון: SLAT"]
    cpuS -.-> cpuN["VM Exit ביירוט"]
    memS -.-> memN["תרגום דו-רמתי"]
    memS ~~~ devS
    devS["התקנים: I/O של VMBus"] --> vspS["VSP בצד השורש מטפל"]
    devS -.-> devN["מדומה / DDA: אחר"]

איור 16: תיזמון מעבד ותרגום זיכרון מטופלים ישירות על ידי ההיפרווייזור (VM Exit רק בהתערבות), ו-I/O של התקן סינתטי מתווך על ידי מחיצת השורש (ה-VSP) מעבר ל-VMBus.

ההמשך בחלק 2, “זיכרון שאפילו הליבה לא יכולה לראות — VBS,‏ HVCI ו-Credential Guard”.

אנחנו מרים את החוט המקשר של המאמר הזה — שההיפרווייזור מחזיק את טבלאות תרגום SLAT — ועוקבים אחרי איך Windows יוצר “זיכרון שאף מנהל ואף הליבה לא יכולים לקרוא”.

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

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

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

קישורים

Microsoft Learn, Silicon assisted security. על כך ש-VBS משתמש בווירטואליזציית חומרה כדי לבודד את Secure Kernel ממערכת ההפעלה הרגילה, ועל כך ש-VBS ו-HVCI מופעלים כברירת מחדל במכשירים שעומדים בדרישות המוקדמות בהתקנה חדשה של Windows 11. ↩ ↩² ↩³
Microsoft Learn, Hyper-V Architecture. על כך שההיפרווייזור מספק מחיצות כיחידת הבידוד; על כך שמחיצת השורש יוצרת מחיצות בת דרך ה-API של hypercall; על כך שמחיצות רצות במרחב זיכרון וירטואלי פרטי בלי גישה ישירה למעבדים פיזיים; על התפקידים של VMBus, VSP, VSC ו-Enlightened I/O; ועל כך שנדרשות הרחבות וירטואליזציה של החומרה (Intel VT/AMD-V). ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²
Microsoft Learn, Hyper-V architecture (Performance Tuning). על כך ש-Hyper-V הוא היפרווייזור Type 1, על כך שמחיצת השורש היא הבעלים של התקני I/O פיזיים, ועל כך ש-VMBus מספק תקשורת בעלת ביצועים גבוהים בין מחיצות שמשתמשת בזיכרון משותף. ↩ ↩²
Microsoft Learn, System requirements for Hyper-V on Windows and Windows Server. על כך שנדרשים מעבד 64 סיביות בעל יכולת SLAT ו-VM Monitor Mode Extensions; על היכולת לאשר שהדרישות מתקיימות בשדה “Hyper-V Requirements” של systeminfo; על כך שמוצג “A hypervisor has been detected” בזמן שהיפרווייזור רץ; ועל כך ש-Discrete Device Assignment יכול להקצות התקן מסוים ישירות למחיצת בת. ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Appendix B: Hyper-V Architecture and Feature Overview. על כך ש-VMMS ‏(Virtual Machine Management Service) מנהל את מצב המכונות הווירטואליות במחיצות בת, ועל כך שתהליך עבודה (VMWP) מתחיל במצב משתמש במחיצת השורש לכל מכונה וירטואלית. ↩
Microsoft Learn, Comparing WSL Versions. על כך ש-WSL2 מריץ ליבת Linux אמיתית בתוך מכונה וירטואלית שירותית קלת-משקל, ועל אזהרות לגבי שימוש יחד עם VMware ו-VirtualBox הנוכחיים. ↩
Microsoft Learn, Windows Sandbox architecture. על כך ש-Windows Sandbox הוא סביבת Windows קלת-משקל שמשלבת טכנולוגיית קונטיינרים עם בידוד על ידי ההיפרווייזור. ↩
Microsoft Learn, Windows Hypervisor Platform. על כך שמסופק API במצב משתמש כדי שמחסנית וירטואליזציה צד שלישי תוכל ליצור ולנהל מחיצות מעל ההיפרווייזור של Windows. ↩
Microsoft Learn, Enable Hotpatch for Azure Arc-enabled servers. על היכולת לאשר את מצב הריצה של VBS (מצב מאובטח וירטואלי) דרך VirtualizationBasedSecurityStatus במחלקה Win32_DeviceGuard. ↩
Microsoft Learn, Install Hyper-V. על כך שאפשר להפעיל Hyper-V ב-Windows 10/11 Pro או Enterprise וכדומה, ושאי אפשר להתקין אותו במהדורת Home. ↩

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

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

למה WSL2 ו-Windows Sandbox עולים בשניות ומרגישים כל כך קלים? המאמר מסביר את המנגנונים, מתמונות בסיס דינמיות ומ-direct map דרך הקצאת זיכרו...

לקריאת המאמר

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

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

נושאים טכניים ב-Windows

שער לנושאי פיתוח Windows, חקירת תקלות וניצול נכסים קיימים.

לצפייה בנושא

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

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

פיתוח יישומי Windows

יישומים עסקיים, חיבור התקנים וכלי תקשורת, מהגדרת הדרישות ועד הפיתוח.

לצפייה בשירות צרו קשר

שאלות נפוצות

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

כשמפעילים Hyper-V, היכן Windows המארח באמת רץ?: ההיפרווייזור לוקח שליטה ישירה על אופן הקצאת מעבדים וזיכרון פיזיים, ו-Windows המארח רץ בתוך מחיצה מיוחדת שנקראת מחיצת השורש. השליטה בהתקנים פיזיים מטופלת בדרך כלל על ידי מנהלי התקנים בצד מחיצת השורש. מחיצת השורש מחזיקה את מנהלי ההתקנים ואת מחסנית ניהול הווירטואליזציה, אבל הבעלות על המעבדים הפיזיים שייכת להיפרווייזור.
האם "וירטואליזציה: מופעלת" במנהל המשימות אומר ש-Hyper-V רץ?: לא. התצוגה הזו מראה אם הרחבות הווירטואליזציה של המעבד (Intel VT-x/AMD-V) מופעלות בקושחה. כדי לראות אם היפרווייזור באמת רץ, חפשו "A hypervisor has been detected" ב-systeminfo, או בדקו את Win32_ComputerSystem.HypervisorPresent.
למה ההיפרווייזור רץ אף שמעולם לא יצרתי מכונה וירטואלית?: ב-Windows 11, אבטחה מבוססת וירטואליזציה (VBS) מופעלת כברירת מחדל במכשירים שעומדים בתנאים — למשל התקנה נקייה על חומרה תואמת — ו-VBS בנוי על ההיפרווייזור של Windows. אותו דבר אם משתמשים ב-WSL2 או ב-Windows Sandbox. זה לא חריג שההיפרווייזור רץ בלי קשר לכך שמישהו משתמש במכונות וירטואליות.
מהו SLAT, ולמה Hyper-V דורש אותו?: SLAT ‏(Second Level Address Translation) הוא המנגנון שבו המעבד מתרגם כתובות פיזיות של האורח לכתובות פיזיות אמיתיות; Intel EPT ו-AMD RVI הם המימושים. בלי זה ההיפרווייזור היה צריך לתחזק את טבלאות התרגום בתוכנה, וזה לא ריאלי מבחינת ביצועים, ולכן Hyper-V הנוכחי מתייחס אליו כדרישה קשיחה.
אם אפעיל Hyper-V, VirtualBox ו-VMware יפסיקו לעבוד?: מכיוון שההיפרווייזור משתמש בהרחבות הווירטואליזציה של המעבד באופן בלעדי, היפרווייזור צד שלישי לא יכול לרוץ בדרך המסורתית. עם זאת, ל-VirtualBox ול-VMware הנוכחיים יש מצב שרץ מעל ההיפרווייזור של Windows (דרך Windows Hypervisor Platform), כך שגרסאות עדכניות של כל אחד יכולות לדור בכפיפה אחת.

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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

לצפייה בפרופיל צרו קשר

קישורים ציבוריים

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

חזרה לבלוג