בעיות מוכרות

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

בעיות כלליות

במאמרים הבאים מפורטות הנחיות לפתרון בעיות או מידע כללי.

הסוכן של האורח מתעלם מהאפשרות ip_forwarding בהגדרות NetworkInterfaces

קטע ההגדרות של סוכן האורח NetworkInterfaces כולל את האפשרות ip_forwarding. אפשר להשתמש באפשרות הזו כדי למנוע מהסוכן להתקין כתובות IP של כינויים ומסלולי העברת IP משרת המטא-נתונים (MDS). עם זאת, בגרסאות של סוכני אורחים שמשתמשות בארכיטקטורה מבוססת-פלאגין, כולל פלאגין הליבה, הסוכן מתעלם מאפשרות ההגדרה ip_forwarding. הסוכן של האורח מתקין כתובות IP של כינויים ומסלולי העברת IP ללא קשר להגדרה. מידע נוסף זמין במסמכי התיעוד של סוכן האורח. הבעיה הזו משפיעה עליכם אם אתם משתמשים ב-SAP Netweaver pacemaker בהגדרה עם מאזן עומסים פנימי (ILB).

כדי לפתור את הבעיה, צריך להגדיר את מאפיין המטא-נתונים enable-guest-agent-core-plugin לערך false, כמו שמתואר במסמכי התאימות לאחור.

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

במקרים נדירים, יכול להיות שמכונות וירטואליות מוגנות שנוצרו לפני 7 בנובמבר 2025 עם הפעלה מאובטחת, או מכונות שמשתמשות בתוכנה להצפנה מלאה של הדיסק או בהצפנת סודות ל-PCR של vTPM, לא יצליחו לבצע אתחול. יכול להיות שהבעיה נובעת מרצף שגוי של עדכונים (לדוגמה, עדכון של shim בלי שיש אישורים מתאימים) אחרי שתוקף האישורים של Microsoft Secure Boot יפוג במחצית השנייה של 2026.

פתרון

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

יכול להיות שדיסקים מקומיים מסוג SSD שמצורפים למכונות C4,‏ C4A,‏ C4D,‏ C4N ו-H4D לא יתעדו את כל הפעולות של כתיבה במקרה של הפסקת חשמל

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

במכונות מסוג C4,‏ C4A,‏ C4D,‏ C4N ו-H4D, יכול להיות שהדיסקים המקומיים מסוג SSD ששוחזרו לא יכללו כתיבות שהושלמו מיד לפני אירוע הפסקת החשמל. כשמופע המחשוב מופעל מחדש, קריאה מכתובת לוגית של בלוק (LBA) שמושפעת מהבעיה מחזירה שגיאה שמציינת שאי אפשר לקרוא את ה-LBA. אם המכונה הווירטואלית שלכם עוברת הפעלה מחדש לא צפויה, כדאי לבדוק את יומני השגיאות של מערכת ההפעלה כדי לראות אם יש כשלים בקריאה או בכתיבה אחרי שהמכונה הווירטואלית מופעלת מחדש.

הקיבולת של Hyperdisk Throughput ו-Hyperdisk Extreme צורכת מכסות של Persistent Disk בו-זמנית

כשיוצרים דיסקים מסוג Hyperdisk Throughput או Hyperdisk Extreme, קיבולת הדיסק נספרת בו-זמנית בשתי מכסות נפרדות: המכסה הספציפית של Hyperdisk ומכסה מקבילה של Persistent Disk.

  • השימוש ב-Hyperdisk Throughput Capacity (GB) (HDT-TOTAL-GB) נספר גם במכסת Persistent disk standard (GB) (DISKS-TOTAL-GB).
  • השימוש ב-Hyperdisk Extreme Capacity (GB) (HDX-TOTAL-GB) נספר גם במכסת Persistent disk SSD (GB) (SSD-TOTAL-GB).

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

כדי לפתור את הבעיה, צריך לשנות את שתי המכסות בכל פעם שמבקשים להגדיל אותן. כשמשנים את מכסת HDT-TOTAL-GB או HDX-TOTAL-GB, צריך לשנות גם את מכסת DISKS-TOTAL-GB או SSD-TOTAL-GB בהתאם.

הפרעות בעומסי עבודה במופעי A4 בגלל בעיות בתוכנת קושחה של מעבדי NVIDIA B200 GPU

חברת NVIDIA זיהתה שתי בעיות בקושחה של מעבדי GPU מסוג B200, שמשמשים במופעי A4. הבעיות האלה עלולות לגרום להפרעות בעומסי העבודה, למשל פקודת nvidia-smi לא מגיבה. אם אתם מבחינים בהפרעות בעומסי עבודה במכונות וירטואליות מסוג A4, אתם צריכים לוודא שאחד מהתנאים הבאים מתקיים:

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

שגיאות אפשריות של מארחים במהלך יצירת מופע C4 בצמתים של דייר יחיד

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

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

הקונסולה הסדרתית היא לקריאה בלבד במכונות Bare Metal מסוג C4 ו-C4D

אי אפשר להפעיל גישה אינטראקטיבית למסוף הטורי במכונות Bare Metal מסוג C4 או C4D. המסוף הטורי הוא לקריאה בלבד.

פתרון אפשרי

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

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

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

כדי לפתור את הבעיה, אפשר להשתמש באחת מהשיטות הבאות:

  • מעדכנים את Cluster Toolkit לגרסה 1.65.0 ואילך. לאחר מכן פורסים מחדש את האשכול באמצעות הפקודה הבאה:

    gcluster deploy -w --force BLUEPRINT_NAME.yaml

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

    1. משתמשים ב-SSH כדי להתחבר לצומת הבקרה הראשי של האשכול.

      gcloud compute ssh --project PROJECT_ID --zone ZONE DEPLOYMENT_NAME-controller

      כדי למצוא את השם המדויק ואת כתובת ה-IP של צומת הבקרה הראשי, אפשר להיכנס למסוף Google Cloud ולעבור לדף VM instances.

    2. יוצרים גיבוי של קובץ cloud.conf הנוכחי. הקובץ הזה נמצא בדרך כלל בתיקייה /etc/slurm/.

      sudo cp /etc/slurm/cloud.conf /etc/slurm/cloud.conf.backup-$(date +%Y%m%d)

    3. בעזרת הרשאות sudo, פותחים את הקובץ /etc/slurm/cloud.conf באמצעות עורך טקסט.

    4. מוסיפים או משנים את השורה שמכילה את UnkillableStepTimeout. לדוגמה, כדי להגדיר את הזמן הקצוב לתפוגה ל-900 שניות (15 דקות), פועלים לפי השלבים הבאים:

      UnkillableStepTimeout=900

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

    6. משתמשים בפקודה sudo scontrol reconfigure כדי להחיל את ההגדרה החדשה על כל האשכול בלי להפעיל אותו מחדש.

אימות התיקון

