מעבר GPU (vDGA) ב-VMware: מדריך מלא

חיבור GPU פיזי ישירות למכונה וירטואלית ב-VMware זהו אחד מאותם שינויים שעושים את כל ההבדל כשעובדים עם עומסי גרפיקה כבדים. IA או רינדור תלת-ממדי. מעבר מכרטיס גרפי מדומה לגישה ישירה דרך מעבר (vDGA / VMDirectPath I/O) יכול לקרב את ביצועי המכונה הווירטואלית לאלה של מכונה פיזית, אך בתמורה הוא מוסיף לא מעט דרישות ומגבלות שצריכות להיות ברורות מאוד לפני שמתחילים.

יתר על כן, במערכת האקולוגית הנוכחית, קיימות מספר דרכים לשימוש ב-GPU בסביבות וירטואליות: מעבר ייעודי, vGPU משותף וטכנולוגיות כמו BitFusion או חלוקת GPUהבנת מה כל אחד מהם עושה, באילו מקרים הוא מתאים וכיצד הוא מוגדר ב-vSphere/ESXi (וכיצד הוא קשור לטכנולוגיות דומות כמו Hyper-V DDA) היא המפתח כדי לא להיכנס למבוי סתום עם החומרה או גרסת ההיפר-ויזור שנבחרה.

מהי העברת GPU (vDGA / VMDirectPath I/O) ב-VMware

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

קיצור דרך זה מאפשר למכונה הווירטואלית לנצל את היתרון כל העוצמה של שבב הגרפיקה, זיכרון הווידאו והתכונות המתקדמות שלו כגון CUDA, OpenCL, Direct3D ו-OpenGL באופן טבעי, עם מעט מאוד תקורה נוספת מצד ההיפר-ויזור. בבדיקות מעבדה של VMware, מדווח בדרך כלל על אובדן ביצועים של כ-4-5% בהשוואה להפעלת אותו GPU במעבדה רגילה.

בפועל, שימוש במעבר GPU פירושו ש כרטיס זה מוקדש כולו למכונה וירטואלית אחת.אין הקצאת משאבים מדויקת בין מספר מכונות וירטואליות, וגם אין שכבת תוכנה של צד שלישי שנטענת על ESXi כדי לשתף את כרטיס המסך, בניגוד למה שקורה עם פתרונות vGPU כגון NVIDIA רֶשֶׁת.

חשוב להבדיל גישה זו מדרכים אחרות לשימוש במעבדים גרפיים (GPUs) בווירטואליזציה, כגון NVIDIA vGPU (vGPU משותף), RemoteFX/חלוקה למחיצות בפתרונות מסוג Hyper-V או BitFusion, אשר שואפים להפיץ GPU או מאגר של GPU בין מספר מכונות באמצעות טכניקות וירטואליזציה או ניתוב מחדש מרחוק שונות.

כשאנחנו מדברים על vDGA בעולם VMware, אנחנו בעצם מתארים את זה הקצאה ישירה של התקן PCIe של ה-GPU למכונה הווירטואלית שימוש ב-VMDirectPath I/O, עם כל הטוב (ביצועים) והרע (מגבלות ניידות וזמינות גבוהה) הכרוכים בכך.

יתרונות השימוש ב-GPU passthrough ב-vSphere

הסיבה העיקרית למעבר ל-vDGA היא ש ביצועי הגרפיקה והמחשוב קרובים מאוד לאלה של מחשב פיזי.על ידי השמטת חלק גדול משכבת ​​הווירטואליזציה עבור אותו התקן PCIe, צווארי הבקבוק האופייניים של ה-GPU המדומה נעלמים והמכונה הווירטואלית יכולה לעבוד עם משחקים, יישומי תלת-ממד או מנועי בינה מלאכותית בצורה חלקה הרבה יותר.

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

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

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

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

מעבר GPU לעומת vGPU וחלופות אחרות

בתוך המערכת האקולוגית של VMware, ישנן מספר דרכים להשתמש בכרטיס מסך, ולא כולן כרוכות בהקדשתו כולה למכונה וירטואלית אחת. הידועות ביותר הן: פתרונות קלט/פלט של vDGA / VMDirectPath, vGPU (NVIDIA GRID או אחרים) וגישה מרחוק/מחשוב כגון BitFusion.

במצב מעבר ישיר (vDGA), ה-GPU מוקצה באופן בלעדי למכונה וירטואליתליבות מחשוב וזיכרון VRAM אינם משותפים בין מספר מכונות וירטואליות, ותפקידו של ההיפר-ויזור כמעט ואינו קיים מעבר לניתוב התקן ה-PCIe לשרת האורח. זוהי האפשרות הקלה ביותר להבנה וזו הדומה ביותר לשרת פיזי עם כרטיס מסך ייעודי.

