בעיות מוכרות

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

בעיות כלליות

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

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

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

במכונות מסוג C4A,‏ C4D,‏ C4 ו-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 disks), גם אם נותרה מכסת Hyperdisk זמינה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שימוש במסוף Google Kubernetes Engine Google Cloud כדי ליצור אשכול או מאגר צמתים עם מכונות וירטואליות מסוג c4-standard-*-lssd, c4-highmem-*-lssd, c3-standard-*-lssd ו-c3d-standard-*-lssd גורם לכשל ביצירת צמתים או לכשל בזיהוי של כונני SSD מקומיים כאחסון זמני.

שונות ברוחב הפס של TCP של זרימה יחידה במכונות וירטואליות מסוג C3D

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

מדד הניצול של ה-CPU לא נכון במכונות וירטואליות שמשתמשות בשרשור אחד לכל ליבה

אם המעבד של המכונה הווירטואלית משתמש בשרשור אחד לכל ליבה, מדד הניצול של המעבד ב-Cloud Monitoring, בכרטיסייה Compute Engine > מכונות וירטואליות > יכולת צפייה, מגיע רק ל-50%. שני תהליכים לכל ליבה הם ברירת המחדל לכל סוגי המכונות, למעט Tau T2D. מידע נוסף זמין במאמר בנושא הגדרת מספר השרשורים לכל ליבה.

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

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

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

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

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

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

  • -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

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

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

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

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

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

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

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

‫C4D bare metal לא תומך בתמונות של SUSE Linux 15 SP6

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

פתרון אפשרי

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

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

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

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

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

שורש הבעיה

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

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

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

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

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

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

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

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

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

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

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

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

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

שורש הבעיה

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

רזולוציה

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

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

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

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

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

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

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

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

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

שורש הבעיה

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

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

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

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

מכונות וירטואליות של Ubuntu שמשתמשות בגרסה v20250530 של תמונת מערכת ההפעלה מציגות 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 לא מצליחות לבצע אתחול אחרי שינוי סוגי המופעים

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

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

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

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

dracut --force --no-hostonly

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

הפתרון

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

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

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

  3. מפעילים מחדש את ה-VM.

לא ניתן היה לאמת את החתימה של 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 ולהשתמש במנהל ההתקן 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 או יותר vCPU שמצורפים (c3d-standard-180 או c3d-standard-360) או יותר. כדי לעקוף את הבעיה, אפשר לבחור באחת מהאפשרויות הבאות:

  • אם אתם צריכים להשתמש ב-Windows Server 2016, השתמשו במכונת C3D קטנה יותר.
  • אם אתם צריכים להשתמש בסוגי המכונות c3d-standard-180 או c3d-standard-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. במכונות וירטואליות שמשתמשות ב-gVNIC, הבעיה הזו לא מתרחשת.

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

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

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

כדי לעדכן את סדרת המכונות של מכונה וירטואלית:

מתוך הנחיית Powershell בתור Administrator מריצים את הפקודה:

PS C:\> start rundll32.exe sppnp.dll,Sysprep_Generalize_Pnp -wait
  1. מפסיקים את ה-VM.
  2. משנים את המכונה הווירטואלית לסוג המכונה הווירטואלית החדש.
  3. מפעילים את ה-VM.

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

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

למכונות וירטואליות שפועלות ב-Microsoft Windows עם ממשק הדיסק NVMe, כולל T2A וכל המכונות הווירטואליות מהדור השלישי, יש מגבלה של 16 דיסקים לחיבור. המגבלה הזו לא חלה על מכונות וירטואליות מהדור הרביעי (C4, ‏ M4). כדי להימנע משגיאות, מומלץ לאחד את נפח האחסון של דיסקים מתמידים (Persistent Disk) ושל Hyperdisk ל-16 דיסקים לכל מכונה וירטואלית לכל היותר. הבעיה הזו לא חלה על אחסון SSD מקומי.

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

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

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

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

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

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

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

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

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

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

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

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

הפתרון

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