כדי לוודא שההגדרה השתנתה, מריצים את הפקודה הבאה:

   scontrol show config | grep UnkillableStepTimeout

הפלט צריך לשקף את הערך החדש שהגדרתם, לדוגמה: UnkillableStepTimeout = 900.

נפתר: שינוי של IOPS או של קצב העברת הנתונים בדיסק ראשי של שכפול אסינכרוני באמצעות הפקודה gcloud compute disks update גורם לשגיאה שקרית

הבעיה הבאה נפתרה ב-1 ביוני 2025.

כשמשתמשים בפקודה gcloud compute disks update כדי לשנות את ערכי ה-IOPS והתפוקה בדיסק ראשי של שכפול אסינכרוני, מוצגת הודעת שגיאה ב-CLI של gcloud גם אם העדכון בוצע בהצלחה.

כדי לוודא שהעדכון בוצע בהצלחה, צריך לבדוק את מאפייני הדיסק באמצעות gcloud CLI או Google Cloud המסוף כדי לראות את ערכי ה-IOPS והתפוקה החדשים. מידע נוסף זמין במאמר בנושא הצגת הגדרות הביצועים שהוקצו ל-Hyperdisk.

יכול להיות ששרת המטא-נתונים יציג מטא-נתונים ישנים של מכונת physicalHost Compute

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

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

ערכים ארוכים של baseInstanceName בקבוצות מופעי מכונה מנוהלים (MIG) עלולים לגרום להתנגשויות בשמות של דיסקים

ב-MIG, יכולים להיווצר קונפליקטים בשמות הדיסקים אם תבנית המופע מציינת דיסקים שייווצרו עם יצירת מופע Compute, והערך של baseInstanceName חורג מ-54 תווים. זה קורה כי Compute Engine יוצר שמות של דיסקים באמצעות שם המכונה כתחילית.

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

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

יצירת בקשות לשמירת מקום לעתיד או שמירת מקום באמצעות תבנית של הגדרות מכונה שמציינת סוג מכונה A2,‏ C3 או G2 גורמת לבעיות

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

  • יכול להיות שהמערכת לא תצליח ליצור את ההזמנה. אם הפעולה מצליחה, אחת מהאפשרויות הבאות מתרחשת:

    • אם יצרתם הזמנה שנעשה בה שימוש אוטומטי (ברירת מחדל), יצירת מופעי מחשוב עם מאפיינים תואמים לא תגרום לשימוש בהזמנה.

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

  • הבקשה ליצירת מקום שמור לעתיד נוצרת בהצלחה. אבל אם תשלחו את הבקשה לבדיקה, היא תידחה. Google Cloud

אי אפשר להחליף את תבנית של הגדרות מכונה ששימשה ליצירת מקום שמור או בקשה למקום שמור לעתיד, או לבטל את מאפייני המכונה של התבנית. אם אתם רוצים לשמור משאבים לסוגי מכונות A2,‏ C3 או G2, אתם צריכים לבצע אחת מהפעולות הבאות:

מגבלות בשימוש בסוגי מכונות -lssd עם Google Kubernetes Engine

כשמשתמשים ב-Google Kubernetes Engine API, למאגר הצמתים שמקצים לו דיסקי SSD מקומיים חייבים להיות מספר דיסקי SSD מקומיים זהה למספר של סוג המכונה שנבחר: C4,‏ C3 או C3D. לדוגמה, אם אתם מתכננים ליצור מופע חישוב שמשתמש בסוג המכונה c3-standard-8-lssd, צריך שני דיסקים מקומיים מסוג SSD. אם אתם משתמשים בסוג המכונה c3d-standard-8-lssd, נדרש רק דיסק אחד. אם מספר הדיסק לא תואם, תקבלו שגיאת הגדרה שגויה של Local SSD ממישור הבקרה של Compute Engine. כדי לבחור את המספר הנכון של דיסקים מסוג SSD מקומי, צריך לעיין בסוגי מכונות שמצורפים אליהם אוטומטית דיסקים מסוג SSD מקומי לפי סוג המכונה lssd.

אם אתם משתמשים במסוף Google Kubernetes Engine Google Cloud כדי ליצור אשכול או מאגר צמתים, יכול להיות שיצירת הצומת תיכשל או שדיסקים של SSD מקומיים לא יזוהו כאחסון זמני כשמשתמשים באחד מסוגי המכונות הבאים:

  • c4-standard-*-lssd
  • c4-highmem-*-lssd
  • c3-standard-*-lssd
  • c3d-standard-*-lssd

שונות בתפוקת TCP בזרימה יחידה במופעי C3D

במופעי C3D עם יותר מ-30 מעבדים וירטואליים, יכול להיות שתהיה שונות בנפח התפוקה של TCP של זרימה יחידה, ולפעמים הוא יהיה מוגבל ל-20 עד 25 Gbps. כדי להשיג קצב גבוה יותר, צריך להשתמש בכמה זרמי TCP.

מדד הניצול של המעבד (CPU) לא נכון במקרים של מכונות וירטואליות לחישוב שמשתמשות בשרשור אחד לכל ליבה

אם המעבד של מכונת החישוב משתמש בשרשור אחד לכל ליבה, מדד השימוש במעבד של Cloud Monitoring בכרטיסייה Observability* בדף VM instances במסוף Compute Engine Google Cloud יגיע רק ל-50%. שני תהליכים לכל ליבה הם ברירת המחדל ברוב סוגי המכונות. מידע נוסף זמין במאמר בנושא הגדרת מספר השרשורים לכל ליבה.

כדי לראות את ניצול המעבד של מכונת ה-Compute שלכם בנורמליזציה ל-100%, צריך לראות את ניצול המעבד ב-Metrics Explorer. מידע נוסף זמין במאמר יצירת תרשימים באמצעות Metrics Explorer.

Google Cloud חיבורים ל-SSH בדפדפן דרך המסוף עלולים להיכשל אם משתמשים בכללים מותאמים אישית של חומת האש

אם אתם משתמשים בכללי חומת אש מותאמים אישית כדי לשלוט בגישת SSH למופעי המחשוב, יכול להיות שלא תוכלו להשתמש בתכונה SSH בדפדפן.

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

שמות זמניים לדיסקים

במהלך עדכונים של מכונות וירטואליות שהופעלו באמצעות הפקודה gcloud compute instances update או השיטה instances.update API, יכול להיות ש-Compute Engine ישנה באופן זמני את השם של הדיסקים של המכונה הווירטואלית, על ידי הוספת אחד מהסיומות הבאות לשם המקורי:

  • -temp
  • -old
  • -new

בסיום העדכון, המערכת של Compute Engine מסירה את הסיומת ומשחזרת את השמות המקוריים של הדיסקים.

הגדלת דיסקים של אחסון מתמיד גורמת לעלייה בזמן האחזור