בגישת vGPU, תוכנה ייעודית (לדוגמה NVIDIA GRID vGPU על גבי VMware vSphereהוא מטפל בווירטואליזציה של ה-GPU ברמת הבקר וחושף מופעים וירטואליים של ה-GPU שניתן להקצות למספר מכונות וירטואליות בו זמנית. כל מחשב אורח רואה "פרוסה" של ה-GPU עם משאבים מובטחים או משותפים.

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

ישנם גם פתרונות כגון BitFusion Flexdirect וטכנולוגיות דומותהמאפשרים לצרוך מעבדים גרפיים (GPUs) דרך הרשת ממכונות וירטואליות שונות, אידיאלי לעומסי עבודה של בינה מלאכותית ו-HPC שבהם ה-GPU משמש יותר כמשאב מחשוב מרוחק מאשר ככרטיס מסך עבור הממשק הגרפי של המשתמש.

בחרו בין vDGA, vGPU או דגם GPU מרוחק זה תלוי אם אתם צריכים לנצל באופן מלא כרטיס מסך (GPU) עבור מכונה אחת (passthrough), האם אתם רוצים להפיץ כרטיס יקר בין משתמשים רבים עם עומסי עבודה בינוניים (vGPU), או האם המפתח הוא לתאם מאגר של כרטיסי מסך (GPU) עבור מחשוב מבוזר (BitFusion ודומיו).

דרישות חומרה לשימוש ב-vDGA ב-ESXi

לפני תכנון פריסת GPU passthrough ב-VMware, עליך לוודא ש- פלטפורמת החומרה עומדת בשורה של תנאים שהם מעבר ל"חיבור כרטיס מסך לשרת".

ראשית, המעבד ומערכת השבבים של לוח האם המארח ESXi חייבים לתמוך וירטואליזציה עם IOMMU. בתוך אינטל זה מושג באמצעות Intel VT-x בתוספת VT-dy, ודרך AMD באמצעות AMD-V עם IOMMU. ל-BIOS/UEFI של השרת יש בדרך כלל אפשרויות ספציפיות לכך. הפעלת הרחבות וירטואליזציה של קלט/פלט.

שנית, עליך לבדוק את לוחית התמיכה מיפוי זיכרון MMIO מעל 4 ג'יגה-בייט (לפעמים מתויג כ"פענוח מעל 4G", "קלט/פלט ממופה זיכרון מעל 4G" או דומה). זה חשוב במיוחד עם כרטיסי מסך מתקדמים כמו טסלה, P100, V100 ומקבילים, אשר מצהירים על אזורי זיכרון גדולים מאוד ב-BAR (אוגרי כתובות בסיסיים) שלהם.

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

כמובן, ה-GPU עצמו חייב להיות תואם לפלטפורמת השרת ונתמך על ידי יצרן המארח (Dell, HPE, Lenovoוכו') כאשר משתמשים בו במצב מעבר. בפועל, רוב כרטיסי ה-PCIe המודרניים עובדים, אך מומלץ לבדוק רשימות תאימות, במיוחד עבור כרטיסי GRID או דגמים חדשים מאוד.

דרישות תוכנה ותאימות גרסאות

ברמת התוכנה, חשוב להבהיר ש... VMware תומכת ב-vDGA ב-vSphere 6.x וגירסאות מאוחרות יותרעם זאת, חלק מהמשתמשים דיווחו על בעיות ספציפיות עם שילובי חומרה מסוימים (לדוגמה, מעבדי NVIDIA GRID בשרתי Dell R720 עם ESXi 6.x).

במקרים אלה, נפוץ לראות שגיאות כגון "המכשיר כבר בשימוש" או תסמינים המצביעים על כך Passthrough הפסיק לעבוד לאחר שדרוג מ-ESXi 5.5 ל-6.xכשלמעשה מדובר בבאגים ספציפיים, שינויים בניהול התקני PCI או מנהלי התקנים, ולא בהפסקה רשמית של תמיכה.

מערכת ההפעלה האורחת שתשתמש ב-GPU במעבר חייבת להיות מנהלי התקנים רשמיים של היצרן המותקנים בתוך המכונה הווירטואלית (NVIDIA, AMD, Intel), מכיוון ש-ESXi אינו טוען מנהל התקן ספציפי עבור כרטיס זה בעת שימוש ב-VMDirectPath I/O; ההיפר-ויזור פשוט חושף את ההתקן לאורח.

בנוסף, יש להגדיר את המכונה הווירטואלית לאתחול ב- מצב EFI או UEFI בעת שימוש במעבדים גרפיים (GPUs) המצהירים על אזורי זיכרון גדולים של MMIO. פרט זה קריטי: קושחת VM שגויה עלולה להוביל לכשלים. אתחול או שה-GPU אינו מאותחל כראוי ממערכת ההפעלה האורחת.

בצד הלקוח, אם הגישה למכונה הווירטואלית מתבצעת דרך שולחן עבודה מרוחק (RDP או פרוטוקולים אחרים)יהיה צורך להפעיל את המדיניות המתאימה כדי שמערכת האורחת תשתמש במתאם הגרפי החומרתי בהפעלות מרוחקות ולא תיתקע עם מנהל התקן כללי ללא האצה.

הגדרת מארח ESXi לשימוש ב-GPU במצב מעבר

הצעד המעשי הראשון הוא להכין את שרת vSphere/ESXi לחשיפת ה-GPU כהתקן קלט/פלט של DirectPathזה כרוך בגישה ל-BIOS, בדיקת מלאי ה-PCI במארח וסימון הכרטיס כך שניתן יהיה להקצות אותו למכונות וירטואליות.

אם ה-GPU דורש אזורי זיכרון MMIO גדולים (16 ג'יגה-בייט או יותר), עליך לחפש ב-BIOS/UEFI של השרת אפשרויות כמו "פענוח מעל 4G" או "טיפול במשאבים של PCI 64 סיביות מעל 4G" ולהפעיל אותם. השם הספציפי משתנה בהתאם ליצרן, אך בדרך כלל ניתן למצוא אותו בהגדרות ה-PCI או במקטע המשאבים המתקדמים.

לאחר הפעלת ESXi עם הגדרות אלו, בלקוח vSphere ניתן לגשת למארח המתאים ולגשת "הגדרה ← חומרה ← התקני PCI ← עריכה" כדי להציג את רשימת התקני ה-PCI שזוהו, תראו כרטיסי NVIDIA, AMD או כרטיסים דומים יחד עם שאר חומרת ה-PCI של השרת.

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

לאחר ההפעלה מחדש, עם החזרה למקטע "הגדרה ← חומרה ← התקני PCI" יוצג חלון שכותרתו "התקני DirectPath I/O PCI זמינים למכונות וירטואליות", ובו יפורטו כל ההתקנים שהפכו לזמינים לשימוש במכונות וירטואליות, כולל כרטיסי מסך (GPU) ובמקרים רבים, מתאמי רשת מתקדמים כמו Mellanox.

הכנה וקביעת תצורה של המכונה הווירטואלית

לאחר שהמארח מוכן, השלב הבא הוא ליצור או להתאים את המכונה הווירטואלית שתשתמש ב-GPU. הדבר הראשון הוא לוודא שהמכונה הווירטואלית הוא נוצר עם קושחת EFI/UEFI מתאימה., במיוחד בתרחישים עם כרטיסי מסך מתקדמים ו-MMIO גבוה.

בלקוח vSphere, פשוט בחר את המכונה הווירטואלית, עבור אל "עריכת הגדרות ← אפשרויות וירטואליות ← אפשרויות אתחול" וודאו ש-"EFI" או "UEFI" נבחרו בשדה "Firmware". אם לא, יהיה צורך לשנות זאת (ובמקרים מסוימים, יהיה צורך ליצור מחדש את המכונה הווירטואלית או מערכת ההפעלה אם הן אינן תומכות בהחלפה חמה זו).

בעת שימוש ב-passthrough עם כרטיסים הממפים יותר מ-16 ג'יגה-בייט של שטח MMIO, מומלץ להתאים כמה פרמטרים מתקדמים בתצורת ה-VM, הנגישים מ- "עריכת הגדרות ← אפשרויות VM ← מתקדם ← פרמטרי תצורה ← עריכת תצורה"שם ניתן להוסיף מפתחות הקשורים ל-pciPassthru כדי לשלוט באופן שבו מרחב הכתובות שמור.

באופן ספציפי, השימוש ב-MMIO של 64 סיביות מופעל בדרך כלל ומוגדר גודל עבור אזור זה, המחושב מ כמה מעבדים גרפיים מתקדמים יוקצו למכונה הווירטואלית?כלל האצבע הוא בדרך כלל להכפיל 16 במספר ה-GPU ולעגל את התוצאה כלפי מעלה לחזקת שתיים (לדוגמה, שני GPU כאלה יסתיימו ב-64 ג'יגה-בייט של MMIO של 64 סיביות).

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

הקצאת ה-GPU למכונה הווירטואלית באמצעות VMDirectPath I/O

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

מלקוח vSphere, בחר את המכונה הווירטואלית והזן "עריכת הגדרות" כדי לסקור את החומרה הווירטואליתברשימת ההתקנים, ניתן ללחוץ על "הוסף התקן חדש" ולבחור "התקן PCI" אם כרטיס המסך אינו מופיע כבר ברשימה. לאחר מכן, בחר את התקן ה-PCI המתאים לכרטיס המסך (לדוגמה, כרטיס ה-NVIDIA או ה-AMD שזוהה במארח).

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

חיוני שהמכונה הווירטואלית תכלול שמר את כל הזיכרון שהוקצה לוב-vSphere, הגדרה זו מוגדרת תחת "עריכת הגדרות ← חומרה וירטואלית ← זיכרון", תוך הגדרת הערך "הזמנה" לכמות ה-RAM שתצורתה נקבעה עבור המכונה הווירטואלית. ללא הזמנה מלאה זו, העברת PCI עלולה להיכשל או להיתקל בבעיות לסירוגין.

לאחר הפעלת המכונה הווירטואלית, במערכת לינוקס ניתן לאמת את נוכחות ה-GPU באמצעות פקוד סוג lspci | grep nvidia, בעוד שב-Windows הוא יופיע תחת "מתאמי תצוגה" ב- מנהל ההתקניםזה נורמלי לראות גם את כרטיס המסך המדומה של VMware וגם את ה-GPU הפיזי הייעודי.

השלב האחרון הוא להתקין את הדברים הבאים על מכשיר האורח: נהגים פקידי יצרן GPU, שהורדו מאתרי האינטרנט של NVIDIA, AMD או Intel, תוך הימנעות מהסתמכות על דרייברים גנריים או אלו המסופקים Windows Updateאשר עשוי שלא להיות מותאם לתרחישי מעבר.

מגבלות ותכונות של vSphere שאינן פועלות עם vDGA

הצד B של העברת GPU ב-VMware הוא ש מספר תכונות מתקדמות של הפלטפורמה אבדו על ידי הקדשת מכשיר פיזי ישירות למכונה וירטואלית. זהו המחיר שיש לשלם עבור ביצועים כמעט מקוריים אלה.

הקורבן הגדול הראשון הוא vMotion ו-DRSלא ניתן להעביר מכונה וירטואלית עם GPU במצב מעבר (passthrough) לשרת מארח אחר באופן חם מכיוון שהכרטיס נעול פיזית לשרת המקורי. לא ניתן גם להשתמש במדיניות איזון עומסים אוטומטיות הכרוכות בהעברת המכונה הווירטואלית בין מארחים באשכול.

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

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

בצד התמיכה, ייתכנו מקרים ספציפיים שבהם שילובים מסוימים של חומרה ומנהלי התקנים עלולים לגרום לבעיותכפי שציינו משתמשים מסוימים בעת שדרוג ל-ESXi 6.x עם כרטיסי NVIDIA GRID בשרתים ספציפיים (למשל, Dell R720), מומלץ לעיין בתיעוד של VMware ושל יצרן ה-GPU בתרחישים אלה, ולפתוח בקשות תמיכה במידת הצורך.

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

מעבר GPU בהיפר-ויזורים אחרים: במקביל ל-Hyper-V

למרות שההתמקדות כאן היא על VMware, כדאי להבין כיצד היפר-ויזורים אחרים (לדוגמה וירטואליזציה עם KVM ו-virt-manager) לטפל באותו צורך להקצות GPU פיזי למכונה וירטואליתמכיוון שהטרמינולוגיה והכלים משתנים, אך הרעיון הבסיסי דומה.

ב-Hyper-V, המקבילה ל-VMware VMDirectPath I/O היא הקצאת התקנים ישירה באמצעות DDA (הקצאת התקנים בדידים)טכניקה זו מאפשרת מיפוי התקן PCIe ספציפי, כגון GPU או NVMe, ישירות בתוך מכונה וירטואלית של Windows, עם רמת שליטה וביצועים הדומות ל-passthrough ב-ESXi.

גרסאות קודמות של Windows Server השתמשו בטכנולוגיה זו RemoteFX להציע וירטואליזציה של GPU ולשתף כרטיס מסך בין מספר מכונות וירטואליות. עם הזמןעקב בעיות אבטחה ומגבלות ביצועים (כגון מגבלת VRAM של 1GB לכל מכונה וירטואלית ו-30 פריימים לשנייה), מיקרוסופט הפסיקה את RemoteFX והותירה את DDA כנתיב העיקרי לתרחישי GPU ייעודיים.

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

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

כל המערכת האקולוגית הזו של מעבר נתונים, vGPU ו-DDA מדגימה שכאשר מוגדרים כראוי ועם החומרה הנכונה, בהחלט אפשרי להשתמש במעבדי גרפיקה חזקים בפנים מכונות וירטואליות לייצור עבור עומסי עבודה הנעים בין מחשבים שולחניים גרפיים תובעניים ועד לבינה מלאכותית ו-HPC, תמיד בהנחה שתצטרכו לוותר על נוחות מסוימת של וירטואליזציה מסורתית ולשים לב היטב לדרייברים, גרסאות היפר-ויזור ותמיכת יצרן ה-GPU.