Masalah umum

Halaman ini menjelaskan masalah umum yang mungkin Anda alami saat menggunakan instance Compute Engine. Untuk masalah yang secara khusus memengaruhi Confidential VM, lihat Batasan Confidential VM.

Masalah umum

Masalah berikut memberikan panduan pemecahan masalah atau informasi umum.

Agen tamu mengabaikan opsi ip_forwarding dalam konfigurasi NetworkInterfaces

Bagian konfigurasi NetworkInterfaces agen tamu menyertakan opsi ip_forwarding. Anda dapat menggunakan opsi ini untuk mencegah agen menginstal alamat IP alias dan rute penerusan IP dari server metadata (MDS). Namun, untuk versi agen tamu yang menggunakan arsitektur berbasis plugin, yang mencakup plugin inti, agen akan mengabaikan opsi konfigurasi ip_forwarding. Agen tamu menginstal alamat IP alias dan rute penerusan IP, terlepas dari konfigurasinya. Untuk mengetahui informasi selengkapnya, lihat dokumentasi agen tamu. Masalah ini akan memengaruhi Anda jika Anda menggunakan pacemaker SAP Netweaver dalam penyiapan dengan load balancer internal (ILB).

Untuk mengurangi masalah ini, tetapkan atribut metadata enable-guest-agent-core-plugin ke false seperti yang dijelaskan dalam dokumentasi kompatibilitas mundur.

Instance komputasi dengan Booting Aman diaktifkan mungkin gagal melakukan booting

Dalam kasus yang jarang terjadi, instance Shielded VM yang dibuat sebelum 7 November 2025 dengan Booting Aman diaktifkan, atau yang menggunakan software enkripsi disk penuh atau penyegelan rahasia ke PCR vTPM, mungkin gagal melakukan booting. Hal ini mungkin disebabkan oleh urutan update yang salah (misalnya, mengupdate shim tanpa memiliki sertifikat yang tepat) setelah sertifikat Booting Aman Microsoft habis masa berlakunya pada paruh kedua tahun 2026.

Resolusi

Untuk mengatasi masalah ini, perbarui instance komputasi Anda dengan sertifikat baru. Untuk mengetahui informasi selengkapnya, lihat panduan masa berlaku sertifikat Booting Aman Microsoft.

Disk SSD Lokal yang terpasang ke instance C4, C4A, C4D, C4N, dan H4D mungkin tidak mencatat semua penulisan jika terjadi pemadaman listrik

Setelah terjadi pemadaman listrik pada server host, jika Compute Engine dapat memulihkan data pada disk SSD Lokal, instance komputasi yang berjalan di server host tersebut akan dimulai ulang dengan semua disk terpasang, dan data tersebut mencakup semua penulisan yang telah diselesaikan sebelum error host.

Untuk instance C4, C4A, C4D, C4N, dan H4D, disk SSD Lokal yang dipulihkan mungkin tidak menyertakan penulisan yang diselesaikan segera sebelum peristiwa pemadaman listrik. Saat instance komputasi dimulai ulang, pembacaan dari alamat blok logis (LBA) yang terpengaruh akan menampilkan error yang menunjukkan bahwa LBA tidak dapat dibaca. Jika instance komputasi Anda mengalami reboot yang tidak terduga, periksa log error OS untuk mengetahui kegagalan baca atau tulis setelah instance komputasi dimulai ulang.

Kapasitas Hyperdisk Throughput dan Hyperdisk Extreme menggunakan kuota Persistent Disk secara bersamaan

Saat Anda membuat disk Hyperdisk Throughput atau Hyperdisk Extreme, kapasitas disk dihitung terhadap dua kuota terpisah secara bersamaan: kuota Hyperdisk tertentu dan kuota Persistent Disk yang sesuai.

  • Hyperdisk Throughput Capacity (GB) (HDT-TOTAL-GB) juga mengurangi kuota Persistent disk standard (GB) (DISKS-TOTAL-GB) Anda.
  • Hyperdisk Extreme Capacity (GB) (HDX-TOTAL-GB) juga mengurangi kuota Persistent disk SSD (GB) (SSD-TOTAL-GB) Anda.

Jika batas kuota Persistent Disk lebih rendah daripada batas kuota Hyperdisk, Anda akan mengalami error QUOTA_EXCEEDED. Anda tidak dapat membuat disk tambahan setelah batas Persistent Disk tercapai, meskipun Anda masih memiliki sisa kuota Hyperdisk.

Untuk mengurangi masalah ini, Anda harus menyesuaikan kedua kuota setiap kali meminta peningkatan. Saat menyesuaikan kuota HDT-TOTAL-GB atau HDX-TOTAL-GB, Anda juga harus menyesuaikan kuota DISKS-TOTAL-GB atau SSD-TOTAL-GB.

Gangguan workload pada instance A4 karena masalah firmware untuk GPU NVIDIA B200

NVIDIA telah mengidentifikasi dua masalah firmware untuk GPU B200, yang digunakan oleh instance A4. Masalah ini dapat menyebabkan gangguan workload, seperti perintah nvidia-smi yang tidak merespons. Jika Anda melihat gangguan workload pada VM A4, pastikan salah satu kondisi berikut terpenuhi:

Jika salah satu kondisi ini terpenuhi, Anda harus mereset GPU yang terpasang ke VM A4 Anda. Untuk mencegah gangguan pada workload Anda di masa mendatang karena masalah firmware, sebaiknya reset GPU Anda setidaknya sekali setiap 60 hari. Untuk mengetahui informasi selengkapnya, lihat Mereset GPU.

Kemungkinan error host selama pembuatan instance C4 di sole-tenant node

Instance jenis mesin C4 yang berjalan di sole-tenant node mungkin mengalami penghentian instance yang tidak terduga karena error host atau kegagalan pembuatan instance.

Untuk mengatasi masalah ini, Google telah membatasi jumlah maksimum instance C4 yang diizinkan per sole-tenant node menjadi 20.

Konsol serial bersifat hanya baca untuk instance bare metal C4 dan C4D

Anda tidak dapat mengaktifkan akses interaktif ke serial console untuk instance bare metal C4 atau C4D; serial console bersifat hanya baca.

Solusi

Untuk menjalankan perintah secara interaktif, Anda dapat terhubung ke instance menggunakan SSH setelah instance dimulai. Untuk mengetahui informasi tentang cara menggunakan SSH dengan instance Compute Engine, lihat Tentang koneksi SSH.

Membatalkan tugas di cluster HPC 32 node atau yang lebih besar melebihi waktu tunggu

