קטגוריה: VMWARE

כמה עדכונים על וירטואליזציות שונות

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

העדכון הראשון נוגע ל-vSphere גירסה 6 שאמורה לצאת בשנה הבאה. ישנם לא מעט חידושים (כל אחד יכול להצטרף לבטא) ואחד מהחידושים שכבר נכנס בגירסה 5.5 הוא NDDK חדש (ר"ת של Native Driver Development Kit). מי שמעוניין לקרוא קצת יותר מה שכתבו על כך, אפשר לקרוא כאן. אני אתייחס לאספקט טיפה שונה.

טכנית, עד גירסה 5.5 חברת VMWare די "תפסה טרמפ" על הדרייברים שיש ללינוקס. לא, ESXI אינו בנוי עם קרנל של לינוקס, אך ישנה מעין "שכבה" (vmkernel) שמתרגמת בין לקרנל הקנייני של ESXI לדרייברים שכתובים עבור לינוקס. היתרון: כבר ביום הראשון, היה אפשר להתקין את ESXI על כל דבר, כל עוד שזה היה מעבד X86 עם 64 סיביות ותמיכת VT. החסרון: שכבת ה"תרגום" הורידה חלק מהביצועים.

ב-6.0 שיגיע, החגיגה נגמרת. למען האמת, ב-5.5 כל הדרייברים שמגיעים עם ה-ISO הם Native אבל יש עדיין אפשרות להכניס דרייברים ישנים אם קימפלת ויצרת ISO חדש, אך לא תוכל לבצע את הטריק הזה ב-6.0 ולכן "קופסאות לבנות" (PC גנרי) לא יוכל להריץ גירסה 6.0, וכבר ב-5.5 קמו צעקות ש-VMWare העיפה דרייברים לכרטיסי רשת ביתיים.

ה-NDDK הוא קוד סגור ו-VMWare בשלב זה לא מתכננת לשחרר אותו לציבור, כך שיהיה מעניין לראות איך קהילת המשתמשים הביתיים תתגבר על הבעיה (מה עוד שב-6.0 תצטרך להתרגל להשתמש ב-VCSA במקום ה-vCenter שהיה רץ על Windows).

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

אחת הבעיות הגדולות בגרפיקה עם וירטואליזציה – היא המהירות של הגרפיקה. היא פשוט א-י-ט-י-ת. אינטל הוציאה את תמיכת ה-VT-D שמאפשרת לך (תאורתית) למפות כרטיס PCi-E (כמו כרטיס מסך) למערכת הפעלה אורחת. לצערי, התמיכה של אינטל בתוספת הזו היא כמו הליכה בשדה מוקשים: יכול להיות שהמעבד החדש שלך תומך בכך, אבל אתה צריך לבדוק שגם ה-Chipset בלוח האם שלך תומך ושגם ה-UEFI/BIOS בלוח האם שלך תומך, אחרת לא תוכל להשתמש ב-VT-D.

אז נניח שעברת את החלק הזה בשלום והחלטת שאתה רוצה להשתמש בפונקציה הזו. אם תחליט להשתמש ב-VMWare Workstation האחרון לדוגמא (גירסה 11), תמצא שאין פונקציונאליות כזו. את זה VMWare מאפשרת רק ב-ESXI. אז תתקין ESXI על המחשב שלך ותעבוד מ-VM, לא משהו מסובך, נכון?

אז זהו, שגם אם תעשה את השמיניות באוויר הללו, אתה תמצא שאתה לא יכול למפות כרטיס GTX מבוסס nVidia אלא רק כרטיסי Quadro יוקרתיים (יש אפשרות "להמיר" כרטיסים ישנים יותר שיהיו Quadro אבל זה לא לבעלי לב חלש, בחלק מהמקרים תצטרך להלחים..). עם כרטיסי Radeon יהיה לך יותר מזל אבל גם לכך תצטרך לשחק עם כל מיני הגדרות (כמו למפות את הזכרון שהמכונה תיקח כזכרון שלא ניתן למיפוי ל-VM אחר, אחרת הכל יתקע, מנסיון…), אבל תוכל לעשות משהו, שכמובן לא נתמך ע"י אף אחד.

ל-nVidia יש פתרונות – שתקנה כרטיס יקר או שתקנה פתרון יותר יקר, כמו כרטיסי ה-GRID שלהם (כולה כמה אלפי דולרים..). יש גם פתרונות "באמצע" כמו Horizon של VMWare, אך עדיין – כל הפתרונות הנ"ל יקרים ולא תמיד מתאימים.

לתוך הבעיה הזו אינטל נכנסה לאחרונה, עם גישה מאוד מעניינת: עד היום, הפתרונות שיש נתנו לך להריץ רק מכונה וירטואלית אחת עם האצה גרפית אמיתית (במקרה של Hyper-V אפשר מספר מכונות עם RemoteFX אך התמיכה הזו מאוד מוגבלת ולא כוללת דברים כמו OpenGL כך ששום אפליקציה רצינית לא תרוץ בצורה מואצת). מדוע שלא נבנה מחדש את כל רעיון ה-vGPU כך שכל מכונה וירטואלית תוכל לגשת למעבד הגרפי (של אינטל, לא מעבדים גרפיים אחרים) ותקבל ביצועים מעולים? אז 3 מהנדסים באינטל עובדים על כך והפרויקט נקרא KVMGT. תוכלו לראות מצגת (PDF) על כך כאן.

העבודה עדיין בעיצומה אולם לפני ימים ספורים אינטל שחררה מעין "אב טיפוס" (מצריך קימפול) שיכול לרוץ על וירטואליזציית KVM. הביצועים – מאוד מרשימים:

graph

אינטל כמובן לוקחת את הצד הניטרלי והשינויים יכנסו גם ל-QEMU, גם ל-XEN וגם ל-KVM. זה עדיין כמובן לא אומר שתוכל לרנדר פוטשופ עם כמה מאות שכבות בשניות, וכמובן זה לא ממש יתאים להריץ את המשחקים האחרונים שחונקים את המעבד הגרפי עד שהוא מתחנן לטישו, אבל זהו צעד ענק שאין ספק שיאומץ על ידי פתרונות וירטואליזציה אחרים כמו VirtualBox ואולי גם ע"י VMWare ומיקרוסופט (מי יודע..). בשלב זה המתחרים (AMD ו-nVidia) לא מציגים פתרונות מתחרים, אולם אני מאמין שלחץ מהמשתמשים יגרום להם לחשוב מחדש לגבי פיתוח פתרונות שיאומצו ע"י יצרני פתרונות הוירטואליזציה השונים.

אגב, למי שמחפש לדעת מה קורה עם VMWare בכל הקשור להאצה, אז אפשר לקבל רמז מגירסת VMWare Workstation 11., בגירסה זו התווספה האפשרות להגדיל את הזכרון הגרפי עד 2 ג'יגה (ע"ח ה-RAM שלך, לא על חשבון ה-RAM בכרטיס הגרפי שלך). מנסיון פשוט שביצעתי, זה משפר בטיפה, לא הרבה.

עוד עדכונים – בקרוב.

כמה מילים לגבי שדרוג ל-RHEL-7/CENTOS-7

בשבועות האחרונים מאז יצאה RHEL-7 לשוק ואחריה CentOS-7, שוחחתי עם מספר עמיתים ולקוחות לגבי התקנה של המערכת. שמעתי מאותם אנשים המון תסכול, עצבים על דברים שהשתנו וגם תכנונים לא נכונים להטמעה של המערכת ההפעלה הנ"ל (אני אתייחס אל RHEL/CENTOS כאחת לשם מאמר זה).

הפוסט הזה אינו בא לשמש כ"סקירה" על RHEL-7, אלא יותר כפוסט שנותן מספר נקודות שחשוב לעבור עליהן לפני הטמעה, מה ניתן ומה (לדעתי) צריך וכדאי לעשות לפני ההטמעה.

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

ניקח לדוגמא את מערכת SystemD, זו מערכת חדשה שמחליפה את SysV הישנה שהיתה עד כה בהפצות לינוקס. ב-RHEL-7 אין יותר SysV ואי אפשר במחי פקודת yum להעיף את systemd, היא משובצת לאורך ולרוחב ההפצעה, מה-Boot ועד ה-Login ונוגעת בכל החלקים, כולל שרותים (Services), לוגים וכו'. כל פורום לינוקס רציני שתבקרו בו, תמצאו ויכוחים ופיצוצים בעד ונגד SystemD, ואפשר למצוא בכל מיני מקומות "בעד" ו"נגד" כאשר אנשי יוניקס ותיקים רוקעים ברגליים ורוצים את Sys V init בחזרה ולעומתם רבים אחרים מסבירים את יתרונות ה-SystemD (כאן לדוגמא). הסיבה העיקרית שרד האט (ולאחרונה גם הפצות אחרות כמו אובונטו הבא) עוברים ל-SystemD זה התמודדות עם הצרכים של היום שלא היו בעבר. כיום יש מספיק מקרים שבהם אתה מכניס ציוד בצורה "חמה" (כלומר ללא כיבוי והפעלה) ובמקרים של שרתים יקרים מאוד גם ציוד שבעבר לא היה ניתן להכניס בצורה חמה כמו מעבדים, זכרונות, והתקנים נוספים (גם כרטיסי PCI-E), ומערכות Sys V init שהיו צריכות סקריפטים מסובכים ו-1001 ספריות ו-daemons שונים כדי להתמודד עם זה – הכל הוחלף ב-SystemD. יש לו Journal (מערכת לוגים משולבת) שנותנת לך לראות בפקודה אחת פשוטה סטטוס יותר מפורט של שרות, אם הוא לא עלה, מדוע הוא לא עלה – מבלי שתשב ותכתוב תוך כמה דקות/שעות (תלוי בכשרון שלך) משהו שינפה את הפלט של dmesg או var/log/messages/ או קבצי לוג אחרים.

ב-RHEL-7 (וכמובן CentOS-7), בשונה מגרסאות לינוקס ל-Enterprise הכל השתנה, החל מה-Kernel שהוא גירסה 3 (בעבר 2.6), המשך ב-Boot (כיום GRUB-2 a שהוא הרבה הרבה יותר מורכב מה-GRUB הראשון), דרך שפות פיתוח, ממשק גרפי, טיפול בציודים, הגדרות רשת, דיסקים, File System וכו', מה שאומר שאם תיקח שרת שרץ עליו RHEL-6 ותעביר אותו לגירסה 7, יש סיכוי רב שחלק מהדברים לא יעבוד או שהמכונה אפילו לא תעלה (כבר יצא לי לראות שרת שמישהו החליט שזה רעיון מעולה לשדרג אותו דרך YUM מ-CentOS 6.1 ל-7 ובסופו של דבר נשאר שרת יקר אבל שלא מצליח לעשות אפילו Boot).

RHEL-7 לפיכך אינו מתאים לשדרוג דרך YUM או דרך בחירת "שדרוג" כשעושים BOOT ל-ISO. במילים אחרות אל תסמכו על ה"שדרוג" הזה. הוא בהחלט ישדרג את קבצי ה-RPM, אבל יש מספיק דברים שהשתנו לגמרי בין 6.5 ל-7. סתם דוגמא: מריצים שרת Apache? מריצים מודולים שקימפלתם? תתפלאו – ב-RHEL-7 האפאצ'י הוא גירסה 2.4 ומודולים רבים לא מצליחים להתקמפל מולו, וחלק מהמודולים האחרים מתקמפלים אבל נופלים בעת העלאת שרות ה-Apache. כיף!

לפיכך, בהתאם למה שהצלחתי לאסוף מנסיוני ומנסיון חבריי, הנה מספר נקודות לגבי מעבר ל-RHEL-7:

  • תחנות Desktop/Workstations שמריצים תוכנות סגורות (שרטוט תלת מימד, קומפיילרים קנייניים, תוכנות IDE קנויות וכו') – לא לשדרג כרגע ל-7. תוכנות סגורות רבות עדיין אינן מתאימות לגירסה 7. אגב, שדרוג לגירסה 6.6 יצא בקרוב, אם בא לכם, אתם יכולים לשחק עם ה-Beta כאן.
  • תחנת שמריצות דברים בקוד פתוח – מומלץ להרים מכונות VM נסיוניות (לא שדרוג) עם האפליקציות ולתת למפתחים לשחק עם זה כמה ימים כדי לראות מה פעיל ומה שבור.
  • שרתים – גם כאן, אני ממליץ להרים מכונת VM ריקה עם RHEL-7 ולהתקין עליה את האפליקציות ולראות מה עובד ומה לא עובד. מצאתם שהכל עובד? אל תשדרגו עם הכלים של רד-האט, עדיף שתפרמטו ותתקינו מחדש, ועל כך תיכף ארחיב.
  • מכונות קומפילציות, Hadoop ושאר דברים יעודיים – נסו עם מספר מכונות VM להרים חווה קטנטנה כדי לראות שהכל עובד, כולל Stress Testing. קצת אחרי ששוחררה RHEL-7 היה באג רציני שתוקן באחד העדכונים.

כפי שציינתי לעיל, בשדרוגים יש סיכוי גבוה שמעבר מ-6.5 ל-7 (או גירסה מוקדמת יותר ל-7) דברים ישברו מבחינת סימנים (Symbols), תאימות בינארית (צורך בהתקנת compat למיניהם) ולכן אני ממליץ להקים את המכונה מחדש. לשמור את כל ה-DATA בנפרד ולהתחיל התקנה מחדש (ובהזדמנות להתחיל לחשוב על שימוש יותר מאסיבי עם Kickstart למי ש…אהממ… עדיין עובד עם ה-ISO). ישנם מערכות File Systems חדשות ויותר יציבות שיודעות לטפל בכמות הרבה יותר גדולה של קבצים – כמו XFS של סיליקון גרפיקס (בברירת מחדל אם לא תגדיר ידנית, RHEL תפרמט את הדיסק שלך ב-XFS). ה-LVM עבר שיפור (בבקשה, בבקשה, חדל מההתקנה של כל מערכת ההפעלה יחד עם הקבצים של המשתמש וה-SWAP הכל תחת Partition יחיד!), אם אתם משתמשים בחברה ב-Active Directory אז תוכלו ישירות מההתקנה להגדיר חיבור לדומיין ואת המשתמשים, וישנם שיפורים רבים נוספים, ובכלל, מומלץ לקרוא לעומק את ה-Installation Guide.

אם אתם הולכים להתקין את ההפצה על וירטואליזציה כמו HyperV או ESXI, אז אני שמח להודיעכם שאין צורך להתקין שום תוספים (ולא, גם לא VMWare Tools). הכל מגיע עם ההפצה בהתקנה רגילה, כך שאינכם צריכים להתקין כלום. למשתמשי HyperV – הבאג המעצבן של NFS עם NetApp על CentOS (המתנה של כמה עשרות שניות בין פקודה לפקודה) – תוקן ע"י רד-האט בתוך ההפצה. משתמשי ESXI – אתם תראו שה-TOOLS מופיעים כ-3rd Party, זה בסדר, הכלי שמותקן בפנים ושמפעיל vmtoolsd נעשה בשיתוף המהנדסים של VMWare.

אני רוצה לקחת את ההזדמנות הזו ולהזכיר לאנשים שקיים בלינוקס ובמיוחד בהפצה הזו תמיכה מעולה ב-Docker, כלומר קונטיינרים, כך שאם אתם חושבים על שדרוג, אין שום בעיה שתרימו קונטיינר עם גירסת הפצה ישנה יותר בתוך הקונטיינר (לא ב-HOST) ואז תתקינו את האפליקציה הישנה, כך גם תהיו מעודכנים ברמת ה-HOST וגם האפליקציות ירוצו כבעבר, ואנשי הסיסטם לינוקס יוכלו לצאת הביתה לפני 12 בלילה 😉

לסיכום: כן, דברים השתנו לחלוטין בגירסה 7, אבל מה לעשות, דברים משתנים וטכנולוגיות והגדרות משתנות. אי אפשר להישאר כל הזמן בעבר. הטכנולוגיה היום דורשת פתרונות יותר דינמיים, הצרכים משתנים והפתרונות גם. נכון, לסקריפטולוגים מביניכם שקיצרו את העבודה היום יומית שלהם לפקודות של 3-4 אותיות תהיה קצת עבודה לשנות את הסקריפטים (לחובבי פייתון – הגירסת ברירת מחדל עכשיו היא 2.7 עדיין, אבל זו הגירסה האחרונה שתתן אותו כברירת מחדל. הגירסה הבאה תקפוץ ישר ל-3.4 או מה שיהיה אז), אבל מבחינת SystemD עדיין סקריפטים שמשתמשים ב-chkconfig, service וכו' יוכלו לרוץ, תסתכלו במסמך הזה אך יחד עם זאת, תתחילו להכין את הסקריפטים שלכם ל-SystemD. לא לשכוח גם להוסיף את ה-REPO הזה.

בהצלחה

הבעיות של VCSA

קצת היסטוריה על VMWare ו-ESX: כש-VMWare החליטו בזמנו לצאת עם גירסת שרת מלאה (לפני כן היתה “גירסת שרת” אבל שהיתה רצה על מערכת ההפעלה שמותקנת במחשב שלך) הם יצאו עם 2 גרסאות: האחת נקראה ESX והשניה ESXi. גירסת ה-ESX נראתה כמו הפצת לינוקס (מה שגרם לרבים להתבלבל ולחשוב שמדובר בהפצת לינוקס מטעם VMWare עם קרנל לינוקס. המציאות היא שהקרנל הוא כולו של VMWare והם השתמשו בממשק תאימות בינארית ללינוקס (ABI) על מנת להריץ שרותי לינוקס שונים על ה-ESX וגם שמנהל השרת יוכל להתקין שרותים נוספים מלינוקסים אחרים על המכונה (זה היה תואם רד-האט). גירסת ESXi לעומת זאת היתה גירסה רזה שכללה רק את הקרנל + Shell מינימלי ועוד כמה כלים, רק בלי חומת אש, שרותי לינוקס וכו’.כיום יש רק גירסת ESXi.

אחד הדברים שהפתיע אנשי לינוקס רבים היה כלי הניהול של VMWare, מה שמוכר בתור ה-vCenter (לשעבר Virtual Center) שהיה כלי על טהרת ה-Windows שנכתב בדוט-נט ושגם שילב בתוכו חלקים מאינטרנט אקספלורר. VMWare גם הוציאה כלי וובי אבל שלא נתן הרבה פונקציונאליות (כלומר הוא לא יכל להחליף את ה-vCenter). מנהלי רשת רבים התלוננו מדוע אין כלי לינוקסאי כזה והתשובה של VMWare היתה שחרור של SDK וגם מכונה וירטואלית לינוקסאית קטנה שכללה סקריפטים שאפשרו לחברות שמשתמשות בלינוקס – להתממשק עם ה-vCenter.

בגירסה 5 הדברים התחילו להשנות (והשתנו יותר בגירסה 5.1) כאשר VMWare שחררו את ה-VCSA (ר”ת של VMWare vCenter Server Appliance) – זו מכונת לינוקס וירטואלית שאמורה להחליף את הגירסה החלונאית בגירסת לינוקס. היא עדיין לא כוללת את כל הפונקציונאליות של הכלי החלונאי (כך לדוגמא עדיין לא ניתן להתקין תוספים/Plugins ב-VCSA עצמו), אבל VMWare נתנה רמז עבה מאוד שזו דרכה – היא חוזרת ללינוקס ובגרסאות עתידיות היא תשקיע יותר ב-Appliance הלינוקסאי מאשר בכלי החלונאי.

עד כאן הכל טוב ויפה (במיוחד שאתה צריך פחות רשיונות ממיקרוסופט). הבעיה מתחילה ב-Appliance עצמו. VMWare שחררה אותו ככלי רשמי ויציב, אבל מי שעשה לו QA .. לא כדאי שיפגוש אותי Smile

הבעיה הראשית מתחילה בזה ש-VMWare לא שחררה אותו כקובץ ISO להתקנה שמזכירה לינוקס (כמו שהיה ב-ESX 3.X) אלא שחררה אותו כקופסא סגורה עם קבצי OVF, VMDK וכו’, ומה ששחררו קיימות בו כל מיני בעיות הקשורות לרשת שפוסט זה יתייחס אליהם.

כאן אצלי בבית ב-LAB שלי, יש לי 2 שרתי DNS (מאסטר/סלייב) וסביר להניח שאם אתה מתעסק עם VMWare בחברה, יש לכם איזה שרת DNS, בין אם זה לינוקס או (סביר להניח) הפתרון של מיקרוסופט שמשולב Active Directory. אני מניח שהכנת לך שם hostname יחודי עבור ה-VCSA עם כתובת IP יחודית משלו ושלא ממש הלכת ל-Go Daddy או ספקים אחרים כדי לרכוש לשרת תעודת SSL, וכאן מתחילה הבעיה (לא באי רכישה) – ה-VCSA מגיע עם שם מכונה localhost שזה לא בדיוק דבר שתרצה.

אתה יכול להיכנס לממשק הוובי, להגדיר כתובת IP ושם hostname, להתחבר ל-AD ואולי להשתמש ב-DB חיצוני (אורקל או DB2 של IBM, עוד לא SQL של מיקרוסופט וגם משום מה לא MySQL, קצת מפתיע ש-VMWare משתמשים ב-JAVA ב-VCSA והם משתמשים ב-JDBC ב-Tomcat אבל הם לא כוללים תמיכה ל-DB אחרים. אם אתם רוצים להוסיף תמיכה למיקרוסופט SQL נסו את הלינק הזה [אגב, הלינק כרגע מת, אבל תודות לגוגל אפשר לראות את הגירסה הטקסטואלית כאן]), אבל ברגע שתשנו כתובת IP ואת ה-hostname ושאר פרמטרים (לא לשכוח ללחוץ על Toggle certificate settings שישתנה ל-yes) – תצטרכו להפעיל את המכונה מחדש (דרך החוצץ System)

ואז המכונה תיתקע בעליה, אם תסתכלו בקונסולה, תראו שהוא נתקע בשורה שכתוב:

waiting for the embedded database to startup [ok]

מה קרה? אוה, טוב ששאלתם…

ה-VCSA הבין שצריך ליצור תעודת SSL חדשה, והוא יצר, אבל הסקריפט של ה-DB לא יודע מה לעשות הלאה, אז הוא פשוט נתקע. אם תעשו Reboot למחשב, זה לא יעזור. זה יחזור שוב. מה שצריך לעשות הוא לבטל את האופציה ליצור תעודות SSL, אבל … אין לכם גישה לא לממשק הוובי ולא ל-SSH. תצטרכו לטפל בזה כמו שמטפלים בתקלה בשרת לינוקס (לא חשבתם שתתחמקו מלינוקס, נכון?)

אז איך מטפלים? כרגיל עם VCSA, מי שבנה את ה-Appliance בנה בצורה מחורבנת לגמרי. Safe mode לא יעזור לכם, ולכן עקבו אחר ההוראות הבאות:

  1. הפעילו את השרת מחדש והיכנסו מיד ל-Console ולחצו על מקש (לדוגמא רווח) כדי לעצור את הטיימר.
  2. לחצו על מקש p ואז ה-grub יבקש סיסמא. הסיסמא היא סיסמת ה-root שלכם (אם לא שיניתם אותה עדיין, היא vmware באותיות קטנות)
  3. לאחר הקשת הסיסמא תחזרו שוב ל-GRUB. בחרו בשורה הראשונה ולחצו על מקש e
  4. כעת יופיעו לכם השורות ש-grub אמור להריץ. לחצו על החץ למטה ובחרו בשורה השניה ושוב לחצו על מקש e
  5. לכו עם החיצים עד סוף השורה והוסיפו את הטקסט הבא: init=/bin/sh ולחצו על מקש enter
  6. כעת לחצו על מקש b והלינוקס יתחיל להיטען ולאחר מספר שניות הוא יעצר עם סימן #
  7. כעת עלינו למחוק קובץ. כל עוד הקובץ קיים, המערכת תנסה ליצור תעודות חדשות והמערכת תיתקע ב-boot רגיל, לכן הכניסו את הפקודה:
    rm /etc/vmware-vpx/ssl/allow_regeneration
  8. הקישו את הפקודה reboot ולחצו enter. המערכת תיתן אולי מספר הודעות שגיאה. תתעלמו.
  9. המערכת תעלה מחדש ובהצלחה. לאחר שתקבלו את המסך הכחול (אחלה בחירת צבעים יש להם), תמתינו עוד מספר שניות (או דקות, תלוי במעבד וכמה חזקה המכונה) ואז היכנסו לממשק הוובי

ברכותיי. נגמרה הבעיה.

אני ממליץ בחום לא להשתמש ב-VCSA במערכות פרודקשן! כותב שורות אליו מצא המון סקריפטים בתוך ה-VCSA שיש להם באגים ומי שכתב אותם כנראה למד לינוקס מתוך ספר ולא מתוך התנסות מלאה (שורות של סקריפטים שחוזרות במקום להשתמש ב-while וכו’) ויש גם לא מעט שגיאות במימוש התחברות ל-NFS – עקבו אחר ההוראות כאן) ואני משער שהדברים ישתפרו בעתיד (ואולי, מי יודע, אולי הם יוסיפו איזה משהו שמראה הורדת גירסה בזמן שמשדרגים במקום מסך סטטי שאין לך אפשרות לדעת אם יורד משהו וכמה ירד!), אבל עד אז, שימו את ה-VCSA כ-VM על מכונה צדדית (אגב, בניגוד להגדרות שם, אין צורך ב-8 ג’יגה זכרון, גם 4 יספיקו בשביל הטסטים). אני גם מקווה שבעתיד הם יוציאו גירסת ISO נורמלית ואולי, רק אולי, יהיה פורום או מקום כלשהו לדווח על באגים ואולי לתת להם תיקוני סקריפטים, גם למי שאין לו מנוי בתשלום (היי, אני יכול לקוות, לא?).