במקרים מסוימים, שינוי הגודל של דיסקים גדולים של Persistent Disks (בגודל של ‎~3 TB או יותר) עלול לפגוע בביצועי הקלט/פלט של הדיסק. אם הבעיה הזו משפיעה עליכם, יכול להיות שיהיה זמן אחזור ארוך יותר בדיסקים שלכם במהלך פעולת שינוי הגודל. הבעיה הזו יכולה להשפיע על דיסקים קשיחים קבועים מכל סוג.

יכול להיות שהתהליכים האוטומטיים שלכם ייכשלו אם הם משתמשים בנתוני תגובה של API לגבי מכסות של התחייבות מבוססת-משאבים

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

  1. הנתונים בתגובה מגיעים מכל אחת מהשיטות הבאות של Compute Engine API:

  2. משתמשים ב-int במקום ב-number כדי להגדיר את השדה של מכסת המשאבים בתשובות של ה-API. אפשר למצוא את השדה בכל אחת מהשיטות הבאות:

  3. יש לכם מכסה בלתי מוגבלת כברירת מחדל לכל המק"טים של התחייבות לשימוש ב-Compute Engine.

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

שורש הבעיה

אם המכסה שלכם מוגבלת, ואתם מגדירים את השדה items[].quotas[].limit או quotas[].limit כסוג int, יכול להיות שנתוני התגובה של ה-API לגבי מגבלות המכסה עדיין ייכללו בטווח של סוג int, והתהליך האוטומטי שלכם לא יופרע. אבל אם מכסת ברירת המחדל היא ללא הגבלה, Compute Engine API מחזיר ערך לשדה limit שנמצא מחוץ לטווח שמוגדר על ידי סוג int. התהליך האוטומטי שלכם לא יכול לצרוך את הערך שמוחזר על ידי שיטת ה-API, ולכן הוא נכשל.

איך לעקוף את הבעיה

כדי לעקוף את הבעיה ולהמשיך ליצור את הדוחות האוטומטיים, אפשר לפעול באחת מהדרכים הבאות:

  • מומלץ: לפעול לפי מאמרי העזרה של Compute Engine API ולהשתמש בסוגי הנתונים הנכונים בהגדרות של ה-method של ה-API. ספציפית, משתמשים בסוג number כדי להגדיר את השדות items[].quotas[].limit ו-quotas[].limit של שיטות ה-API.

  • צריך להקטין את מגבלת המכסה לערך שקטן מ-9,223,372,036,854,775,807. צריך להגדיר מכסות מקסימליות לכל הפרויקטים שיש בהם התחייבויות מבוססות-משאבים, בכל האזורים. אפשר לעשות זאת באחת מהדרכים הבאות:

בעיות מוכרות במכונות GPU

בקטע הבא מפורטות הבעיות הידועות במכונות GPU ב-Compute Engine.

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

בסוגי מכונות שעברו אופטימיזציה למאיץ, מעבדי ה-GPU מצורפים באופן אוטומטי. ברוב סוגי המכונות מסדרת A שעברו אופטימיזציה להאצה, למעט A2 Standard, מצורפים אוטומטית דיסקים של SSD מקומי.

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

שגיאות ביצירה וירידה בביצועים כשמשתמשים בממשקי רשת דינמיים עם מכונות GPU

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

  • הפעולה נכשלת עם שגיאה כמו:

    Internal error. Please try again or contact Google Support. (Code: 'CODE')

  • הפעולה מצליחה, אבל הביצועים של המופע יורדים, למשל רוחב הפס ברשת נמוך משמעותית.

הבעיות האלה מתרחשות כי ההגדרה של כרטיס הרשת הדינמי מובילה לשגיאות כש-Compute Engine מנסה לפזר את כרטיסי הרשת הוירטואליים של המופע על פני כרטיסי רשת פיזיים בשרת המארח.

בעיות מוכרות במופעי Bare Metal

אלה הבעיות המוכרות במכונות Bare Metal ב-Compute Engine.

הפעלת תחזוקת המארח באופן ידני לא עובדת במכונות X4

במכונות X4, התהליך שמתואר במאמר בנושא הפעלה ידנית של אירוע תחזוקה במארח לא עובד.

פתרון אפשרי

  1. עוצרים את מופע X4.
  2. אחרי שמצב המופע משתנה ל-TERMINATED, מפעילים את מופע X4.

מידע על הפסקה או הפעלה מחדש של מכונת X4 זמין במאמר הפסקה או הפעלה מחדש של מכונת Compute Engine.

סוגי מכונות Bare Metal C4D לא תומכים בתמונות SUSE Linux 15 SP6

אי אפשר להריץ את מערכת ההפעלה SUSE Linux Enterprise Server ‏ (SLES) בגרסה 15 SP6 במופעי Bare metal של C4D.

פתרון אפשרי

במקום זאת, צריך להשתמש ב-SLES 15 SP5.

אי אפשר לדמות תחזוקת מארח במכונות C4 Bare Metal

סוגי המכונות c4-standard-288-metal ו-c4-highmem-288-metal לא תומכים בסימולציה של אירועי תחזוקת מארח.

דרך לעקיפת הבעיה

שימוש במכונות וירטואליות (VM) שנוצרו באמצעות סוגי מכונות אחרים מסוג C4 כדי לדמות אירועי תחזוקה.

  1. יצירת מכונה וירטואלית באמצעות סוג מכונה C4 שלא מסתיים ב--metal.

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

  2. סימולציה של אירוע תחזוקה של המארח עבור מכונה וירטואלית.

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

רמת ביצועים נמוכה מהצפוי במופעי Bare Metal של Z3 ב-RHEL 8

כשמשתמשים ב-Red Hat Enterprise Linux ‏ (RHEL) בגרסה 8 עם מופע Z3 bare metal, ביצועי הרשת נמוכים מהצפוי.

שורש הבעיה

חסרה תכונה של Page Pool בגרסת הליבה של Linux‏ (4.18) שמשמשת את RHEL 8.

דרך לעקיפת הבעיה

כשעובדים עם מופעי Z3 bare metal, כדאי להשתמש בגרסה עדכנית יותר של RHEL או במערכת הפעלה אחרת.

בעיות שקשורות לשימוש בממשקי רשת דינמיים

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

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

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

מכיוון שהנתיבים המקומיים לא מתווספים ל-NIC דינמי, יכול להיות שחבילות נתונים יאבדו ב-NIC הדינמי.