Untuk tugas besar pada cluster dengan 32 node atau lebih, waktu yang diperlukan untuk membatalkan tugas dapat melebihi nilai UnkillableStepTimeout default, yaitu 300 detik. Melebihi nilai ini akan menyebabkan node yang terpengaruh tidak dapat digunakan untuk tugas mendatang.

Untuk mengatasi masalah ini, gunakan salah satu metode berikut:

  • Update Cluster Toolkit ke rilis 1.65.0 atau yang lebih baru. Kemudian, deploy ulang cluster menggunakan perintah berikut:

    gcluster deploy -w --force BLUEPRINT_NAME.yaml

  • Jika Anda tidak dapat mengupdate Cluster Toolkit atau men-deploy ulang cluster, Anda dapat mengubah parameter UnkillableStepTimeout secara manual dengan menyelesaikan langkah-langkah berikut:

    1. Gunakan SSH untuk terhubung ke node pengontrol utama cluster Anda.

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

      Anda dapat menemukan nama dan alamat IP yang tepat untuk node pengontrol utama menggunakan konsol Google Cloud dan membuka halaman VM instances.

    2. Buat cadangan file cloud.conf saat ini. File ini biasanya berada di /etc/slurm/.

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

    3. Dengan menggunakan hak istimewa sudo, gunakan editor teks untuk membuka file /etc/slurm/cloud.conf.

    4. Tambahkan atau ubah baris yang berisi UnkillableStepTimeout. Misalnya, tetapkan waktu tunggu ke 900 detik (15 menit) sebagai berikut:

      UnkillableStepTimeout=900

    5. Simpan file.

    6. Gunakan perintah sudo scontrol reconfigure untuk menerapkan setelan baru di seluruh cluster tanpa perlu memulai ulang sepenuhnya.

Memverifikasi perbaikan

Anda dapat memverifikasi bahwa setelan telah berubah dengan menjalankan perintah berikut:

   scontrol show config | grep UnkillableStepTimeout

Output akan mencerminkan nilai baru yang Anda tetapkan, misalnya: UnkillableStepTimeout = 900.

Terselesaikan: Mengubah IOPS atau throughput pada disk utama Replikasi Asinkron menggunakan perintah gcloud compute disks update menyebabkan error palsu

Masalah berikut telah diselesaikan pada 1 Juni 2025.

Saat Anda menggunakan perintah gcloud compute disks update untuk mengubah IOPS dan throughput pada disk utama Replikasi Asinkron, gcloud CLI akan menampilkan pesan error meskipun update berhasil.

Untuk memverifikasi secara akurat bahwa update berhasil, periksa properti disk menggunakan gcloud CLI atau konsol Google Cloud untuk melihat nilai IOPS dan throughput baru. Untuk mengetahui informasi selengkapnya, lihat Melihat setelan performa yang disediakan untuk Hyperdisk.

Server metadata mungkin menampilkan metadata instance komputasi physicalHost lama

Setelah mengalami error host yang memindahkan instance komputasi ke host baru, saat Anda membuat kueri server metadata, server tersebut mungkin menampilkan metadata physicalHost dari host instance sebelumnya.

Untuk mengatasi masalah ini, lakukan salah satu langkah berikut:

Nilai baseInstanceName yang panjang dalam grup instance terkelola (MIG) dapat menyebabkan konflik nama disk

Dalam MIG, konflik nama disk dapat terjadi jika template instance menentukan disk yang akan dibuat saat pembuatan instance komputasi dan nilai baseInstanceName melebihi 54 karakter. Hal ini terjadi karena Compute Engine membuat nama disk menggunakan nama instance sebagai awalan.

Saat membuat nama disk, jika nama yang dihasilkan melebihi batas nama resource yaitu 63 karakter, Compute Engine akan memotong karakter yang berlebih dari akhir nama instance. Pemotongan ini dapat menyebabkan pembuatan nama disk yang identik untuk instance yang memiliki pola penamaan yang mirip. Dalam kasus ini, instance baru akan mencoba memasang disk yang ada. Jika disk sudah terpasang ke instance komputasi lain, pembuatan instance baru akan gagal. Jika disk tidak terpasang atau berada dalam mode multi-penulis, instance baru akan memasang disk, yang berpotensi menyebabkan kerusakan data.

Untuk menghindari konflik nama disk, pertahankan nilai baseInstanceName hingga panjang maksimum 54 karakter.

Membuat pemesanan atau permintaan pemesanan untuk masa mendatang menggunakan template instance yang menentukan jenis mesin A2, C3, atau G2 menyebabkan masalah

Jika Anda menggunakan template instance yang menentukan jenis mesin A2, C3, atau G2 untuk membuat pemesanan, atau membuat dan mengirim permintaan pemesanan untuk masa mendatang untuk ditinjau, Anda akan mengalami masalah. Secara khusus, salah satu hal berikut mungkin terjadi:

  • Pembuatan pemesanan mungkin gagal. Jika berhasil, salah satu dari hal berikut ini berlaku:

    • Jika Anda membuat pemesanan yang digunakan secara otomatis (default), pembuatan instance komputasi dengan properti yang cocok tidak akan menggunakan pemesanan.

    • Jika Anda membuat pemesanan tertentu, pembuatan instance komputasi untuk menargetkan pemesanan secara khusus akan gagal.

  • Pembuatan permintaan pemesanan untuk masa mendatang berhasil. Namun, jika Anda mengirimkannya untuk ditinjau, Google Cloud akan menolak permintaan Anda.

Anda tidak dapat mengganti template instance yang digunakan untuk membuat permintaan pemesanan atau pemesanan untuk masa mendatang, atau mengganti properti instance template. Jika Anda ingin memesan resource untuk jenis mesin A2, C3, atau G2, lakukan salah satu hal berikut:

Batasan saat menggunakan jenis mesin -lssd dengan Google Kubernetes Engine

Saat menggunakan Google Kubernetes Engine API, node pool yang Anda sediakan dengan disk SSD Lokal harus memiliki jumlah disk SSD Lokal yang sama dengan jenis mesin C4, C3, atau C3D yang dipilih. Misalnya, jika Anda berencana membuat instance komputasi yang menggunakan jenis mesin c3-standard-8-lssd, harus ada dua disk SSD Lokal; jika Anda menggunakan jenis mesin c3d-standard-8-lssd, hanya diperlukan satu disk. Jika nomor disk tidak cocok, Anda akan mendapatkan error kesalahan konfigurasi SSD Lokal dari bidang kontrol Compute Engine. Lihat Jenis mesin yang otomatis memasang disk SSD Lokal untuk memilih jumlah disk SSD Lokal yang benar berdasarkan jenis mesin lssd.

