בעיות מוכרות

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

בעיות כלליות

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

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

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

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

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

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

רזולוציה

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

יכול להיות שדיסקים מסוג 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).

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

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

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

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

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

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

שגיאות אפשריות במארח במהלך יצירת מכונה מסוג C4 בצמתים של דייר יחיד (sole-tenant)

במכונות מסוג C4 שפועלות בשרתים לדייר יחיד (sole-tenant), יכול להיות שהמכונות יפסיקו לפעול באופן לא צפוי בגלל שגיאות במארח או בגלל כשלים ביצירת המכונות.

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

הקונסולה הטורית היא לקריאה בלבד במכונות פיזיות מסוג 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 של צומת הבקר הראשי, נכנסים לדף VM instances במסוף Google Cloud .

    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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • -temp
  • -old
  • -new

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

זמן אחזור ארוך יותר בחלק מהדיסקים של האחסון המתמיד (persistent disks) בגלל שינוי גודל הדיסק

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

יכול להיות שהתהליכים האוטומטיים ייכשלו אם הם משתמשים בנתוני התגובה מה-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. התהליך האוטומטי לא יכול לצרוך את הערך שמוחזר על ידי ה-method של ה-API, ולכן הוא נכשל.

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

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

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

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

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

בקטע הבא מתוארות הבעיות המוכרות במכונות GPU של Compute Engine.

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

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

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

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

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

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

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

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

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

בעיות מוכרות במכונות ללא מערכת הפעלה (bare metal)

אלה הבעיות המוכרות במכונות ללא מערכת הפעלה של Compute Engine.

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

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

פתרון עקיף

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

במאמר עצירה או הפעלה מחדש של מכונה ב-Compute Engine מוסבר איך עוצרים או מפעילים מחדש מכונה מסוג X4.

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

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

פתרון עקיף

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

אי אפשר לדמות תחזוקה של מארח במכונות C4 ללא מערכת הפעלה (bare metal)

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

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

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

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

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

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

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

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

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

שורש הבעיה

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

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

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

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

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

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

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

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

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

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

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

שורש הבעיה

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

רזולוציה

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

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

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

יירוט חבילות יכול לגרום לאובדן חבילות בגלל תגי VLAN חסרים בכותרות ה-Ethernet

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

שורש הבעיה

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

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

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

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

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

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

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

אלה הבעיות המוכרות במכונות Linux.

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

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

[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 Optimized שנוצרו בדצמבר 2025 (לדוגמה, rocky-linux-9-optimized-gcp-nvidia-latest-v20251215) כבר כוללות את החבילה המעודכנת doca-repo, כך שבעיית השדרוג הזו לא קיימת בגרסאות האלה או בגרסאות מאוחרות יותר.

אי אפשר להשתמש ב-OS Login ב-SLES 16

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

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

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

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

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

מכונות וירטואליות שמשתמשות בתמונות של Debian 11 בגרסאות שקדמו ל-v20250728 לא מצליחות להריץ את apt update

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

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

שורש הבעיה

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

רזולוציה

צריך להשתמש בגרסת תמונה debian-11-bullseye-v20250728 או בגרסה חדשה יותר. הגרסאות האלה לא מכילות את מאגרי הנתונים של היסב בגרסאות מוקדמות יותר (backporting). לחלופין, אפשר לעדכן מכונות קיימות על ידי שינוי של /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 במכונה הלא נגישה, הריצו את הפקודה הבאה (החליפו את /rescue בנקודת הטעינה שלכם):

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

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

במכונות שמשתמשות בגרסה 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, גרסה 20250328.00 של החבילה guest-config מוסיפה את 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. מאשרים את ה-FQDN באמצעות הפקודה hostname -f

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

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

בגרסה האחרונה של קובצי האימג' של openSUSE ב-v20250724 (החל מ-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 לא מצליחות לבצע אתחול אחרי שינוי סוגי המכונות

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

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

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

dracut --force --no-hostonly

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

dracut -f --no-hostonly

ביצועי IOPS נמוכים יותר ב-SSD מקומי ב-Z3 עם קובצי אימג' של SUSE 12

במכונות Z3 שמשתמשות בתמונות של SUSE Linux Enterprise Server (SLES) 12, הביצועים של IOPS בדיסקים מסוג Local 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 לאימות המאגר. במקום זאת, נקודת הקצה (endpoint) 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 ימים. חשוב לוודא שהמכונות הווירטואליות ב-Google Compute Engine שמריצות Windows מוגדרות כך שהן יישארו מופעלות.
  • תוכנת ליבה שניגשת לאוגרים ספציפיים למודל שלא עברו אמולציה, תגרום לשגיאות הגנה כלליות שעלולות לגרום לקריסת המערכת, בהתאם למערכת ההפעלה של האורח.
  • מנהל ההתקן vioscsi, שמשמש לדיסקים של SCSI, מגדיר את הדגל removable, וכתוצאה מכך המערכת מתייחסת לדיסקים כאל אחסון נשלף. זה גורם להגבלות גישה לא צפויות ב-Windows לדיסקים שכפופים לאובייקטים של מדיניות קבוצתית (GPO) שמטרגטים אחסון נשלף.

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

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

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

פתרון עקיף

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

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

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

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

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

סוכן האורח לא מתחיל לפעול

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

רזולוציה

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