כדי לפתור את הבעיה, צריך להוסיף את כתובות ה-IP באופן ידני, כך:

  1. מתחברים למכונה באמצעות SSH.

  2. אם מגדירים טווח של כתובות IP וירטואליות, מבצעים את הפעולות הבאות. אם לא, אפשר לדלג על השלב הזה.

    1. ב-/etc/default/instance_configs.cfg, מוודאים שההגדרה ip_aliases מוגדרת ל-true.

    2. אם ההגדרה ip_aliases מוגדרת ל-false, משנים את הקובץ כך שהיא תוגדר ל-true ואז מפעילים מחדש את סוכן האורח:

      systemctl restart google-guest-agent

  3. מגדירים נתיב מקומי לטווח כתובות ה-IP של הכינוי או לכתובת ה-IP של כלל ההעברה באמצעות הפקודה הבאה:

    ip route add to local IP_ADDRESS dev DYNAMIC_NIC_DEVICE_NAME proto 66

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫IP_ADDRESS: טווח כתובות ה-IP של הכינוי או כתובת ה-IP של כלל ההעברה שרוצים להוסיף להם נתיב מקומי.
    • ‫DYNAMIC_NIC_DEVICE_NAME: שם המכשיר של ה-NIC הדינמי שרוצים להוסיף לו נתיב מקומי. לדוגמה, a-gcp.ens4.3.

בעיות בהתקנה ובניהול של כרטיסי רשת דינמיים בגרסאות של סוכן האורח 20250901.00 עד 20251120.01

אם מגדירים ניהול אוטומטי של כרטיסי NIC דינמיים והמופע מריץ את סוכן האורח בגרסה 20250901.00 עד 20251120.01, יכול להיות שתיתקלו בבעיות הבאות:

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

    יכול להיות שתקבלו שגיאה שכוללת את Cannot find device כשמריצים פקודות במערכת ההפעלה של האורח שמפנות ל-NIC דינמיים.

  • מחיקה של כמה כרטיסי רשת דינמיים גורמת לכך ששרת המטא-נתונים לא נגיש.

שורש הבעיה

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

רזולוציה

כדי לפתור את הבעיות האלה, צריך לעדכן את המופע לשימוש בגרסה 20251205.00 או בגרסה חדשה יותר של סוכן האורח:

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

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

יירוט מנות עלול לגרום להשמטת מנות בגלל תגי VLAN חסרים בכותרות של Ethernet

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

שורש הבעיה

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

דרך לעקיפת הבעיה

אל תשתמשו Google Cloud בתכונות שמסתמכות על חסימת מנות, כמו נקודות קצה של חומת אש.

פעולות של NIC דינמי נכשלות כשמכונת חישוב נמצאת בכמה קבוצות של מכונות

אם מוסיפים או מוחקים NIC דינמי, והפעולה נתקעת במצב RUNNING עם התקדמות של 0% ובסופו של דבר נכשלת עם INTERNAL_ERROR, יכול להיות שהסיבה לכך היא שמכונת המחשוב נמצאת בכמה קבוצות של מכונות (מנוהלות או לא מנוהלות).

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

בעיות מוכרות במופעי מחשוב של Linux

אלה הבעיות המוכרות במופעי מחשוב של Linux.

שגיאה בשדרוג חבילה ב-Rocky Linux 9.7

הפעולה dnf update נכשלת בגרסה v20251113 או בגרסאות קודמות של תמונות Rocky Linux Accelerator Optimized (לדוגמה, rocky-linux-9-optimized-gcp-nvidia-latest-v20251113) בגלל סתירה בתלות של חבילה. יכול להיות שתופיע שגיאה דומה לזו:

[root@rockylinux9 ~]# dnf update
CIQ SIG/Cloud Next for Rocky Linux 9 37 MB/s | 49 MB 00:01
CIQ SIG/Cloud Next Nonfree for Rocky Linux 9 4.4 MB/s | 1.5 MB 00:00
NVIDIA DOCA 2.10.0 packages for EL 9.5 239 kB/s | 160 kB 00:00
Google Compute Engine 38 kB/s | 8.2 kB 00:00
Google Cloud SDK 59 MB/s | 154 MB 00:02
Rocky Linux 9 - BaseOS 24 MB/s | 6.3 MB 00:00
Rocky Linux 9 - AppStream 36 MB/s | 11 MB 00:00
Rocky Linux 9 - Extras 124 kB/s | 16 kB 00:00
Error:
 Problem 1: package perftest-25.04.0.0.84-1.el9.x86_64 from baseos requires libhns.so.1(HNS_1.0)(64bit), but none of the providers can be installed
  - package perftest-25.04.0.0.84-1.el9.x86_64 from baseos requires libhns.so.1()(64bit), but none of the providers can be installed
  - cannot install both libibverbs-51.0-3.el9_5.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-51.0-5.el9_5.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-54.0-2.el9_6.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-54.0-3.el9_6.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-54.0-4.el9_6.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-54.0-5.el9_6.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-57.0-3.el9_7_ciq.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-57.0-2.el9.x86_64 from baseos and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install the best update candidate for package perftest-25.01.0-0.70.g759a5c5.2501060.x86_64
  - cannot install the best update candidate for package libibverbs-2501mlnx56-1.2501060.x86_64
 Problem 2: package ucx-ib-mlx5-1.18.0-1.2501060.x86_64 from @System requires ucx(x86-64) = 1.18.0-1.2501060, but none of the providers can be installed
  - cannot install both ucx-1.18.1-1.el9.x86_64 from appstream and ucx-1.18.0-1.2501060.x86_64 from @System
  - cannot install both ucx-1.18.1-1.el9.x86_64 from appstream and ucx-1.18.0-1.2501060.x86_64 from doca
  - cannot install the best update candidate for package ucx-ib-mlx5-1.18.0-1.2501060.x86_64
  - cannot install the best update candidate for package ucx-1.18.0-1.2501060.x86_64
...
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

שורש הבעיה

קיים ניגוד בין גרסאות חבילות במרחב המשתמש בין גרסאות DOCA OFED לפני 3.20 לבין Rocky Linux 9.7. באופן ספציפי, Rocky Linux 9.7 כולל חבילות ucx ו-perftest שהן גרסה מאוחרת יותר מהחבילות התואמות במאגר DOCA OFED. חוסר ההתאמה בין הגרסאות גורם לכך ש-dnf update נכשל עם שגיאות ברזולוציית התלות.

רזולוציה

לפני שמבצעים שדרוג מלא של המערכת, צריך לעדכן את חבילת המאגר של DOCA:

sudo dnf update doca-repo
sudo dnf update

תמונות שעברו אופטימיזציה של Rocky Linux Accelerator שנבנו בדצמבר 2025 (למשל, rocky-linux-9-optimized-gcp-nvidia-latest-v20251215) כבר כוללות את חבילת doca-repo המעודכנת, ולכן בעיית השדרוג הזו לא קיימת בגרסאות האלה או בגרסאות מאוחרות יותר.

‫OS Login לא נתמך ב-SLES 16

בעיה בהגדרת SSH ב-SUSE Linux Enterprise Server‏ (SLES) 16 מונעת את השימוש בתכונה Google Cloud OSLogin. עם זאת, חיבורי SSH שמנוהלים באמצעות מטא-נתונים לא מושפעים וימשיכו לפעול.