Jika Anda menggunakan konsol Google Kubernetes Engine Google Cloud untuk membuat cluster atau node pool, pembuatan node akan gagal atau disk SSD Lokal tidak akan terdeteksi sebagai penyimpanan efemeral saat menggunakan salah satu jenis mesin berikut:

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

Variabilitas throughput TCP alur tunggal pada instance C3D

Instance C3D yang memiliki lebih dari 30 vCPU mungkin mengalami variabilitas throughput TCP alur tunggal dan terkadang dibatasi hingga 20 hingga 25 Gbps. Untuk mencapai kapasitas yang lebih tinggi, gunakan beberapa alur TCP.

Metrik kemampuan observasi penggunaan CPU salah untuk instance komputasi yang menggunakan satu thread per core

Jika CPU instance komputasi Anda menggunakan satu thread per core, metrik pemakaian CPU Cloud Monitoring di tab Observability* pada halaman VM instances di konsol Compute Engine Google Cloud hanya diskalakan menjadi 50%. Dua thread per core adalah setelan default untuk sebagian besar jenis mesin. Untuk mengetahui informasi selengkapnya, lihat Menetapkan jumlah thread per core.

Untuk menampilkan pemakaian CPU instance komputasi Anda yang dinormalkan menjadi 100%, tampilkan pemakaian CPU di Metrics Explorer. Untuk informasi selengkapnya, lihat Membuat diagram dengan Metrics Explorer.

Koneksi SSH-in-browser konsolGoogle Cloud mungkin gagal jika Anda menggunakan aturan firewall kustom

Jika menggunakan aturan firewall kustom untuk mengontrol akses SSH ke instance komputasi, Anda mungkin tidak dapat menggunakan fitur SSH-in-browser.

Untuk mengatasi masalah ini, lakukan salah satu langkah berikut:

Nama sementara untuk disk

Selama update instance komputasi yang dimulai menggunakan perintah gcloud compute instances update atau metode instances.update API, Compute Engine mungkin mengubah nama disk instance komputasi Anda untuk sementara waktu, dengan menambahkan akhiran berikut ke nama aslinya:

  • -temp
  • -old
  • -new

Compute Engine menghapus akhiran dan memulihkan nama disk asli saat update selesai.

Meningkatkan latensi untuk beberapa Persistent Disk yang disebabkan oleh perubahan ukuran disk

Dalam beberapa kasus, mengubah ukuran Persistent Disk berukuran besar (~3 TB atau lebih) dapat mengganggu performa I/O disk. Jika Anda terkena dampak masalah ini, Persistent Disk Anda mungkin mengalami peningkatan latensi selama operasi pengubahan ukuran. Masalah ini dapat memengaruhi Persistent Disk dari semua jenis.

Proses otomatis Anda mungkin gagal jika menggunakan data respons API tentang kuota komitmen berbasis resource

Proses otomatis yang memakai dan menggunakan data respons API terkait kuota komitmen berbasis resource Compute Engine mungkin akan gagal jika setiap hal berikut terjadi. Proses otomatis Anda dapat menyertakan cuplikan kode, logika bisnis, atau kolom database yang menggunakan atau menyimpan respons API.

  1. Data respons berasal dari salah satu metode Compute Engine API berikut:

  2. Anda menggunakan int, bukan number, untuk menentukan kolom untuk batas kuota resource dalam isi respons API. Anda dapat menemukan kolom ini dengan cara berikut untuk setiap metode:

  3. Anda memiliki kuota default tak terbatas yang tersedia untuk setiap SKU Compute Engine yang di-commit.

    Untuk mengetahui informasi selengkapnya tentang kuota komitmen dan SKU yang di-commit, lihat Kuota untuk komitmen dan resource yang di-commit.

Akar masalah

Saat kuota Anda terbatas, jika Anda menentukan kolom items[].quotas[].limit atau quotas[].limit sebagai jenis int, data respons API untuk batas kuota Anda mungkin masih berada dalam rentang untuk jenis int dan proses otomatis Anda mungkin tidak akan terganggu. Namun, jika batas kuota default tidak terbatas, Compute Engine API akan menampilkan nilai untuk kolom limit yang berada di luar rentang yang ditentukan oleh jenis int. Proses otomatis Anda tidak dapat menggunakan nilai yang ditampilkan oleh metode API dan akibatnya gagal.

Cara mengatasi masalah ini

Anda dapat mengatasi masalah ini dan terus membuat laporan otomatis dengan cara berikut:

  • Direkomendasikan: Ikuti dokumentasi referensi Compute Engine API dan gunakan jenis data yang benar untuk definisi metode API. Secara khusus, gunakan jenis number untuk menentukan kolom items[].quotas[].limit dan quotas[].limit untuk metode API Anda.

  • Kurangi batas kuota Anda menjadi nilai di bawah 9.223.372.036.854.775.807. Anda harus menetapkan batas kuota untuk semua project yang memiliki komitmen berbasis resource, di semua region. Anda dapat melakukannya dengan salah satu cara berikut:

Masalah umum untuk instance GPU

Bagian berikut menjelaskan masalah umum untuk instance GPU Compute Engine.

Jenis mesin yang dioptimalkan akselerator yang memiliki disk SSD Lokal yang terpasang secara otomatis mungkin memerlukan waktu berjam-jam untuk dihentikan dan dimulai ulang

Jenis mesin yang dioptimalkan akselerator memiliki GPU yang terpasang secara otomatis. Sebagian besar jenis mesin yang dioptimalkan akselerator seri A, kecuali A2 Standard, memiliki disk SSD Lokal yang terpasang secara otomatis.

Jenis mesin yang dioptimalkan akselerator tidak mendukung migrasi langsung, dan Anda harus menetapkan kebijakan pemeliharaan host ke TERMINATE. Jenis mesin ini dapat memerlukan waktu hingga satu jam untuk dihentikan setelah kegagalan atau error host. Untuk jenis mesin yang dioptimalkan untuk akselerator yang memiliki disk SSD Lokal yang terpasang secara otomatis, proses penghentian mungkin memerlukan waktu beberapa jam.

Error pembuatan dan penurunan performa saat menggunakan Dynamic NIC dengan instance GPU

Dynamic NIC tidak didukung untuk digunakan dengan instance GPU. Jika Anda membuat instance GPU dengan NIC Dinamis, atau menambahkan NIC Dinamis ke instance GPU yang ada, masalah berikut mungkin terjadi:

  • Operasi akan gagal dengan error seperti berikut:

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

  • Operasi berhasil, tetapi instance mengalami penurunan performa, seperti bandwidth jaringan yang jauh lebih rendah.

Masalah ini terjadi karena konfigurasi Dynamic NIC menyebabkan error saat Compute Engine mencoba mendistribusikan vNIC instance di seluruh NIC fisik di server host.

