Masalah umum

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

Masalah umum

Masalah berikut memberikan panduan pemecahan masalah atau informasi umum.

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:

Batasan saat menggunakan jenis mesin c3-standard-*-lssd dan c3d-standard-*-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 C3 dan 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 dokumen Kelompok mesin tujuan umum untuk memilih jumlah disk SSD Lokal yang benar berdasarkan jenis mesin lssd C3 atau C3D.

Penggunaan Konsol Google Cloud Google Kubernetes Engine untuk membuat cluster atau node pool dengan VM 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 konsol Google 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:

Pengurangan atau penghapusan pemesanan tertentu akan menghentikan VM menggunakan pemesanan lainnya

Jika Anda mengurangi ukuran atau menghapus pemesanan tertentu yang digunakan oleh satu atau beberapa VM, VM tanpa induk tidak dapat menggunakan pemesanan apa pun.

Pelajari lebih lanjut cara menghapus pemesanan dan mengubah ukuran pemesanan.

Memindahkan VM atau disk menggunakan moveInstance API atau gcloud CLI menyebabkan perilaku yang tidak terduga

Memindahkan instance virtual machine (VM) menggunakan perintah gcloud compute instances move atau metode project.moveInstance dapat menyebabkan hilangnya data, penghapusan VM, atau perilaku tak terduga lainnya.

Untuk memindahkan VM, sebaiknya ikuti petunjuk di bagian Memindahkan instance VM antar-zona atau antar-region.

Disk yang terpasang ke VM dengan jenis mesin n2d-standard-64 tidak mencapai batas performa secara konsisten

Persistent disk yang terpasang ke VM dengan jenis mesin n2d-standard-64 tidak secara konsisten mencapai batas performa maksimum 100.000 IOPS. Ini adalah kasus untuk IOPS baca dan tulis.

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.

  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 VM Linux

Berikut adalah masalah umum untuk VM Linux.

SUSE Enterprise VM gagal melakukan booting setelah mengubah jenis instance

Setelah mengubah jenis instance VM SUSE Linux Enterprise, VM dapat gagal melakukan 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, flag ini 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 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, pertimbangkan untuk menggunakan konsol serial atau VM penyelamatan sementara untuk mengakses sistem dan membuat ulang initramfs menggunakan perintah berikut:

dracut -f --no-hostonly -v /boot/initramfs-$(uname -r).img $(uname -r)

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

Ini adalah masalah 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.

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 akan hilang saat dimulai ulang. 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: 1. Edit file /etc/default/grub dan hapus parameter kernel net.ifnames=0 dan biosdevname=0. 2. Buat ulang konfigurasi grub. 3. Mulai ulang VM.

Image Google Cloud SUSE publik tidak menyertakan konfigurasi udev yang diperlukan untuk membuat symlink bagi perangkat SSD Lokal C3 dan C3D.

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 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, 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:

  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 VM Windows

  • Dukungan untuk NVMe di Windows yang menggunakan driver Community NVMe masih dalam versi Beta, performanya mungkin tidak cocok dengan instance Linux. Driver Community NVMe telah diganti dengan driver Microsoft StorNVMe di image publik Google Cloud. Sebaiknya Anda mengganti driver NVME pada VM 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 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.

Error saat mengukur drift waktu NTP menggunakan w32tm di VM Windows

Untuk VM Windows di Compute Engine yang menjalankan VirtIO NIC, ada bug umum saat pengukuran drift NTP menghasilkan error saat menggunakan perintah berikut:

w32tm /stripchart /computer:metadata.google.internal

Error tersebut akan terlihat mirip dengan yang berikut ini:

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 pengukuran drift NTP lainnya, seperti Meinberg Time Server Monitor.

Perangkat booting tidak dapat diakses setelah mengupdate VM dari Gen 1 atau 2 ke VM Gen 3+

Windows Server mengikat drive booting ke jenis antarmuka disk awalnya saat startup pertama. Untuk mengubah VM yang ada dari seri mesin lama yang menggunakan antarmuka disk SCSI ke seri mesin yang lebih baru yang menggunakan antarmuka disk NVMe, lakukan sysprep driver PnP Windows sebelum menonaktifkan VM. Sysprep ini hanya menyiapkan driver perangkat dan memastikan semua jenis antarmuka disk dipindai untuk drive booting pada pengaktifan 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
  1. Menghentikan VM.
  2. Ubah VM ke jenis mesin VM baru.
  3. Mulai VM.

Jika VM baru tidak dimulai dengan benar, ubah VM kembali ke jenis mesin asli agar VM dapat berjalan lagi. Aplikasi akan berhasil dimulai. Tinjau persyaratan migrasi untuk memastikan Anda memenuhinya. Kemudian, coba lagi petunjuknya.

Bandwidth terbatas dengan gVNIC di VM Windows

Driver gVNIC yang dipaketkan pada image Windows yang ditawarkan oleh Compute Engine dapat mencapai bandwidth jaringan hingga 50 Gbps pada Instance Windows, baik untuk performa jaringan standar maupun performa jaringan per VM Tier_1. Driver gVNIC versi terbaru dapat memberikan performa kecepatan linier (hingga 200 Gbps) dan dukungan untuk frame Jumbo.

Driver yang diperbarui hanya tersedia untuk seri mesin generasi ketiga dan yang lebih baru (tidak termasuk N4). Untuk informasi selengkapnya, lihat Memperbarui versi gVNIC di OS Windows.

Jumlah lampiran disk terbatas untuk seri mesin VM yang lebih baru

VM yang berjalan di Microsoft Windows dengan antarmuka disk NVMe, (yang mencakup VM generasi ketiga dan yang lebih baru, serta VM yang menggunakan Confidential Computing), memiliki batas lampiran disk sebanyak 16 disk. Untuk menghindari error, gabungkan penyimpanan Hyperdisk dan Persistent Disk Anda hingga maksimum 16 disk per VM. Penyimpanan SSD lokal dikecualikan dari 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:

  1. 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
  ...

  2. Jika versi driver google-compute-engine-driver-gvnic.x86_64 adalah 1.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 C3D 180 dan 360 tidak mendukung image OS Windows

Jenis mesin vCPU C3D 180 tidak mendukung image OS Windows Server 2012 dan 2016. VM C3D yang dibuat dengan 180 vCPU dan 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.

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

Saat ini, kemampuan untuk menambahkan atau mengubah ukuran Hyperdisk atau Persistent Disk untuk VM M3, C3, atau C3D 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, atau C3D yang berjalan di Windows setelah mengubah Hyperdisk atau Persistent Disk agar modifikasi disk dapat dikenali oleh tamu tersebut.