פורמטים נתמכים של כתובות URL לסקריפט לטעינה בזמן ההפעלה

אם מופעלת במכונת החישוב שלכם סביבת אורח בגרסה 20251115.00, לא ניתן לאחזר סקריפט לטעינה בזמן ההפעלה באמצעות מפתח המטא-נתונים startup-script-url אם כתובת ה-URL היא בפורמט https://storage.googleapis.com/ שמתואר במאמר שימוש בסקריפטים לטעינה בזמן ההפעלה במכונות VM של Linux.

כדי לעקוף את הבעיה הזו, אפשר להשתמש באחד מפורמטי כתובות ה-URL הנתמכים הבאים:

  • כתובת URL מאומתת: https://storage.cloud.google.com/BUCKET/FILE
  • URI של אחסון ב-CLI של gcloud: gs://BUCKET/FILE

לא ניתן להריץ מכונות וירטואליות שמשתמשות בתמונות של Debian 11 לפני גרסה v20250728‏ apt update

ב-22 ביולי 2025, קהילת Debian הסירה את Debian 11 (Bullseye) backports מה-Debian upstream הראשי. העדכון הזה גורם לכך ש-sudo apt update ייכשל עם השגיאה הבאה:

The repository 'https://deb.debian.org/debian bullseye-backports Release' does
not have a Release file.

שורש הבעיה

קהילת Debian הסירה את מאגרי ה-backports מה-upstream הראשי, ולכן אין יותר הפניה אל bullseye-backports Release.

רזולוציה

משתמשים בגרסה debian-11-bullseye-v20250728 של התמונה או בגרסה חדשה יותר. הגרסאות האלה לא מכילות את מאגרי הגיבוי. לחלופין, אפשר לעדכן את המופעים הנוכחיים על ידי שינוי של /etc/apt/sources.list:

  • כדי לעדכן את כתובת ה-URL של המאגר ולהשתמש בארכיון עבור bullseye-backports:

    sudo sed -i 's/^deb https:\/\/deb.debian.org\/debian bullseye-backports main$/deb https:\/\/archive.debian.org\/debian bullseye-backports main/g; s/^deb-src https:\/\/deb.debian.org\/debian bullseye-backports main$/deb-src https:\/\/archive.debian.org\/debian bullseye-backports main/g' /etc/apt/sources.list

  • כדי למחוק את כתובת ה-URL של המאגר ולבטל את bullseye-backports:

    sudo sed -i '/^deb https:\/\/deb.debian.org\/debian bullseye-backports main$/d; /^deb-src https:\/\/deb.debian.org\/debian bullseye-backports main$/d' /etc/apt/sources.list

ubuntu-desktop התקנת חבילה גורמת לניתוק החיבור לרשת כשמפעילים מחדש את המכונה

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

שורש הבעיה

חבילת ubuntu-deskop מושכת את ubuntu-settings כתלות, שמגדירה את NetworkManager כ'רכיב העיבוד' (renderer) שמוגדר כברירת מחדל עבור netplan. במילים אחרות, הוא מוסיף הגדרת YAML חדשה ל-netplan ב-/usr/lib/netplan/00-network-manager-all.yaml שמכילה את ההגדרות הבאות:

network:
  version: 2
  renderer: NetworkManager

ההגדרה הזו מתנגשת עם הקצאת הרשאות מוקדמת שמבוססת על networkd באמצעות cloud-init.

Recovery

אם הפעלתם מחדש את מופע החישוב ואין לכם גישה אליו, צריך לבצע את הפעולות הבאות:

  1. פועלים לפי ההוראות לשחזור מופע של מחשוב.

  2. אחרי שטוענים את מחיצת מערכת הקבצים של Linux במופע Compute שלא ניתן לגשת אליו, מריצים את הפקודה הבאה (מחליפים את /rescue בנקודת הטעינה):

    echo -e 'network:\n  version: 2\n  renderer: networkd' | sudo tee /rescue/etc/netplan/99-gce-renderer.yaml

  3. ממשיכים להפעיל מחדש את מכונת ה-Compute שלא ניתן לגשת אליה.

מכונות וירטואליות ב-Compute Engine שמשתמשות בגרסה v20250530 של מערכת ההפעלה Ubuntu מציגות FQDN שגוי

יכול להיות שיוצג לכם שם דומיין מוגדר במלואו (FQDN) שגוי עם הסיומת .local כשאתם מבצעים אחת מהפעולות הבאות:

  • מעדכנים לגרסה 20250328.00 של חבילת google-compute-engine.
  • הפעלת מכונות וירטואליות מכל קובץ אימג' של Ubuntu שמוצע על ידי Canonical עם סיומת הגרסה v20250530.

לדוגמה, projects/ubuntu-os-cloud/global/images/ubuntu-2204-jammy-v20250530.

אם נתקלתם בבעיה הזו, יכול להיות שיוצג לכם FQDN שדומה לזה:

   [root@ubuntu2204 ~]# apt list --installed | grep google
   ...
   google-compute-engine/noble-updates,now 20250328.00-0ubuntu2~24.04.0 all [installed]
   ...

   [root@ubuntu2204 ~]# curl "http://metadata.google.internal/computeMetadata/v1/instance/image" -H "Metadata-Flavor: Google"
   projects/ubuntu-os-cloud/global/images/ubuntu-2204-jammy-v20250530

   [root@ubuntu2204 ~]# hostname -f
   ubuntu2204.local

שורש הבעיה

בכל תמונות Ubuntu בגרסה v20250530, חבילת guest-config בגרסה 20250328.00 מוסיפה את local לנתיב החיפוש בגלל ההשקה של קובץ תצורה חדש: https://github.com/GoogleCloudPlatform/guest-configs/blob/20250328.00/src/etc/systemd/resolved.conf.d/gce-resolved.conf

   [root@ubuntu2204 ~]# cat /etc/resolv.conf
   # This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
   # Do not edit.
   ...

   nameserver 127.0.0.53
   options edns0 trust-ad
   search local ... google.internal

הנוכחות של הרשומה local בנתיב החיפוש בקובץ /etc/resolv.conf גורמת להוספת רכיב .local לשם המארח כשמתבצעת בקשה ל-FQDN.

שימו לב: בגרסה 20250501 של guest-configs הבעיה כבר תוקנה, אבל Canonical עדיין לא שילבה את התיקון בתמונות שלה.

דרך לעקיפת הבעיה

  1. משנים את קובץ התצורה של Network Name Resolution‏ /etc/systemd/resolved.conf.d/gce-resolved.conf. לשם כך, מחליפים את Domains=local ב-Domains=~local.
  2. מריצים את הפקודה הבאה כדי להפעיל מחדש את שירות systemd-resolved: systemctl restart systemd-resolved
  3. מוודאים ש-local הוסר מנתיב החיפוש ב-/etc/resolv.conf

  4. משתמשים בפקודה hostname -f כדי לוודא מהו ה-FQDN.

    [root@ubuntu2204 ~]# hostname -f