Masalah umum untuk instance bare metal

Berikut adalah masalah umum untuk instance bare metal Compute Engine.

Memulai pemeliharaan host secara manual tidak berfungsi untuk instance X4

Untuk instance X4, prosedur yang dijelaskan dalam memulai peristiwa pemeliharaan host secara manual tidak berfungsi.

Solusi

  1. Hentikan instance X4.
  2. Setelah status instance berubah menjadi TERMINATED, mulai instance X4.

Untuk mengetahui informasi tentang cara menghentikan atau memulai ulang instance X4, lihat Menghentikan atau memulai ulang instance Compute Engine.

Jenis mesin bare metal C4D tidak mendukung image SUSE Linux 15 SP6

Instance bare metal C4D tidak dapat menjalankan OS SUSE Linux Enterprise Server (SLES) versi 15 SP6.

Solusi

Gunakan SLES 15 SP5 sebagai gantinya.

Simulasi pemeliharaan host tidak berfungsi untuk instance bare metal C4

Jenis mesin c4-standard-288-metal dan c4-highmem-288-metal tidak mendukung simulasi peristiwa pemeliharaan host.

Solusi

Gunakan instance virtual machine (VM) yang dibuat menggunakan jenis mesin C4 lainnya untuk menyimulasikan peristiwa pemeliharaan.

  1. Buat instance VM menggunakan jenis mesin C4 yang tidak diakhiri dengan -metal.

    Saat membuat VM, konfigurasikan instance C4 ke Terminate, bukan menggunakan Migrasi Langsung selama peristiwa pemeliharaan host.

  2. Simulasikan peristiwa pemeliharaan host untuk VM ini.

Selama peristiwa pemeliharaan host yang disimulasikan, perilaku untuk VM yang dikonfigurasi ke Terminate sama dengan perilaku untuk instance C4 bare metal.

Performa lebih rendah dari yang diperkirakan dengan instance bare metal Z3 di RHEL 8

Saat menggunakan Red Hat Enterprise Linux (RHEL) versi 8 dengan instance bare metal Z3, performa jaringan lebih rendah dari yang diharapkan.

Akar masalah

Ada fitur Page Pool yang tidak ada dalam versi kernel Linux (4.18) yang digunakan oleh RHEL 8.

Solusi

Gunakan versi RHEL yang lebih baru atau sistem operasi lain saat Anda bekerja dengan instance bare metal Z3.

Masalah terkait penggunaan Dynamic Network Interface

Bagian ini menjelaskan masalah umum terkait penggunaan beberapa antarmuka jaringan dan Dynamic Network Interface.

Paket yang dihapus saat menggunakan Dynamic NIC dengan rentang IP alias, penerusan protokol, atau Load Balancer Jaringan Passthrough

Agen tamu otomatis menambahkan rute lokal dalam skenario berikut untuk vNIC, tetapi tidak untuk Dynamic NIC:

  • Saat Anda mengonfigurasi rentang IP alias, agen tamu akan membuat rute lokal untuk rentang IP alias.
  • Saat Anda membuat instance target yang mereferensikan instance komputasi untuk penerusan protokol, agen tamu akan membuat rute lokal untuk alamat IP aturan penerusan terkait.
  • Saat Anda menambahkan backend ke Load Balancer Jaringan Passthrough, agen tamu akan membuat rute lokal untuk alamat IP aturan penerusan terkait.

Karena rute lokal tidak ditambahkan untuk Dynamic NIC, Dynamic NIC mungkin mengalami paket yang tidak terkirim.

Untuk mengatasi masalah ini, tambahkan alamat IP secara manual sebagai berikut:

  1. Hubungkan ke instance menggunakan SSH.

  2. Jika Anda mengonfigurasi rentang IP alias, lakukan hal berikut. Jika tidak, Anda dapat melewati langkah ini.

    1. Di /etc/default/instance_configs.cfg, pastikan setelan ip_aliases ditetapkan ke true.

    2. Jika setelan ip_aliases ditetapkan ke false, ubah file untuk mengubahnya menjadi true, lalu mulai ulang agen tamu:

      systemctl restart google-guest-agent

  3. Konfigurasikan rute lokal untuk rentang IP alias atau alamat IP aturan penerusan menggunakan perintah berikut:

    ip route add to local IP_ADDRESS dev DYNAMIC_NIC_DEVICE_NAME proto 66

    Ganti kode berikut:

    • IP_ADDRESS: rentang IP alias atau alamat IP aturan penerusan yang ingin Anda tambahi rute lokal.
    • DYNAMIC_NIC_DEVICE_NAME: nama perangkat Dynamic NIC yang ingin Anda tambahi rute lokal. Contoh, a-gcp.ens4.3.

Masalah terkait penginstalan dan pengelolaan NIC Dinamis di agen tamu versi 20250901.00 hingga 20251120.01

Jika Anda mengonfigurasi pengelolaan otomatis Dynamic NIC dan instance Anda menjalankan agen tamu pada versi dari 20250901.00 hingga 20251120.01, Anda mungkin mengalami masalah berikut:

  • Agen tamu gagal menginstal dan mengelola Dynamic NIC di OS tamu instance Anda.

    Anda mungkin menerima error yang menyertakan Cannot find device saat menjalankan perintah di OS tamu yang merujuk ke Dynamic NIC.

  • Menghapus beberapa Dynamic NIC akan menyebabkan server metadata tidak dapat diakses.

Akar masalah

Mulai versi 20250901.00, agen tamu dimigrasikan ke arsitektur berbasis plugin baru untuk meningkatkan modularitas. Arsitektur baru ini awalnya tidak mendukung penginstalan dan pengelolaan otomatis Dynamic NIC.

Resolusi

Untuk mengatasi masalah ini, update instance Anda agar menggunakan agen tamu versi 20251205.00 atau yang lebih baru:

  1. Untuk mengupdate agen tamu ke versi terbaru, lihat Mengupdate lingkungan tamu.
  2. Untuk mengonfirmasi versi agen tamu yang dijalankan instance Anda, lihat Melihat paket yang diinstal berdasarkan versi sistem operasi.

Jika perlu, Anda dapat mengatasi sementara masalah ini untuk instance yang menjalankan agen tamu versi 20250901.00 hingga 20251120.01 dengan mengikuti petunjuk di Kompatibilitas mundur untuk kembali ke arsitektur agen tamu sebelumnya.

Packet Intercept dapat menyebabkan paket hilang karena tag VLAN tidak ada di header Ethernet

Intersepsi paket saat menggunakan Dynamic NIC dapat menyebabkan paket terputus. Paket yang dihapus dapat terjadi jika pipeline dihentikan lebih awal. Masalah ini memengaruhi mode berbasis sesi dan non-sesi.

