בעיות מוכרות

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

בעיות כלליות

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

סוכן האורח מתעלם מהאפשרות 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 מקומי, מופעל מחדש מופע של Compute שפועל בשרת המארח הזה עם כל הדיסקים שמצורפים אליו, והנתונים כוללים את כל הפעולות שבוצעו לפני השגיאה במארח.

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

הקיבולת של 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. אי אפשר ליצור דיסקים נוספים אחרי שמגיעים למגבלה של דיסקים של אחסון מתמיד (persistent disks), גם אם נותרה מכסת Hyperdisk זמינה.

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

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

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

  • זמן הפעולה הרציפה של ה-VM ‏ (lastStartTimestamp) חורג מ-65 ימים.
  • ביומנים מוצגת הודעה Xid 149 עם תיוג של 0x02a.

אם אחד מהתנאים האלה מתקיים, צריך לאפס את יחידות ה-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 מציג הודעת שגיאה גם אם העדכון הצליח.

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

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

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

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

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

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

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

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

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

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

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

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

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

  • הבקשה למקום שמור לעתיד נוצרת בהצלחה. אבל אם תשלחו את הבקשה לבדיקה, 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, נדרש רק דיסק אחד. אם מספר הדיסק לא תואם, תקבלו שגיאת הגדרה שגויה של SSD מקומי ממישור הבקרה של Compute Engine. כדי לבחור את המספר הנכון של דיסקים מקומיים מסוג SSD בהתאם לסוג המכונה lssd, אפשר לעיין במאמר בנושא סוגי מכונות שמצורפים אליהם באופן אוטומטי דיסקים מקומיים מסוג SSD.

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

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

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

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

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

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

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

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

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

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

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

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

  • -temp
  • -old
  • -new

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

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

במקרים מסוימים, שינוי הגודל של דיסקים גדולים וקבועים (בגודל של ‎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

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

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

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

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

הבעיות האלה מתרחשות כי ההגדרה של NIC דינמי מובילה לשגיאות כש-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

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

פתרון עקיף

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

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

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

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

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

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

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

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

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

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

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

שורש הבעיה

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

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

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

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

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

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

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

מכיוון שהנתיבים המקומיים לא מתווספים ל-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.

בעיות בהתקנה ובניהול של כרטיסי NIC דינמיים בגרסאות של סוכן האורח 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

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

שורש הבעיה

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

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

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

  • Authenticated 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 כ'מעבד' ברירת המחדל עבור 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 שמשתמשים בגרסה 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‏ (NNR) /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. מאשרים את ה-FQDN באמצעות הפקודה hostname -f

    [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 נמוכים יותר עבור Local 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 במופעי מחשוב שנוצרו לפני מאי 2022 ולהשתמש במנהל ההתקן של Microsoft StorNVMe במקום זאת.
  • אחרי שיוצרים מכונה, אי אפשר להתחבר אליה באופן מיידי. כל מופעי Windows חדשים משתמשים בכלי System preparation (sysprep) כדי להגדיר את המופע, והתהליך הזה יכול להימשך 5-10 דקות.
  • אי אפשר להפעיל תמונות של Windows Server בלי חיבור לרשת אל kms.windows.googlecloud.com, והן מפסיקות לפעול אם הן לא עוברות אימות ראשוני תוך 30 יום. תוכנה שהופעלה באמצעות KMS צריכה להיות מופעלת מחדש כל 180 יום, אבל KMS מנסה להפעיל אותה מחדש כל 7 ימים. חשוב להגדיר את מופעי המחשוב של Windows כדי שהם יישארו פעילים.
  • תוכנת ליבה שניגשת לרגיסטרים ספציפיים למודל שלא עברו אמולציה תגרום לשגיאות הגנה כלליות, שיכולות לגרום לקריסת המערכת בהתאם למערכת ההפעלה של האורח.
  • מנהל ההתקן vioscsi, שמשמש לדיסקים מסוג SCSI, מגדיר את הדגל removable, וכתוצאה מכך הדיסקים מטופלים כאחסון נשלף. הדבר גורם להגבלות גישה לא צפויות ב-Windows לדיסקים שחלים עליהם אובייקטים של מדיניות קבוצתית (GPO) שמיועדים לאחסון נשלף.

סוכן האורח לא מופעל ב-Windows Server 2012 R2 ובגרסאות קודמות

אחרי עדכון חבילות של סוכן אורח במופעים שמריצים מערכות הפעלה מדור קודם של Windows (כמו Windows Server 2012 R2,‏ Windows Server 2012 או Windows Server 2008 R2). אם מריצים את הקובץ הבינארי באופן ידני, מקבלים שגיאה שמציינת שהקובץ הבינארי לא מזוהה.

התמיכה ב-Windows Server 2012 R2 ובגרסאות קודמות הוסרה מ-Go (Golang) החל מ-Go 1.21. אי אפשר להפעיל במערכות ההפעלה האלה גרסאות של סוכן אורח שנבנו באמצעות Go 1.21 או גרסה מתקדמת יותר.

פתרון עקיף

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

  • שדרוג מערכת ההפעלה: שדרוג המכונה הווירטואלית לגרסה נתמכת, כמו Windows Server 2016 ואילך. מידע נוסף זמין במאמר בנושא סיום התמיכה ב-Windows.

  • חזרה לגרסה קודמת של סוכן אורח: אם אתם חייבים להמשיך להריץ את Windows Server 2012 R2 או גרסה קודמת, אתם יכולים להתקין מחדש חבילות תואמות של סוכן אורח ממופע פעיל אחר של Compute או מתמונת מצב:

    1. במכונת המחשוב הפעילה, בודקים את הגרסה של חבילות google-compute-engine-windows ו-google-compute-engine-metadata-scripts.
    2. עוברים אל Googet ספריית המטמון C:\ProgramData\Googet\cache\` and copy the של קובצי ה-‎.goo` של החבילות שלמעלה אל המכונה הווירטואלית הפגומה.
    3. במכונה הווירטואלית הפגומה, מתקינים את החבילות שהועתקו אחת-אחת באמצעות googet install -reinstall PACKAGE_NAME.goo.

  • כדי למנוע מהסוכן האורח להתעדכן לגרסה לא תואמת, צריך להשבית את העדכון האוטומטי של הסוכן האורח.

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

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

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

פתרון כדי לפתור את הבעיה, צריך לעדכן את המופע לשימוש בגרסה 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 מעבדים וירטואליים. כדי לעקוף את הבעיה, אפשר לבחור באחת מהאפשרויות הבאות:

  • אם אתם צריכים להשתמש ב-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.

מכונת אתחול לא נגישה אחרי עדכון מכונת חישוב מדור 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 ובחבילת GooGet בגרסה 1.0.0@44 או בגרסה מוקדמת יותר, כשמשתמשים בכרטיס רשת וירטואלי של Google‏ (gVNIC).

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

  1. כדי לבדוק איזו גרסת מנהל התקן מותקנת במכונת החישוב, מריצים את הפקודה הבאה מתוך חלון של שורת פקודה או 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 כדי שהשינויים בדיסק יזוהו.