ubuntu2204.us-central1-a.c.my-project.internal

חסרה mkfs.ext4 בתמונות openSUSE

בגרסה האחרונה v20250724 של קובצי אימג' של openSUSE (החל מ-opensuse-leap-15-6-v20250724-x86-64) מאוגוסט 2025 חסרה חבילת e2fsprogs, שמספקת כלי עזר לניהול מערכות קבצים. אחד מהסימפטומים הנפוצים של הבעיה הזו הוא שמופיעה הודעת שגיאה כמו command not found כשמנסים להשתמש בפקודה mkfs.ext4.

דרך לעקיפת הבעיה

אם נתקלים בבעיה הזו, צריך להתקין את החבילה החסרה באופן ידני באמצעות מנהל החבילות של openSUSE, ‏ zypper.

# Update the package index
user@opensuse:~> sudo zypper refresh

# Install the e2fsprogs package
user@opensuse:~> sudo zypper install e2fsprogs

# Verify the installation
user@opensuse:~> which mkfs.ext4

מופעי מחשוב של SUSE Enterprise לא מצליחים לבצע אתחול אחרי שינוי סוגי המכונות

אחרי שמשנים את סוג המכונה של מופע Compute שמופעל בו SUSE Enterprise Linux, יכול להיות שהמופע לא יופעל ותופיע השגיאה הבאה במסוף הטורי:

            Starting [0;1;39mdracut initqueue hook[0m...
   [  136.146065] dracut-initqueue[377]: Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks:
   [  136.164820] dracut-initqueue[377]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2fD3E2-0CEB.sh: "[ -e "/dev/disk/by-uuid/D3E2-0CEB" ]"
   [  136.188732] dracut-initqueue[377]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2fe7b218a9-449d-4477-8200-a7bb61a9ff4d.sh: "if ! grep -q After=remote-fs-pre.target /run/systemd/generator/systemd-cryptsetup@*.service 2>/dev/null; then
   [  136.220738] dracut-initqueue[377]:     [ -e "/dev/disk/by-uuid/e7b218a9-449d-4477-8200-a7bb61a9ff4d" ]
   [  136.240713] dracut-initqueue[377]: fi"

שורש הבעיה

‫SUSE יוצרת את תמונות הענן שלה עם initramfs (מערכת קבצים ראשונית של RAM) רב-תכליתית שתומכת בסוגים שונים של מכונות. כדי לעשות את זה, משתמשים בדגלים --no-hostonly --no-hostonly-cmdline -o multipath במהלך היצירה הראשונית של התמונה. עם זאת, כשמותקן ליבה חדשה או כשמתבצעת יצירה מחדש של initramfs, שמתרחשת במהלך עדכוני מערכת, הדגלים האלה מושמטים כברירת מחדל. כתוצאה מכך, נוצרת תמונה קטנה יותר של initramfs שמותאמת במיוחד לחומרה של המערכת הנוכחית, ויכול להיות שהיא לא כוללת מנהלי התקנים שנדרשים לסוגים אחרים של מופעים.

לדוגמה, מופעי C3 משתמשים בכונני NVMe, שנדרשים מודולים ספציפיים כדי לכלול אותם ב-initramfs. אם מעבירים מערכת עם initramfs שחסרים בה מודולי NVMe כאלה למופע C3, תהליך האתחול נכשל. הבעיה הזו יכולה להשפיע גם על סוגים אחרים של מכונות עם דרישות חומרה ייחודיות.

דרך לעקיפת הבעיה

לפני שמשנים את סוג המכונה, צריך ליצור מחדש את initramfs עם כל הדרייברים:

dracut --force --no-hostonly

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

dracut -f --no-hostonly

ביצועי IOPS נמוכים יותר עבור SSD מקומי ב-Z3 עם תמונות SUSE 12

במכונות וירטואליות מסוג Z3 שמשתמשות בתמונות של SUSE Linux Enterprise Server‏ (SLES) 12, הביצועים של IOPS בדיסקים של SSD מקומיים נמוכים משמעותית מהצפוי.

שורש הבעיה

זו בעיה בבסיס הקוד של SLES 12.

דרך לעקיפת הבעיה

תיקון מ-SUSE לפתרון הבעיה הזו לא זמין או לא מתוכנן. במקום זאת, צריך להשתמש במערכת ההפעלה SLES 15.

מופעי מחשוב של RHEL 7 ו-CentOS מאבדים גישה לרשת אחרי הפעלה מחדש

אם למופעי החישוב שלכם ב-CentOS או ב-RHEL 7 יש כמה כרטיסי ממשק רשת (NIC) ואחד מהם לא משתמש בממשק VirtIO, יכול להיות שתאבדו את הגישה לרשת אחרי הפעלה מחדש. הבעיה הזו מתרחשת כי RHEL לא תומך בהשבתה של שמות צפויים של ממשקי רשת אם לפחות כרטיס רשת אחד לא משתמש בממשק VirtIO.

פתרון

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

  1. עורכים את הקובץ /etc/default/grub ומסירים את פרמטרים של ליבת המערכת net.ifnames=0 ו-biosdevname=0.

  2. יוצרים מחדש את ההגדרה של GRUB.

  3. מפעילים מחדש את מכונת החישוב.

לא ניתן לאמת את החתימה של repomd.xml

במערכות שמבוססות על Red Hat Enterprise Linux ‏ (RHEL) או על CentOS 7, יכול להיות שתופיע השגיאה הבאה כשמנסים להתקין או לעדכן תוכנה באמצעות yum. השגיאה הזו מציינת שמפתח ה-GPG של המאגר לא תקין או שתוקף שלו פג.

יומן לדוגמה: 

[root@centos7 ~]# yum update




...



google-cloud-sdk/signature                                                                  | 1.4 kB  00:00:01 !!!
https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for google-cloud-sdk
Trying other mirror.



...



failure: repodata/repomd.xml from google-cloud-sdk: [Errno 256] No more mirrors to try.
https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for google-cloud-sdk
פתרון

כדי לפתור את הבעיה, צריך להשבית את בדיקת מפתח ה-GPG של המאגר בהגדרת מאגר ה-yum על ידי הגדרת repo_gpgcheck=0. בקבצים בסיסיים נתמכים של Compute Engine, יכול להיות שההגדרה הזו תופיע בקובץ /etc/yum.repos.d/google-cloud.repo. עם זאת, יכול להיות שההגדרה הזו מוגדרת בקובצי תצורה שונים של מאגרים או בכלי אוטומציה שונים של מופע המחשוב.

מאגרי Yum בדרך כלל לא משתמשים במפתחות GPG לאימות המאגר. במקום זאת, נקודת הקצה https מהימנה.

כדי לאתר את ההגדרה הזו ולעדכן אותה, מבצעים את השלבים הבאים:

  1. מחפשים את ההגדרה בקובץ /etc/yum.repos.d/google-cloud.repo.

    cat /etc/yum.repos.d/google-cloud.repo


[google-compute-engine]
name=Google Compute Engine
baseurl=https://packages.cloud.google.com/yum/repos/google-compute-engine-el7-x86_64-stable
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
[google-cloud-sdk]
name=Google Cloud SDK
baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

  2. תשנה את כל השורות שכתוב בהן repo_gpgcheck=1 ל-repo_gpgcheck=0.

    sudo sed -i 's/repo_gpgcheck=1/repo_gpgcheck=0/g' /etc/yum.repos.d/google-cloud.repo

  3. בודקים שההגדרה עודכנה.

    cat /etc/yum.repos.d/google-cloud.repo

[google-compute-engine]
name=Google Compute Engine
baseurl=https://packages.cloud.google.com/yum/repos/google-compute-engine-el7-x86_64-stable
enabled=1
gpgcheck=1
repo_gpgcheck=0
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
[google-cloud-sdk]
name=Google Cloud SDK
baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=0
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

מופעים שמשתמשים ב-OS Login מחזירים הודעת התחברות אחרי החיבור

במקרים מסוימים שבהם נעשה שימוש ב-OS Login, יכול להיות שתקבלו את הודעת השגיאה הבאה אחרי יצירת החיבור:

/usr/bin/id: cannot find name for group ID 123456789

פתרון

מתעלמים מהודעת השגיאה.

בעיות מוכרות במופעי Windows

  • התמיכה ב-NVMe ב-Windows באמצעות מנהל ההתקן של NVMe מהקהילה היא בגרסת בטא, והביצועים עשויים להיות שונים מאלה של מופעי Linux. מנהל ההתקן של NVMe בקהילה הוחלף במנהל ההתקן של Microsoft StorNVMe בתמונות ציבוריות של Google Cloud . מומלץ להחליף את מנהל ההתקן של NVME במופעי Compute שנוצרו לפני מאי 2022 ולהשתמש במנהל ההתקן StorNVMe של מיקרוסופט במקום זאת.
  • אחרי שיוצרים מכונה, אי אפשר להתחבר אליה באופן מיידי. כל מופעי Windows חדשים משתמשים בכלי System preparation (sysprep) כדי להגדיר את המופע, והתהליך הזה יכול להימשך 5-10 דקות.
  • אי אפשר להפעיל תמונות של Windows Server בלי חיבור לרשת אל kms.windows.googlecloud.com, והן מפסיקות לפעול אם הן לא מאומתות תוך 30 יום. תוכנה שהופעלה על ידי KMS צריכה להיות מופעלת מחדש כל 180 ימים, אבל KMS מנסה להפעיל אותה מחדש כל 7 ימים. חשוב להגדיר את מופעי המחשוב של Windows כדי שהם יישארו פעילים.
  • תוכנת ליבה שמקבלת גישה לרישומים ספציפיים למודל שלא עברו אמולציה תגרום לשגיאות הגנה כלליות, שיכולות לגרום לקריסת המערכת, בהתאם למערכת ההפעלה של האורח.
  • מנהל ההתקן vioscsi, שמשמש לדיסקים מסוג SCSI, מגדיר את הדגל removable, וכתוצאה מכך הדיסקים נחשבים לאחסון נשלף. הדבר גורם להגבלות גישה לא צפויות ב-Windows לדיסקים שחלים עליהם אובייקטים של מדיניות קבוצתית (GPO) שמיועדים לאחסון נשלף.

הפעלת סוכן אורח נכשלה

גרסה 20251011.00 של סוכן האורח של Windows לא מצליחה להתחיל לפעול בתנאי עומס מסוימים.

הגורם הבסיסי האריזה של סוכן האורח של Windows לגרסה 20251011.00 מגדירה באופן שגוי את מצב ההתחלה של סוכן האורח של Windows ל-auto ב-Windows Service Manager.

פתרון כדי לפתור את הבעיה, צריך לעדכן את המופע לשימוש בגרסה 20251120.01 ואילך של guest agent.

פתרון עקיף ידני אם אי אפשר להתקין את גרסה 20251120.01, מריצים את הפקודה הבאה:

  • sc.exe config GCEAgent start=delayed-auto

יכול להיות שתכונות לניהול פרטי הכניסה לא יפעלו במופעי Windows שבהם נעשה שימוש בשמות בשפה שאינה אנגלית

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

מערכת Windows Server 2016 לא תופעל בסוגי מכונות C3D עם 180 או יותר vCPU

מערכת Windows Server 2016 לא תופעל בסוגי מכונות C3D עם 180 או 360 vCPU. כדי לעקוף את הבעיה, בוחרים אחת מהאפשרויות הבאות:

  • אם אתם צריכים להשתמש ב-Windows Server 2016, אתם צריכים להשתמש בסוג מכונה עם פחות מ-180 vCPU.
  • אם אתם צריכים להשתמש בסוג מכונה C3D עם 180 או 360 מעבדים וירטואליים, אתם צריכים להשתמש בגרסה מאוחרת יותר של Windows Server.

‫Windows Server 2025 ו-Windows 11 24h2/25h2 – תמיכה בהשהיה ובהפעלה מחדש

אי אפשר להפעיל מחדש את Windows Server 2025,‏ Windows 11 24h2 ו-Windows 11 25h2 אחרי שהם מושהים. עד שהבעיה תיפתר, לא תהיה תמיכה בתכונת ההשהיה וההפעלה מחדש ב-Windows Server 2025, ב-Windows 11 24h2 וב-Windows 11 25h2.

שגיאות במדידת סחיפת זמן NTP באמצעות w32tm במופעי Windows

במקרים של מכונות וירטואליות של Windows ב-Compute Engine שמשתמשות בממשק רשת של VirtIO, יש באג מוכר שגורם לשגיאות במדידת סחיפת NTP כשמשתמשים בפקודה הבאה:

w32tm /stripchart /computer:metadata.google.internal

השגיאות ייראו כך:

Tracking metadata.google.internal [169.254.169.254:123].
The current time is 11/6/2023 6:52:20 PM.
18:52:20, d:+00.0007693s o:+00.0000285s  [                  *                  ]
18:52:22, error: 0x80072733
18:52:24, d:+00.0003550s o:-00.0000754s  [                  *                  ]
18:52:26, error: 0x80072733
18:52:28, d:+00.0003728s o:-00.0000696s  [                  *                  ]
18:52:30, error: 0x80072733
18:52:32, error: 0x80072733

הבאג הזה משפיע רק על מכונות Compute Engine עם כרטיסי רשת של VirtIO. במקרים של מופעי Compute שמשתמשים בממשקי רשת gVNIC, הבעיה הזו לא מתרחשת.

כדי להימנע מהבעיה הזו, Google ממליצה להשתמש בכלים אחרים למדידת סחיפה של NTP, כמו Meinberg Time Server Monitor.

מכשיר אתחול שלא ניתן לגשת אליו אחרי עדכון מכונת Compute מדור 1 או 2 למכונה מדור 3 או מאוחר יותר

מערכת Windows Server קושרת את כונן האתחול לסוג ממשק הדיסק הראשוני שלו עם ההפעלה הראשונה. כדי לשנות מכונת חישוב קיימת מסדרת מכונות ישנה יותר (דור 1 או 2) שמשתמשת בממשק דיסק SCSI לסדרת מכונות חדשה יותר (דור 3 או מאוחר יותר) שמשתמשת בממשק דיסק NVMe, צריך לבצע sysprep של מנהל התקן Windows PnP לפני שמכבים את מכונת החישוב. ה-sysprep הזה רק מכין את מנהלי ההתקנים של המכשיר ומוודא שכל סוגי ממשקי הדיסק נסרקים כדי למצוא את כונן האתחול בהפעלה הבאה.

בפרומפט של Powershell, בתור Administrator, מריצים את הפקודה:

PS C:\> start rundll32.exe sppnp.dll,Sysprep_Generalize_Pnp -wait

כדי לשנות את סדרת המכונות של מופע Compute:

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

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

מספר מוגבל של דיסקים לצירוף לסדרות מכונות שמשתמשות בדיסקים מסוג NVMe

למכונות Compute שמשתמשות בממשק הדיסק NVMe ובתמונה של מערכת הפעלה Microsoft Windows יש מגבלה של 16 דיסקים לחיבור דיסקים לסדרות מכונות ספציפיות. המגבלה הזו חלה על סדרות המכונות N4,‏ C3,‏ C3D ו-M3.

סדרות מכונות כמו C4,‏ C4D,‏ N4D ו-M4 תומכות ביותר מ-16 דיסקים כשמשתמשים במנהל התקנים תואם של NVMe, כמו מנהל ההתקנים StorNVMe של מיקרוסופט.

המגבלה הזו לא חלה על אחסון SSD מקומי. כדי להימנע משגיאות, צריך לאחד את האחסון של Persistent Disk ו-Hyperdisk למקסימום של 16 דיסקים לכל מכונת חישוב בסדרות המכונות המושפעות.

החלפת מנהל ההתקן של NVME במופעי מחשוב שנוצרו לפני מאי 2022

אם רוצים להשתמש ב-NVMe במופע Compute שמשתמש ב-Microsoft Windows, והמופע נוצר לפני 1 במאי 2022, צריך לעדכן את מנהל ההתקן הקיים של NVMe במערכת ההפעלה של האורח כדי להשתמש במנהל ההתקן Microsoft StorNVMe.

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

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

googet update
googet install google-compute-engine-driver-nvme

ביצועים נמוכים יותר של דיסקים מקומיים מסוג SSD במופעי C3 ו-C3D שמופעלים ב-Microsoft Windows

הביצועים של SSD מקומי מוגבלים במופעי C3 ו-C3D שמופעלים ב-Microsoft Windows.

אנחנו עובדים על שיפור הביצועים.

ביצועים נמוכים יותר של נפחי Hyperdisk Extreme שמצורפים למופעי n2-standard-80 שמופעלים ב-Microsoft Windows

מכונות Compute שמבוססות על סוג המכונה n2-standard-80 שמריצות Microsoft Windows יכולות להגיע ל-80,000 IOPS לכל היותר בכל נפחי Hyperdisk Extreme שמצורפים למכונה.

פתרון

כדי להגיע ל-160,000 IOPS עם מופעי N2 שמריצים Windows, בוחרים אחד מסוגי המכונות הבאים:

  • n2-highmem-80
  • n2-highcpu-80
  • n2-standard-96
  • n2-highmem-96
  • n2-highcpu-96
  • n2-highmem-128
  • n2-standard-128

תפוקת רשת נמוכה כשמשתמשים ב-gVNIC

יכול להיות שיהיו בעיות ברוחב הפס של הרשת במכונות וירטואליות של Windows Server 2022 ו-Windows 11 שמשתמשות במנהל התקן gVNIC בגרסה 1.0.0@44 או בגרסאות קודמות של חבילת GooGet, כשמשתמשים בכרטיס רשת וירטואלי של Google‏ (gVNIC).

כדי לפתור את הבעיה, צריך לעדכן את חבילת gVNIC driver GooGet לגרסה 1.0.0@45 ואילך. לשם כך:

  1. כדי לבדוק איזו גרסת מנהל התקן מותקנת במופע שלכם ב-Compute, מריצים את הפקודה הבאה ממנהל מערכת של Command Prompt או הפעלה של Powershell:

    googet installed

    הפלט אמור להיראות כך:

    Installed packages:
  ...
  google-compute-engine-driver-gvnic.x86_64 VERSION_NUMBER
  ...

  2. אם גרסת הדרייבר של google-compute-engine-driver-gvnic.x86_64 היא 1.0.0@44 או גרסה קודמת, צריך לעדכן את מאגר החבילות של GooGet על ידי הרצת הפקודה הבאה ממסוף פקודות של אדמין או מסשן של Powershell:

    googet update

סוגי מכונות גדולים מסוג C4,‏ C4D ו-C3D vCPU לא תומכים בתמונות של מערכת ההפעלה Windows

סוגי מכונות C4 עם יותר מ-144 vCPU וסוגי מכונות C4D ו-C3D עם יותר מ-180 vCPU לא תומכים בתמונות של מערכות הפעלה Windows Server 2012 ו-2016. מכונות גדולות יותר מסוג C4,‏ C4D ו-C3D שמשתמשות בתמונות של מערכת ההפעלה Windows Server 2012 ו-2016 לא יצליחו לבצע אתחול. כדי לעקוף את הבעיה הזו, בוחרים סוג מכונה קטן יותר או משתמשים בתמונה של מערכת הפעלה אחרת.

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

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

שגיאת דיסק כללית ב-Windows Server 2016 וב-2012 R2 עבור מופעים מסוג M3,‏ C3,‏ C3D ו-C4D

בשלב הזה, אי אפשר להוסיף או לשנות את הגודל של Hyperdisk או Persistent Disk עבור מופע M3, ‏ C3, ‏ C3D או C4D פעיל במכונות אורחות ספציפיות של Windows. ‫Windows Server 2012 R2 ו-Windows Server 2016,‏ ותמונות הלקוח התואמות שלהם ב-Windows, לא מגיבים בצורה נכונה לפקודות הצירוף של הדיסק והשינוי של גודל הדיסק.

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

פתרון

אם אתם משתמשים במופעי M3,‏ C3,‏ C3D או C4D שפועלים במערכת ההפעלה Windows ואתם משנים נפח Hyperdisk או Persistent Disk, אתם צריכים להפעיל מחדש את מופע Compute כדי שהשינויים בדיסק יזוהו.