Akar masalah

Paket yang dihapus terjadi selama intersepsi paket saat pipeline dihentikan lebih awal (intersepsi ingress dan injeksi ulang egress). Penghentian awal menyebabkan ID VLAN hilang dari header Ethernet paket masuk. Karena paket egress berasal dari paket ingress yang dimodifikasi, paket egress juga tidak memiliki ID VLAN. Hal ini menyebabkan pemilihan indeks endpoint yang salah dan penurunan paket berikutnya.

Solusi

Jangan gunakan fitur Google Cloud yang mengandalkan intersepsi paket, seperti endpoint firewall.

Operasi NIC dinamis gagal saat instance komputasi berada di beberapa grup instance

Jika Anda menambahkan atau menghapus Dynamic NIC, dan operasi macet dalam status RUNNING pada progres 0% dan akhirnya gagal dengan INTERNAL_ERROR, hal ini mungkin karena instance komputasi berada dalam beberapa grup instance (terkelola atau tidak terkelola).

Agar operasi dapat diselesaikan, hapus instance dari semua grup instance, kecuali satu. Anda dapat menghapus instance dari grup instance terkelola atau menghapus instance dari grup instance tidak terkelola.

Masalah umum untuk instance komputasi Linux

Berikut adalah masalah umum untuk instance komputasi Linux.

Error upgrade paket di Rocky Linux 9.7

dnf update gagal pada image Rocky Linux Accelerator Optimized versi v20251113 atau yang lebih lama (misalnya, rocky-linux-9-optimized-gcp-nvidia-latest-v20251113) karena konflik dependensi paket. Anda mungkin melihat error yang mirip dengan berikut:

[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)

Akar masalah

Konflik versi paket userspace terjadi antara versi DOCA OFED sebelum 3.20 dan Rocky Linux 9.7. Secara khusus, Rocky Linux 9.7 menyertakan paket ucx dan perftest yang merupakan versi yang lebih baru daripada paket yang sesuai di repositori DOCA OFED. Ketidakcocokan versi ini menyebabkan dnf update gagal dengan error penyelesaian dependensi.

Resolusi

Sebelum melakukan upgrade sistem lengkap, update paket repositori DOCA:

sudo dnf update doca-repo
sudo dnf update

Image Rocky Linux yang Dioptimalkan untuk Akselerator yang dibuat pada Desember 2025 (misalnya, rocky-linux-9-optimized-gcp-nvidia-latest-v20251215) sudah menyertakan paket doca-repo yang diupdate, sehingga masalah upgrade ini tidak ada pada build tersebut atau yang lebih baru.

Login OS tidak didukung di SLES 16

Masalah konfigurasi SSH di SUSE Linux Enterprise Server (SLES) 16 mencegah penggunaan fitur Google Cloud OSLogin. Namun, Koneksi SSH yang dikelola metadata tidak terpengaruh dan terus berfungsi.

Format URL yang didukung untuk skrip startup

Jika instance komputasi Anda menggunakan agen tamu versi 20251115.00, pengambilan skrip startup menggunakan kunci metadata startup-script-url akan gagal jika URL menggunakan format https://storage.googleapis.com/ yang didokumentasikan di halaman Menggunakan skrip startup di VM Linux.

Untuk mengatasi masalah ini, gunakan salah satu format URL yang didukung berikut:

  • URL yang Diautentikasi: https://storage.cloud.google.com/BUCKET/FILE
  • URI penyimpanan gcloud CLI: gs://BUCKET/FILE

Instance VM yang menggunakan image Debian 11 sebelum versi v20250728 gagal menjalankan apt update

Pada 22 Juli 2025, komunitas Debian menghapus backport Debian 11 (Bullseye) dari upstream Debian utama. Update ini menyebabkan sudo apt update gagal dengan error berikut:

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

Akar masalah

Karena komunitas Debian menghapus repositori backport dari upstream utama, tidak ada lagi referensi ke bullseye-backports Release.

Resolusi

Gunakan versi image debian-11-bullseye-v20250728 atau yang lebih baru. Versi ini tidak berisi repositori backport. Atau, Anda dapat mengupdate instance saat ini dengan mengubah /etc/apt/sources.list:

  • Untuk memperbarui URL repositori dan menggunakan arsip untuk 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

  • Untuk menghapus URL repositori dan menghapus 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

Penginstalan paket ubuntu-desktop merusak konektivitas jaringan saat instance dimulai ulang

Saat Anda memulai ulang instance komputasi Ubuntu setelah menginstal paket ubuntu-desktop, antarmuka jaringan mungkin tidak dikonfigurasi dengan benar.

Akar masalah

Paket ubuntu-deskop menarik ubuntu-settings sebagai dependensi, yang menetapkan NetworkManager sebagai "perender" default untuk netplan. Lebih khusus lagi, tindakan ini menyisipkan konfigurasi YAML baru untuk netplan di /usr/lib/netplan/00-network-manager-all.yaml yang berisi hal berikut:

network:
  version: 2
  renderer: NetworkManager

Konfigurasi ini bertentangan dengan penyediaan awal berbasis networkd menggunakan cloud-init.

Pemulihan

Jika instance komputasi telah dimulai ulang dan tidak dapat diakses, lakukan hal berikut:

  1. Ikuti petunjuk tentang cara menyelamatkan instance komputasi.

  2. Setelah memasang partisi sistem file Linux instance komputasi yang tidak dapat diakses, jalankan perintah berikut (ganti /rescue dengan direktori pemasangan Anda):

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

  3. Lanjutkan untuk memulai ulang instance komputasi yang tidak dapat diakses.

Instance komputasi yang menggunakan OS Ubuntu versi v20250530 menampilkan FQDN yang salah

Anda mungkin melihat Nama Domain yang Sepenuhnya Memenuhi Syarat (FQDN) yang salah dengan penambahan akhiran .local saat Anda melakukan salah satu hal berikut:

  • Update ke versi 20250328.00 dari paket google-compute-engine.
  • Luncurkan instance komputasi dari image Ubuntu yang ditawarkan Canonical dengan akhiran versi v20250530.

Misalnya, projects/ubuntu-os-cloud/global/images/ubuntu-2204-jammy-v20250530.

