Halaman ini menjelaskan masalah umum yang mungkin Anda alami saat menggunakan 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.
Anda tidak dapat menggunakan konsol Google Cloud untuk membuat Spot VM untuk A4 dan A3 Ultra
Anda tidak dapat membuat VM Spot yang menggunakan seri mesin Ultra A4 atau A3 menggunakan konsol Google Cloud . Secara khusus, di halaman Create an instance, setelah Anda memilih jenis GPU untuk seri mesin ini di panel Machine configuration, panel Advanced menyatakan bahwa A reservation is required dan tidak memungkinkan Anda memilih Spot dalam daftar VM provisioning model.
Untuk mengatasi masalah ini, gunakan gcloud CLI atau REST untuk membuat Spot VM untuk A4 dan A3 Ultra. Atau, Anda dapat menggunakan konsol Google Cloud untuk membuat VM Ultra A4 dan A3 yang menggunakan model penyediaan terikat reservasi.
Mengubah IOPS atau throughput pada disk utama Replikasi Asinkron menggunakan perintah gcloud compute disks update
akan menyebabkan error palsu
Saat Anda menggunakan perintah gcloud compute disks update
untuk mengubah IOPS dan throughput pada disk utama Replikasi Asinkron, Google Cloud CLI akan menampilkan pesan error meskipun update berhasil.
Untuk memverifikasi secara akurat bahwa update berhasil, gunakan Google Cloud CLI atau konsol Google Cloud untuk melihat apakah properti disk menampilkan nilai IOPS dan throughput baru. Untuk mengetahui informasi selengkapnya, lihat Melihat setelan performa yang disediakan untuk Hyperdisk.
Server metadata mungkin menampilkan metadata VM physicalHost
lama
Setelah mengalami
error host yang
memindahkan instance ke host baru, saat Anda
mengirim kueri ke server metadata,
server tersebut mungkin menampilkan metadata
physicalHost
dari host sebelumnya instance.
Untuk mengatasi masalah ini, lakukan salah satu langkah berikut:
- Gunakan metode
instances.get
atau perintahgcloud compute instances describe
untuk mengambil informasiphysicalHost
yang benar. - Hentikan, lalu mulai instance Anda. Proses ini memperbarui informasi
physicalHost
di server metadata. - Tunggu 24 jam hingga informasi
physicalHost
instance yang terpengaruh diperbarui.
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 VM 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 63 karakter, Compute Engine akan memangkas karakter yang berlebih dari akhir nama instance. Pemotongan ini dapat menyebabkan pembuatan nama disk yang identik untuk instance yang memiliki pola penamaan yang serupa. Dalam kasus seperti itu, instance baru akan mencoba memasang disk yang ada. Jika disk sudah terpasang ke instance lain, pembuatan instance baru akan gagal. Jika disk tidak terpasang atau dalam mode multi-penulis, instance baru akan memasang disk, yang berpotensi menyebabkan kerusakan data.
Untuk menghindari konflik nama disk, pertahankan nilai baseInstanceName
dengan 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:
Pembuatan pemesanan mungkin gagal. Jika berhasil, salah satu dari hal berikut ini berlaku:
Jika Anda membuat pemesanan yang digunakan secara otomatis (default), pembuatan VM dengan properti yang cocok tidak akan menggunakan pemesanan.
Jika Anda membuat pemesanan tertentu, membuat VM untuk menargetkan pemesanan secara khusus akan gagal.
Berhasil membuat permintaan pemesanan untuk masa mendatang. 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 VM template. Jika Anda ingin mencadangkan resource untuk jenis mesin A2, C3, atau G2, lakukan salah satu hal berikut:
Buat project tunggal atau pemesanan bersama baru dengan menentukan properti secara langsung.
Buat permintaan pemesanan untuk masa mendatang yang baru dengan melakukan hal berikut:
Jika Anda ingin menghentikan permintaan pemesanan untuk masa mendatang yang ada agar tidak membatasi properti permintaan pemesanan untuk masa mendatang, yang dapat Anda buat di project saat ini—atau dalam project yang dibagikan oleh permintaan pemesanan untuk masa mendatang—hapus permintaan pemesanan untuk masa mendatang.
Buat project tunggal atau permintaan pemesanan untuk masa mendatang yang dibagikan dengan menentukan properti secara langsung dan mengirimkannya untuk ditinjau.
Batasan saat menggunakan jenis mesin -lssd
dengan Google Kubernetes Engine
Saat menggunakan Google Kubernetes Engine API, node pool dengan SSD Lokal yang terpasang yang Anda sediakan harus memiliki jumlah disk SSD yang sama dengan jenis mesin C4, C3, atau C3D yang dipilih. Misalnya, jika Anda berencana
untuk membuat VM yang menggunakan c3-standard-8-lssd
, harus ada 2 disk SSD,
sedangkan untuk c3d-standard-8-lssd
, hanya diperlukan 1 disk SSD. 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
.
Penggunaan konsol Google Kubernetes Engine Google Cloud untuk membuat cluster atau node pool dengan VM c4-standard-*-lssd
, c4-highmem-*-lssd
, c3-standard-*-lssd
, dan c3d-standard-*-lssd
akan menyebabkan kegagalan pembuatan node atau kegagalan untuk mendeteksi SSD Lokal sebagai penyimpanan efemeral.
Variabilitas throughput TCP alur tunggal pada VM C3D
VM C3D yang lebih besar dari 30 vCPU mungkin mengalami variabilitas throughput TCP alur tunggal dan terkadang dibatasi hingga 20-25 Gbps. Untuk mencapai kapasitas yang lebih tinggi, gunakan beberapa alur TCP.
Metrik kemampuan observasi penggunaan CPU salah untuk VM yang menggunakan satu thread per core
Jika CPU VM Anda menggunakan satu thread per core, metrik kemampuan observasi Cloud Monitoring pemakaian CPU di tab Mesin Compute> VM instances > Observability hanya diskalakan menjadi 50%. Dua thread per core adalah setelan default untuk semua jenis mesin, kecuali Tau T2D. Untuk mengetahui informasi selengkapnya, lihat Menetapkan jumlah thread per core.
Untuk menampilkan pemakaian CPU VM 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 VM, Anda mungkin tidak dapat menggunakan fitur SSH-in-browser.
Untuk mengatasi masalah ini, lakukan salah satu langkah berikut:
Aktifkan Identity-Aware Proxy untuk TCP agar dapat terus terhubung ke VM menggunakan fitur konsol Google Cloud SSH-in-browser.
Buat ulang aturan firewall
default-allow-ssh
untuk terus terhubung ke VM menggunakan SSH-in-browser.Hubungkan ke VM menggunakan Google Cloud CLI, bukan SSH-in-browser.
Nama sementara untuk disk
Selama update instance virtual machine (VM) yang dimulai menggunakan
perintah gcloud compute instances update
atau
metode instances.update
API, Compute Engine mungkin mengubah nama disk VM 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 perubahan 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.
Data respons berasal dari salah satu metode Compute Engine API berikut:
Anda menggunakan
int
, bukannumber
, untuk menentukan kolom untuk batas kuota resource dalam isi respons API. Anda dapat menemukan kolom ini dengan cara berikut untuk setiap metode:items[].quotas[].limit
untuk metodecompute.regions.list
.quotas[].limit
untuk metodecompute.regions.get
.quotas[].limit
untuk metodecompute.projects.get
.
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 kolomitems[].quotas[].limit
danquotas[].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:
- Ikuti langkah yang sama seperti yang Anda lakukan untuk meminta penyesuaian kuota, dan meminta batas kuota yang lebih rendah.
- Buat penggantian kuota.
Masalah umum untuk Instance bare metal
Instance bare metal C4D tidak dapat menjalankan OS SUSE Linux Enterprise Server (SLES) versi 15 SP6.
Solusi
Sebagai gantinya, gunakan SLES 15 SP5.
Masalah terkait penggunaan Dynamic Network Interface
Bagian ini menjelaskan masalah umum terkait penggunaan beberapa antarmuka jaringan dan Antarmuka Jaringan Dinamis.
Kehilangan paket dengan ukuran MTU kustom
NIC Dinamis dengan vNIC induk mungkin mengalami kehilangan paket dengan ukuran MTU kustom.
Solusi
Untuk menghindari kehilangan paket, gunakan salah satu ukuran MTU berikut:
- 1.460 byte (nilai default untuk jaringan VPC)
- 1.500 byte (Ethernet standar)
- 8.896 byte (nilai maksimum yang mungkin)
Interaksi firewall saat menggunakan kembali ID VLAN dengan NIC Dinamis
Pada instance, menggunakan kembali ID VLAN untuk NIC Dinamis baru akan berimplikasi pada pelacakan koneksi firewall. Jika Anda menghapus NIC Dinamis dan membuat NIC Dinamis pengganti yang menggunakan ID VLAN yang sama, entri tabel pelacakan koneksi firewall tidak akan dihapus secara otomatis. Contoh berikut menunjukkan pertimbangan keamanan yang relevan:
- Instance komputasi memiliki NIC Dinamis contoh dengan ID VLAN
4
yang terhubung ke subnet di jaringan VPCnetwork-1
. - Instance mengirimkan paket ke alamat IP tujuan dan port tujuan 192.0.2.7:443. Aturan firewall keluar yang berlaku mengizinkan koneksi keluar.
- Karena aturan Cloud NGFW bersifat stateful, koneksi keluar yang diizinkan akan membuat entri tabel pelacakan koneksi firewall yang mengizinkan paket masuk dari alamat IP sumber dan port sumber 192.0.2.7:443.
- Anda menghapus NIC Dinamis contoh dan membuat NIC Dinamis pengganti. NIC Dinamis pengganti juga menggunakan ID VLAN
4
, tetapi terhubung ke subnet di jaringan VPC yang berbeda,network-2
. - Semua entri tabel pelacakan koneksi firewall yang belum berakhir dan berlaku untuk NIC Dinamis asli juga berlaku untuk NIC Dinamis pengganti. Artinya, resource di jaringan VPC
network-2
dapat mengirim paket yang sumbernya cocok dengan 192.0.2.7:443, dan instance komputasi menerimanya tanpa perlu mengevaluasi aturan firewall ingress.
Untuk mengetahui informasi selengkapnya tentang pelacakan koneksi dan aturan firewall, lihat Spesifikasi dalam dokumentasi Cloud Next Generation Firewall.
Solusi
Berdasarkan per instance, jika Anda perlu membuat NIC Dinamis yang menggunakan ID VLAN yang sama dengan NIC Dinamis yang dihapus dari instance:
- Tunggu setidaknya 10 menit antara menghapus NIC Dinamis asli dan membuat NIC Dinamis pengganti.
- Hentikan instance, hapus NIC Dinamis asli dan buat NIC Dinamis pengganti, lalu mulai instance.
Penyadapan paket dapat mengakibatkan paket dihentikan karena tag VLAN yang tidak ada di header Ethernet
Penyadapan paket saat menggunakan NIC Dinamis dapat menyebabkan paket dibuang. Paket yang dihentikan dapat terjadi saat pipeline dihentikan lebih awal. Masalah ini memengaruhi mode berbasis sesi dan non-berbasis sesi.
Akar masalah
Paket yang dihentikan terjadi selama penyadapan paket saat pipeline dihentikan lebih awal (penyadapan ingress dan penyisipan ulang egress). Penghentian awal menyebabkan ID VLAN tidak ada di header Ethernet paket ingress. Karena paket keluar berasal dari paket masuk yang diubah, paket keluar juga tidak memiliki ID VLAN. Hal ini menyebabkan pemilihan indeks endpoint yang salah dan paket berikutnya dibatalkan.
Solusi
Jangan gunakan fitur Google Cloud yang mengandalkan penyadapan paket, seperti endpoint firewall.
Masalah umum untuk instance VM Linux
Berikut adalah masalah umum untuk VM Linux.
VM Ubuntu yang menggunakan Image OS 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 tindakan berikut:
- Update ke versi
20250328.00
paketgoogle-compute-engine
. - Luncurkan instance dari image Ubuntu yang ditawarkan Canonical dengan akhiran versi
v20250530
. Contoh,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
akan menghasilkan elemen .local
yang ditambahkan ke nama host saat FQDN diminta.
Perhatikan bahwa versi 20250501 dari guest-configs
telah memperbaiki masalah ini, tetapi Canonical belum memasukkan perbaikan tersebut ke dalam image mereka.
Solusi
- Ubah file konfigurasi Network Name Resolution
/etc/systemd/resolved.conf.d/gce-resolved.conf
dengan mengubahDomains=local
menjadiDomains=~local
- Jalankan perintah berikut untuk memulai ulang layanan systemd-resolved:
systemctl restart systemd-resolved
- Pastikan
local
dihapus dari jalur penelusuran di/etc/resolv.conf
Konfirmasi FQDN menggunakan perintah
hostname -f
[root@ubuntu2204 ~]# hostname -f ubuntu2204.us-central1-a.c.my-project.internal
VM SUSE Enterprise gagal di-booting setelah mengubah jenis instance
Setelah mengubah jenis instance VM SUSE Linux Enterprise, VM tersebut dapat gagal di-booting dengan error berikut yang terlihat berulang di konsol serial:
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
gambar awal. Namun, saat kernel baru diinstal atau initramfs
dibuat ulang, yang terjadi selama update sistem, tanda ini dihilangkan secara default.
Hal ini akan menghasilkan initramfs
yang lebih kecil dan disesuaikan secara khusus untuk hardware sistem saat ini, yang berpotensi mengecualikan driver yang diperlukan untuk jenis instance lainnya.
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
VM penyelamat sementara. Gunakan perintah chroot
untuk
mengakses boot disk VM 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
VM Z3 pada image SUSE Linux Enterprise Server (SLES) 12 memiliki performa IOPS yang jauh lebih rendah dari yang diharapkan pada disk SSD Lokal.
Akar masalah
Masalah ini ada dalam codebase SLES 12.
Solusi
Patch dari SUSE untuk memperbaiki masalah ini tidak tersedia atau direncanakan. Sebagai gantinya, Anda harus menggunakan sistem operasi SLES 15.
VM RHEL 7 dan CentOS kehilangan akses jaringan setelah dimulai ulang
Jika VM CentOS atau RHEL 7 Anda memiliki beberapa kartu antarmuka jaringan (NIC) dan salah satu NIC ini tidak menggunakan antarmuka VirtIO, akses jaringan mungkin hilang saat VM di-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 VM hingga masalah teratasi. Hilangnya konektivitas jaringan dapat dicegah agar tidak terjadi lagi dengan melakukan hal berikut:
Edit file
/etc/default/grub
dan hapus parameter kernelnet.ifnames=0
danbiosdevname=0
.Buat ulang konfigurasi grub.
Mulai ulang VM.
Terselesaikan: Symlink tidak ada untuk perangkat SSD Lokal di VM C3 dan C3D yang menjalankan SUSE Linux
Masalah berikut telah diselesaikan pada 13 Januari 2025.
Image SUSE publik tidak menyertakan konfigurasi udev yang diperlukan untuk membuat symlink bagi perangkat SSD Lokal C3 dan C3D. Google Cloud
Resolusi
Guna menambahkan aturan udev untuk SUSE dan image kustom, lihat Symlink tidak dibuat untuk C3 dan C3D dengan SSD Lokal.
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 yum repository
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,
VM 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:
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
Ubah semua baris yang bertuliskan
repo_gpgcheck=1
menjadirepo_gpgcheck=0
.sudo sed -i 's/repo_gpgcheck=1/repo_gpgcheck=0/g' /etc/yum.repos.d/google-cloud.repo
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 VM Windows
- Dukungan untuk NVMe di Windows yang menggunakan driver Community NVMe masih dalam versi Beta, performanya mungkin tidak sama dengan instance Linux. Driver Community NVMe telah diganti dengan driver Microsoft StorNVMe di image publik Google Cloud . Sebaiknya ganti driver NVME pada VM yang dibuat sebelum Mei 2022 dan gunakan 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 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.
Windows Server 2025 dan Windows 11 24h2 - Dukungan penangguhan dan pelanjutan
Windows Server 2025 dan Windows 11 24h2 tidak dapat dilanjutkan saat ditangguhkan. Hingga masalah ini teratasi, fitur penangguhan dan pelanjutan tidak akan didukung untuk Windows Server 2025 dan Windows 11 24h2.
Error saat mengukur penyimpangan waktu NTP menggunakan w32tm di VM Windows
Untuk VM Windows di Compute Engine yang menjalankan NIC VirtIO, ada bug yang diketahui saat mengukur penyimpangan NTP menghasilkan error saat menggunakan perintah berikut:
w32tm /stripchart /computer:metadata.google.internal
Errornya 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 VM Compute Engine dengan NIC VirtIO. VM yang menggunakan gVNIC tidak mengalami masalah ini.
Untuk menghindari masalah ini, Google merekomendasikan penggunaan alat pengukur penyimpangan NTP lainnya, seperti Meinberg Time Server Monitor.
Perangkat boot tidak dapat diakses setelah mengupdate VM dari VM Gen 1 atau 2 ke VM Gen 3+
Windows Server mengikat drive boot ke jenis antarmuka disk awalnya saat pertama kali dimulai. Untuk mengubah VM yang ada dari seri mesin lama yang menggunakan antarmuka disk SCSI ke seri mesin baru yang menggunakan antarmuka disk NVMe, lakukan sysprep driver PnP Windows sebelum mematikan VM. Sysprep ini hanya menyiapkan driver perangkat dan memverifikasi bahwa semua jenis antarmuka disk dipindai untuk drive booting pada saat mulai berikutnya.
Untuk mengupdate seri mesin VM, lakukan langkah berikut:
Dari perintah Powershell sebagai Administrator
, jalankan:
PS C:\> start rundll32.exe sppnp.dll,Sysprep_Generalize_Pnp -wait
- Menghentikan VM.
- Ubah VM ke jenis mesin VM baru.
- Mulai VM.
Jika VM baru tidak dimulai dengan benar, ubah VM kembali ke jenis mesin asli agar VM Anda dapat berjalan kembali. Aplikasi akan berhasil dimulai. Tinjau persyaratan migrasi untuk memverifikasi bahwa Anda memenuhinya. Kemudian, coba lagi petunjuknya.
Bandwidth terbatas dengan gVNIC di VM Windows
Driver gVNIC yang dikemas pada image Windows yang ditawarkan oleh Compute Engine dapat mencapai bandwidth jaringan hingga 50 Gbps pada Instance Windows, untuk performa jaringan standar dan performa jaringan per VM Tier_1. Driver gVNIC versi terbaru dapat memberikan performa kecepatan saluran (hingga 200 Gbps) dan dukungan untuk frame Jumbo.
Driver yang diperbarui hanya tersedia untuk seri mesin generasi ketiga dan yang lebih baru (kecuali N4). Untuk mengetahui informasi selengkapnya, lihat Memperbarui versi gVNIC di Windows OS.
Pemasangan jumlah disk terbatas untuk seri mesin VM yang lebih baru
VM yang berjalan di Microsoft Windows dengan antarmuka disk NVMe, yang mencakup T2A dan semua VM generasi ketiga, memiliki batas pemasangan disk sebanyak 16 disk. Batasan ini tidak berlaku untuk VM generasi keempat (c4, m4). Untuk menghindari error, gabungkan penyimpanan Persistent Disk dan Hyperdisk Anda hingga maksimum 16 disk per VM. Penyimpanan SSD lokal tidak termasuk dalam masalah ini.
Mengganti driver NVME pada VM yang dibuat sebelum Mei 2022
Jika ingin menggunakan NVMe pada VM yang menggunakan Microsoft Windows, dan VM 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 VM sebelum mengubah jenis mesin menjadi seri mesin generasi ketiga, atau sebelum membuat snapshot boot disk yang akan digunakan untuk membuat VM baru yang menggunakan seri mesin generasi ketiga.
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 SSD Lokal di Microsoft Windows dengan VM C3 dan C3D
Performa SSD Lokal dibatasi untuk VM C3 dan C3D yang menjalankan Microsoft Windows.
Peningkatan performa sedang berlangsung.
Throughput jaringan buruk saat menggunakan gVNIC
VM 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:
Periksa versi driver yang terinstal pada VM dengan menjalankan perintah berikut dari sesi Command Prompt atau Powershell administrator:
googet installed
Outputnya terlihat mirip dengan yang berikut ini:
Installed packages: ... google-compute-engine-driver-gvnic.x86_64 VERSION_NUMBER ...
Jika versi driver
google-compute-engine-driver-gvnic.x86_64
adalah1.0.0@44
atau yang lebih lama, update repositori paket GooGet dengan menjalankan perintah berikut dari sesi Command Prompt atau Powershell administrator:googet update
Jenis mesin vCPU C4, C4D, dan C3D besar tidak mendukung image OS Windows
Jenis mesin C4 dengan lebih dari 144 vCPU serta jenis mesin C4D dan C3D dengan lebih dari 180 vCPU tidak mendukung image OS Windows Server 2012 dan 2016. Jenis mesin C4, C4D, dan C3D yang lebih besar yang menggunakan image OS Windows Server 2012 dan 2016 akan gagal di-booting. Untuk mengatasi masalah ini, pilih jenis mesin yang lebih kecil atau gunakan OS image lain.
VM 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.
VM C4D yang dibuat dengan lebih dari 255 vCPU dan 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 VM M3, C3, C3D, dan C4D
Saat ini, kemampuan untuk menambahkan atau mengubah ukuran Hyperdisk atau Persistent Disk untuk VM 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 varian Windows non-server yang terkait, tidak merespons perintah pemasangan disk dan pengubahan ukuran disk dengan benar.
Misalnya, mengeluarkan disk dari VM M3 yang berjalan akan memutuskan koneksi disk dari instance Windows Server tanpa sistem operasi Windows mengenali bahwa disk telah hilang. Penulisan berikutnya ke disk akan menampilkan error umum.
Resolusi
Anda harus memulai ulang VM M3, C3, C3D, atau C4D yang berjalan di Windows setelah mengubah Hyperdisk atau Persistent Disk agar modifikasi disk dapat dikenali oleh tamu tersebut.