בעיות מוכרות

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

בעיות כלליות

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

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

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

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

כדי לפתור את הבעיה, צריך לאפס את המעבדים הגרפיים. כדי למנוע את הבעיה, צריך לאפס את יחידות העיבוד הגרפי (GPU) במופעי A4 לפחות פעם ב-60 יום.

שגיאות אפשריות של מארחים במהלך יצירת מופע 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.

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

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

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

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

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

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

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

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

זמן האחזור של חלק מהדיסקים של אחסון מתמיד (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

אי אפשר להפעיל במקרים של 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.

רמת ביצועים נמוכה מהצפוי עם מופעי Z3 bare metal ב-RHEL 8

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

שורש הבעיה

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

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

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

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

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

מנות שנפסלו כשמשתמשים בכרטיסי NIC דינמיים עם טווחי כתובות 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.

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

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

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

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

הפקודה dnf update נכשלת בתמונות של Rocky Linux Accelerator Optimized בגרסה v20251113 או בגרסאות קודמות (לדוגמה, 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 של guest agent, אחזור של סקריפט לטעינה בזמן ההפעלה באמצעות מפתח המטא-נתונים 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 כ'מעבד' ברירת המחדל עבור 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.

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

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

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

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

סדרות מכונות כמו C4,‏ C4D,‏ N4D ו-M4 תומכות ביותר מ-16 דיסקים כשמשתמשים במנהל התקן תואם של NVMe, כמו מנהל ההתקן Microsoft 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,0�0 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. כדי לבדוק איזו גרסת מנהל התקן מותקנת במכונת החישוב, מריצים את הפקודה הבאה מתוך חלון של שורת פקודה או 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 וב-Windows Server 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 כדי שהשינויים בדיסק יזוהו.