Jika mengalami masalah ini, Anda mungkin melihat FQDN yang mirip dengan berikut ini:

   [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

Akar masalah

Pada semua image Ubuntu dengan versi v20250530, paket guest-config versi 20250328.00 menambahkan local ke jalur penelusuran karena pengenalan file konfigurasi baru: 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

Keberadaan entri local ini dalam jalur penelusuran di file /etc/resolv.conf menyebabkan elemen .local ditambahkan ke nama host saat FQDN diminta.

Perhatikan bahwa guest-configs versi 20250501 telah memperbaiki masalah ini, tetapi Canonical belum memasukkan perbaikan tersebut ke dalam image mereka.

Solusi

  1. Ubah file konfigurasi Resolusi Nama Jaringan /etc/systemd/resolved.conf.d/gce-resolved.conf dengan mengubah Domains=local menjadi Domains=~local
  2. Jalankan perintah berikut untuk memulai ulang layanan systemd-resolved: systemctl restart systemd-resolved
  3. Pastikan local dihapus dari jalur penelusuran di /etc/resolv.conf

  4. Konfirmasi FQDN menggunakan perintah hostname -f

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

Tidak ada mkfs.ext4 di Image openSUSE

Rilis v20250724 terbaru image openSUSE (mulai dari opensuse-leap-15-6-v20250724-x86-64) dari Agustus 2025 tidak memiliki paket e2fsprogs, yang menyediakan utilitas untuk mengelola sistem file. Gejala umum dari masalah ini adalah Anda melihat pesan error seperti command not found saat mencoba menggunakan perintah mkfs.ext4.

Solusi

Jika Anda mengalami masalah ini, instal paket yang tidak ada secara manual menggunakan pengelola paket 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

Instance komputasi SUSE Enterprise gagal melakukan booting setelah mengubah jenis mesin

Setelah Anda mengubah jenis mesin untuk instance komputasi yang menjalankan SUSE Enterprise Linux, instance tersebut dapat gagal melakukan booting dengan error berikut di serial console:

            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"

Akar masalah

SUSE membuat image cloud-nya dengan initramfs (sistem file RAM awal) serbaguna yang mendukung berbagai jenis instance. Hal ini dicapai dengan menggunakan flag --no-hostonly --no-hostonly-cmdline -o multipath selama pembuatan image awal. Namun, saat kernel baru diinstal atau initramfs dibuat ulang, yang terjadi selama update sistem, flag ini akan dihilangkan secara default. Hal ini menghasilkan initramfs yang lebih kecil yang disesuaikan secara khusus untuk hardware sistem saat ini, yang berpotensi mengecualikan driver yang diperlukan untuk jenis instance lain.

Misalnya, instance C3 menggunakan drive NVMe, yang memerlukan modul tertentu untuk disertakan dalam initramfs. Jika sistem dengan initramfs yang tidak memiliki modul NVMe ini dimigrasikan ke instance C3, proses booting akan gagal. Masalah ini juga dapat memengaruhi jenis instance lain dengan persyaratan hardware yang unik.

Solusi

Sebelum mengubah jenis mesin, buat ulang initramfs dengan semua driver:

dracut --force --no-hostonly

Jika sistem sudah terpengaruh oleh masalah ini, buat instance komputasi penyelamatan sementara. Gunakan perintah chroot untuk mengakses boot disk instance yang terpengaruh, lalu buat ulang initramfs menggunakan perintah berikut:

dracut -f --no-hostonly

Performa IOPS yang lebih rendah untuk SSD Lokal di Z3 dengan image SUSE 12

Instance komputasi Z3 yang menggunakan image SUSE Linux Enterprise Server (SLES) 12 memiliki performa yang jauh lebih rendah daripada yang diharapkan untuk IOPS di disk SSD Lokal.

Akar masalah

Masalah ini ada dalam codebase SLES 12.

Solusi

Patch dari SUSE untuk memperbaiki masalah ini tidak tersedia atau tidak direncanakan. Sebagai gantinya, Anda harus menggunakan sistem operasi SLES 15.

Instance komputasi RHEL 7 dan CentOS kehilangan akses jaringan setelah reboot

Jika instance komputasi CentOS atau RHEL 7 Anda memiliki beberapa kartu antarmuka jaringan (NIC) dan salah satu NIC ini tidak menggunakan antarmuka VirtIO, akses jaringan mungkin akan hilang saat reboot. Hal ini terjadi karena RHEL tidak mendukung penonaktifan nama antarmuka jaringan yang dapat diprediksi jika setidaknya satu NIC tidak menggunakan antarmuka VirtIO.

Resolusi

Konektivitas jaringan dapat dipulihkan dengan menghentikan dan memulai instance komputasi hingga masalah teratasi. Hilangnya konektivitas jaringan dapat dicegah agar tidak terjadi lagi dengan melakukan hal berikut:

  1. Edit file /etc/default/grub dan hapus parameter kernel net.ifnames=0 dan biosdevname=0.

  2. Buat ulang konfigurasi grub.

  3. Mulai ulang instance komputasi.

Tanda tangan repomd.xml tidak dapat diverifikasi

Pada sistem berbasis Red Hat Enterprise Linux (RHEL) atau CentOS 7, Anda mungkin melihat error berikut saat mencoba menginstal atau mengupdate software menggunakan yum. Error ini menunjukkan bahwa kunci GPG repositori Anda sudah tidak berlaku atau salah.

Contoh log: 

[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
Resolusi

Untuk memperbaikinya, nonaktifkan pemeriksaan kunci GPG repositori di konfigurasi repositori yum dengan menyetel repo_gpgcheck=0. Dalam image dasar Compute Engine yang didukung, setelan ini mungkin dapat ditemukan di file /etc/yum.repos.d/google-cloud.repo. Namun, instance komputasi Anda dapat memiliki set ini di file konfigurasi repositori atau alat otomatisasi yang berbeda.

Repositori Yum biasanya tidak menggunakan kunci GPG untuk validasi repositori. Sebaliknya, endpoint https tepercaya.

Untuk menemukan dan memperbarui setelan ini, selesaikan langkah-langkah berikut:

  1. Cari setelan di file /etc/yum.repos.d/google-cloud.repo Anda.

    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. Ubah semua baris yang bertuliskan repo_gpgcheck=1 menjadi repo_gpgcheck=0.

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

  3. Pastikan setelan telah diperbarui.

    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

Instance yang menggunakan Login OS menampilkan pesan login setelah koneksi

Pada beberapa instance yang menggunakan Login OS, Anda mungkin menerima pesan error berikut setelah koneksi dibuat:

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

Resolusi

Abaikan pesan error.

Masalah umum untuk instance Windows

  • Dukungan untuk NVMe di Windows yang menggunakan driver Community NVMe masih dalam versi Beta, dan performanya mungkin tidak sama dengan instance Linux. Driver Community NVMe telah diganti dengan driver Microsoft StorNVMe di image publik Google Cloud . Sebaiknya Anda mengganti driver NVME pada instance komputasi yang dibuat sebelum Mei 2022 dan menggunakan driver Microsoft StorNVMe.
  • Setelah membuat instance, Anda tidak dapat langsung terhubung. Semua instance Windows baru menggunakan alat Persiapan sistem (sysprep) untuk menyiapkan instance Anda, yang dapat memerlukan waktu 5–10 menit untuk menyelesaikannya.
  • Image Windows Server tidak dapat diaktifkan tanpa koneksi jaringan ke kms.windows.googlecloud.com dan akan berhenti berfungsi jika tidak diautentikasi dalam waktu 30 hari. Software yang diaktifkan oleh KMS harus diaktifkan ulang setiap 180 hari, tetapi KMS akan mencoba mengaktifkan kembali setiap 7 hari. Pastikan untuk mengonfigurasi instance komputasi Windows agar tetap aktif.
  • Software kernel yang mengakses register khusus model yang tidak diemulasi akan menghasilkan kesalahan perlindungan umum, yang dapat menyebabkan error sistem, bergantung pada sistem operasi tamu.
  • Driver vioscsi, yang digunakan untuk disk SCSI, menetapkan flag removable, sehingga disk diperlakukan sebagai penyimpanan portabel. Hal ini menyebabkan pembatasan akses yang tidak terduga di Windows ke disk yang tunduk pada Group Policy Object (GPO) yang menargetkan penyimpanan yang dapat dilepas.

Agen tamu gagal dimulai di Windows Server 2012 R2 dan yang lebih lama

Setelah mengupdate paket agen tamu pada instance yang menjalankan sistem operasi Windows lama (seperti Windows Server 2012 R2, Windows Server 2012, atau Windows Server 2008 R2). Jika Anda menjalankan biner secara manual, Anda akan menerima error yang menyatakan bahwa biner tidak dikenali.

Upstream Go (Golang) menghentikan dukungan untuk Windows Server 2012 R2 dan versi sebelumnya mulai dari Go 1.21. Build rilis agen tamu yang dibuat dengan Go 1.21 atau yang lebih baru tidak dapat berjalan di sistem operasi ini.

Solusi

Untuk mengatasi masalah ini, gunakan salah satu metode berikut:

  • Upgrade sistem operasi: upgrade instance VM Anda ke versi yang didukung, seperti Windows Server 2016 atau yang lebih baru. Untuk mengetahui informasi selengkapnya, lihat Akhir dukungan Windows.

  • Kembalikan ke versi agen tamu yang lebih lama: jika Anda harus terus menjalankan Windows Server 2012 R2 atau yang lebih lama, instal ulang paket agen tamu yang kompatibel dari instance komputasi lain yang sedang berjalan atau snapshot:

    1. Pada instance komputasi yang berfungsi, periksa versi paket google-compute-engine-windows dan google-compute-engine-metadata-scripts.
    2. Buka direktori cache Googet C:\ProgramData\Googet\cache\` and copy the.goo` untuk paket di atas ke VM yang rusak.
    3. Di VM yang rusak, instal paket yang disalin satu per satu dengan googet install -reinstall PACKAGE_NAME.goo.

  • Untuk mencegah agen tamu diupdate ke versi yang tidak kompatibel, nonaktifkan update otomatis untuk agen tamu.

Agen tamu gagal dimulai

Agen tamu Windows versi 20251011.00 gagal dimulai dalam kondisi beban tertentu.

Penyebab utama Paket agen tamu Windows untuk versi 20251011.00 salah menetapkan mode mulai agen tamu Windows ke auto di Windows Service Manager.

Penyelesaian Untuk mengatasi masalah ini, update instance Anda agar menggunakan agen tamu versi 20251120.01 atau yang lebih baru.

Solusi manual Jika menginstal versi 20251120.01 bukan merupakan opsi, jalankan perintah berikut:

  • sc.exe config GCEAgent start=delayed-auto

Fitur pengelolaan kredensial mungkin gagal untuk instance Windows yang menggunakan nama bahasa selain bahasa Inggris

Agen tamu Windows mengidentifikasi akun dan grup administrator menggunakan pencocokan string. Oleh karena itu, fitur pengelolaan kredensial hanya berfungsi dengan benar saat Anda menggunakan nama bahasa Inggris untuk akun dan grup pengguna, misalnya, Administrators. Jika Anda menggunakan nama bahasa selain bahasa Inggris, fitur pengelolaan kredensial seperti membuat atau mereset sandi mungkin tidak berfungsi seperti yang diharapkan.

Windows Server 2016 tidak akan melakukan booting pada jenis mesin C3D dengan 180 vCPU atau lebih

Windows Server 2016 tidak akan melakukan booting pada jenis mesin C3D yang memiliki 180 atau 360 vCPU. Untuk mengatasi masalah ini, pilih salah satu opsi berikut:

  • Jika Anda perlu menggunakan Windows Server 2016, gunakan jenis mesin yang memiliki kurang dari 180 vCPU.
  • Jika Anda perlu menggunakan jenis mesin C3D yang memiliki 180 atau 360 vCPU, gunakan Windows Server versi yang lebih baru.

Windows Server 2025 dan Windows 11 24h2/25h2 - Dukungan penangguhan dan pelanjutan

Windows Server 2025, Windows 11 24h2, dan Windows 11 25h2 tidak dapat melanjutkan saat ditangguhkan. Hingga masalah ini diselesaikan, fitur penangguhan dan melanjutkan tidak akan didukung untuk Windows Server 2025, Windows 11 24h2, dan Windows 11 25h2.

Error saat mengukur pergeseran waktu NTP menggunakan w32tm di instance Windows

Untuk instance Windows di Compute Engine yang menggunakan antarmuka jaringan VirtIO, ada bug umum yang menyebabkan pengukuran penyimpangan NTP menghasilkan error saat menggunakan perintah berikut:

w32tm /stripchart /computer:metadata.google.internal

Error akan terlihat seperti berikut:

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

Bug ini hanya memengaruhi instance Compute Engine dengan NIC VirtIO. Instance komputasi yang menggunakan antarmuka jaringan gVNIC tidak mengalami masalah ini.

Untuk menghindari masalah ini, Google merekomendasikan penggunaan alat pengukur penyimpangan NTP lainnya, seperti Meinberg Time Server Monitor.

Perangkat booting tidak dapat diakses setelah mengupdate instance komputasi dari instance Gen 1 atau 2 ke instance Gen 3 atau yang lebih baru

Windows Server mengikat boot drive ke jenis antarmuka disk awalnya saat startup pertama. Untuk mengubah instance komputasi yang ada dari seri mesin yang lebih lama (Generasi 1 atau 2) yang menggunakan antarmuka disk SCSI ke seri mesin yang lebih baru (Generasi 3 atau yang lebih baru) yang menggunakan antarmuka disk NVMe, lakukan sysprep driver PnP Windows sebelum menonaktifkan instance komputasi. Sysprep ini hanya menyiapkan driver perangkat dan memverifikasi bahwa semua jenis antarmuka disk dipindai untuk drive booting pada startup berikutnya.

Dari prompt Powershell, sebagai Administrator, jalankan:

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

Untuk mengubah seri mesin instance komputasi, lakukan hal berikut:

  1. Hentikan instance komputasi.
  2. Edit instance komputasi untuk menggunakan jenis mesin baru.
  3. Mulai instance komputasi.

Jika instance komputasi baru tidak dimulai dengan benar, edit instance komputasi untuk menggunakan jenis mesin asli, lalu mulai ulang instance. Urutan langkah ini akan membuat instance komputasi Anda berjalan dengan sukses. Tinjau persyaratan migrasi untuk memverifikasi bahwa Anda memenuhinya. Kemudian, coba lagi petunjuknya.

Lampiran jumlah disk terbatas untuk seri mesin yang menggunakan disk NVMe

Instance komputasi yang menggunakan antarmuka disk NVMe dan image OS Microsoft Windows memiliki batas pemasangan disk sebanyak 16 disk untuk seri mesin tertentu. Batas ini berlaku untuk seri mesin N4, C3, C3D, dan M3.

Seri mesin seperti C4, C4D, N4D, dan M4 mendukung lebih dari 16 disk saat Anda menggunakan driver NVMe yang kompatibel, seperti driver Microsoft StorNVMe.

Batas ini tidak berlaku untuk penyimpanan SSD Lokal. Untuk menghindari error, gabungkan penyimpanan Persistent Disk dan Hyperdisk Anda hingga maksimum 16 disk per instance komputasi untuk seri mesin yang terpengaruh.

Mengganti driver NVME pada instance komputasi yang dibuat sebelum Mei 2022

Jika ingin menggunakan NVMe pada instance komputasi yang menggunakan Microsoft Windows, dan instance tersebut dibuat sebelum 1 Mei 2022, Anda harus mengupdate driver NVMe yang ada di OS Tamu agar dapat menggunakan Driver Microsoft StorNVMe.

Anda harus mengupdate driver NVMe pada instance komputasi sebelum mengubah jenis mesin menjadi seri mesin generasi ketiga atau yang lebih baru, atau sebelum membuat snapshot boot disk yang akan digunakan untuk membuat instance komputasi baru yang menggunakan seri mesin generasi ketiga atau yang lebih baru.

Gunakan perintah berikut untuk menginstal paket driver StorNVME dan menghapus driver komunitas, jika ada di OS tamu.

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

Performa lebih rendah untuk disk SSD Lokal di instance C3 dan C3D yang menjalankan Microsoft Windows

Performa SSD Lokal dibatasi untuk instance C3 dan C3D yang menjalankan Microsoft Windows.

Peningkatan performa sedang dalam proses.

Performa lebih rendah untuk volume Hyperdisk Extreme yang terpasang ke instance n2-standard-80 yang menjalankan Microsoft Windows

Instance komputasi berdasarkan jenis mesin n2-standard-80 yang menjalankan Microsoft Windows dapat mencapai maksimum 80.000 IOPS di semua volume Hyperdisk Extreme yang terpasang ke instance.

Resolusi

Untuk mencapai hingga 160.000 IOPS dengan instance N2 yang menjalankan Windows, pilih salah satu jenis mesin berikut:

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

Throughput jaringan buruk saat menggunakan gVNIC

Instance komputasi Windows Server 2022 dan Windows 11 yang menggunakan paket GooGet driver gVNIC versi 1.0.0@44 atau yang lebih lama mungkin mengalami throughput jaringan yang buruk saat menggunakan Google Virtual NIC (gVNIC).

Untuk mengatasi masalah ini, update paket GooGet driver gVNIC ke versi 1.0.0@45 atau yang lebih baru dengan melakukan hal berikut:

  1. Periksa versi driver yang terinstal pada instance komputasi dengan menjalankan perintah berikut dari sesi Command Prompt atau Powershell administrator:

    googet installed

    Outputnya akan terlihat mirip seperti berikut:

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

  2. Jika versi driver google-compute-engine-driver-gvnic.x86_64 adalah 1.0.0@44 atau yang lebih lama, update Package Repository GooGet dengan menjalankan perintah berikut dari sesi Command Prompt atau Powershell administrator:

    googet update

Jenis mesin vCPU C4, C4D, dan C3D yang besar tidak mendukung image OS Windows

Jenis mesin C4 yang memiliki lebih dari 144 vCPU serta jenis mesin C4D dan C3D yang memiliki lebih dari 180 vCPU tidak mendukung image OS Windows Server 2012 dan 2016. Jenis mesin C4, C4D, dan C3D yang lebih besar yang menggunakan OS image Windows Server 2012 dan 2016 akan gagal di-booting. Untuk mengatasi masalah ini, pilih jenis mesin yang lebih kecil atau gunakan OS image lain.

Instance C3D yang dibuat dengan 360 vCPU dan image OS Windows akan gagal di-booting. Untuk mengatasi masalah ini, pilih jenis mesin yang lebih kecil atau gunakan OS image lain.

Instance C4D yang dibuat dengan lebih dari 255 vCPU dan image Windows 2025 akan gagal di-booting. Untuk mengatasi masalah ini, pilih jenis mesin yang lebih kecil atau gunakan OS image lain.

Error disk umum pada Windows Server 2016 dan 2012 R2 untuk instance M3, C3, C3D, dan C4D

Saat ini, kemampuan untuk menambahkan atau mengubah ukuran Hyperdisk atau Persistent Disk untuk instance M3, C3, C3D, atau C4D yang berjalan tidak berfungsi seperti yang diharapkan pada tamu Windows tertentu. Windows Server 2012 R2 dan Windows Server 2016, serta image klien Windows yang terkait, tidak merespons perintah pemasangan disk dan pengubahan ukuran disk dengan benar.

Misalnya, jika Anda menghapus disk dari instance M3 yang sedang berjalan, disk tersebut akan dilepas, tetapi sistem operasi Windows tidak mengenali bahwa disk tersebut tidak lagi tersedia. Penulisan berikutnya ke disk akan menampilkan error umum.

Resolusi

Jika Anda menggunakan instance M3, C3, C3D, atau C4D yang berjalan di sistem operasi Windows dan Anda mengubah volume Hyperdisk atau Persistent Disk, maka agar modifikasi disk dapat dikenali, Anda harus memulai ulang instance komputasi.