Masalah umum
Halaman ini menjelaskan masalah umum yang mungkin Anda temui saat menggunakan Google Cloud VMware Engine.
Masalah umum
Berikut adalah masalah umum yang diketahui dan memengaruhi VMware Engine.
Alarm error pNIC vCenter bawaan dipicu oleh peristiwa jaringan sementara
Masalah: Alarm infrastruktur vCenter bawaan—seperti "High pNIC error rate detected"—dapat dipicu secara berkala di konsol Klien vSphere karena anomali paket lokal sementara.
Detail: Framework pemberitahuan VMware bawaan mengevaluasi penghitung kartu antarmuka jaringan fisik (pNIC) yang mendasarinya selama periode sampling yang singkat dan kaku. Karena desain ini, vCenter dapat memicu pemberitahuan langsung untuk peristiwa rutin yang tidak berdampak—seperti gangguan sementara atau perilaku penurunan paket yang diharapkan pada uplink vSAN siaga—bahkan saat lapisan jaringan dalam kondisi baik. Karena redundansi jalur bawaan, pemberitahuan ini tidak memengaruhi ketersediaan lingkungan atau integritas data.
Solusi: Tidak ada tindakan atau solusi yang diperlukan pelanggan. Karena update pada sensitivitas sampling alarm vCenter bawaan tidak diharapkan dalam jangka pendek, Google telah men-deploy kecerdasan platform yang mendasarinya untuk mengelola dan memfilter positif palsu ini. Untuk lingkungan produksi yang ditargetkan, Google menekan pemberitahuan konsol bawaan yang ditampilkan kepada pelanggan ini. Sebagai gantinya, mesin analisis Google memantau data infrastruktur dan mengevaluasi lapisan fisik secara terus-menerus menggunakan rata-rata bergulir 30 menit. Jika mesin analisis Google mengidentifikasi degradasi fisik yang persisten, seperti kabel atau optik yang rusak, platform akan otomatis memberi tahu dukungan Google untuk menyelidiki dan menyelesaikan masalah tersebut, serta secara sistematis mengirimkan notifikasi otomatis kepada Anda.
Status: Ini adalah batasan yang diketahui dari logika evaluasi alarm vCenter bawaan logic. Google mengelola perilaku ini melalui kecerdasan platform bawaan yang terintegrasi. VMware mengetahui masalah ini dan telah memberikan saran terkait solusinya.
Upgrade HCX Manager salah diberi label sebagai upgrade versi vSphere
Masalah: Upgrade HCX Manager salah diberi label sebagai "vSphere version upgrade" di Google Cloud konsol.
Detail: Meskipun notifikasi email tertentu yang mengidentifikasi upgrade HCX dikirim setidaknya 14 hari dan 24 jam sebelum peristiwa tersebut, notifikasi otomatis "Your Private Cloud update has started" dan "Your Private Cloud update has completed" mencerminkan update cloud pribadi umum. Selain itu, antarmuka konsol secara eksplisit memberi label operasi sebagai upgrade versi vSphere.Google Cloud Ketidakcocokan ini dapat menyebabkan kebingungan, terutama bagi pelanggan yang baru saja menyelesaikan upgrade stack lengkap (misalnya, vSphere 7.x ke 8.x), karena lingkungan tersebut tampaknya sedang menjalani update platform utama lainnya.
Solusi: Tinjau email notifikasi khusus HCX yang dikirim sebelum periode pemeliharaan untuk mengonfirmasi cakupan pekerjaan. Jika jadwalnya sesuai, status "vSphere version upgrade" di Google Cloud konsol hanya merujuk ke update HCX Manager. Tidak ada tindakan yang diperlukan.
Status: Ini adalah batasan yang diketahui dari desain sistem notifikasi saat ini.
Waktu penyediaan untuk cloud pribadi vSphere 8.0 update 3
Masalah: VMware Engine kini men-deploy cloud pribadi baru dengan VMware vSphere versi 8.0 Update 3 dan NSX-T 4.2.1.2. Selama periode upgrade ini, pembuatan dan perluasan cloud pribadi menggunakan kecepatan penyediaan standar untuk semua deployment baru dengan versi yang diupdate.
Detail: Pembuatan cloud pribadi dapat memerlukan waktu hingga 140 menit.
Solusi: Tidak ada solusi yang diperlukan, tetapi rencanakan waktu tambahan saat Anda men-deploy cloud pribadi baru atau memperluas cluster yang ada.
Deteksi: Anda mungkin mengamati waktu deployment yang lebih lama dari biasanya untuk cloud pribadi baru atau saat Anda memperluas cluster yang ada.
Status: Perilaku ini diharapkan karena update versi dan upgrade yang sedang berlangsung.
Virtual Machine dengan Windows Server 2022 KB5022842 (Build OS 20348.1547) yang dikonfigurasi dengan booting aman diaktifkan tidak melakukan booting (90947)
Setelah menginstal update Windows Server 2022 KB5022842 (Build OS 20348.1547) OS tamu tidak dapat melakukan booting saat virtual machine dikonfigurasi dengan booting aman diaktifkan. Untuk mengatasi masalah ini, Anda dapat melakukan salah satu hal berikut:
Ada batas 100 awalan untuk pemberitahuan rute dari cloud pribadi ke jaringan VPC
Jika pemberitahuan rute Anda melebihi batas ini, beberapa awalan mungkin akan dihilangkan. Untuk tetap berada dalam batas ini, terapkan agregasi di NSX-T Edge.
VMware Engine mengandalkan Cloud Router untuk mengiklankan rentang alamat IP (awalan atau CIDR) dari NSX ke jaringan VPC produsen layanan. Awalan ini menjadi rute dinamis kustom di jaringan VPC produsen layanan yang di-peering dengan jaringan VPC Anda.
Saat Anda mengonfigurasi jaringan VPC untuk mengimpor rute dinamis kustom dalam hubungan peering ini, awalan NSX akan melakukan peering rute kustom di jaringan VPC Anda. Jumlah awalan NSX yang dapat Anda impor dibatasi oleh dua faktor:
- Batas default Cloud Router untuk jumlah awalan unik per region, yang diwarisi oleh VMware Engine
- Jumlah maksimum rute dinamis dalam grup peering di jaringan VPC Anda
Operasi cloud pribadi yang dicoba sebelum cloud pribadi di-deploy sepenuhnya akan gagal
Operasi seperti peningkatan hak istimewa, perluasan cloud pribadi, dan penggantian node diizinkan di portal Google Cloud VMware Engine pada cloud pribadi operasional yang belum disediakan sepenuhnya. Namun, jika Anda mencoba operasi ini di VMware Engine sebelum cloud pribadi di-deploy sepenuhnya (termasuk NSX-T dan HCX), operasi ini akan gagal. Jangan mencoba operasi ini hingga Anda telah men-deploy cloud pribadi sepenuhnya.
VMware Engine belum didukung sepenuhnya oleh Kontrol Layanan VPC
Kontrol Layanan VPC menerapkan solusi sementara (solusi) agar Anda tetap dapat menggunakan VMware Engine dari dalam project di perimeter Kontrol Layanan VPC. Lihat Kontrol Layanan VPC untuk mengetahui informasi selengkapnya.
Interoperabilitas Apigee dengan perutean internet lokal
Jika Anda menggunakan Apigee dengan peering VPC di jaringan VPC yang sama dengan VMware Engine, dan Anda mengonfigurasi VMware Engine untuk merutekan traffic internet melalui koneksi lokal, komunikasi keluar Apigee mungkin juga dirutekan melalui koneksi lokal Anda.
Konfigurasi ini terjadi saat Anda mengaktifkan Kontrol Layanan VPC pada
servicenetworking.googleapis.com peering seperti yang dijelaskan dalam
Mengonfigurasi akses internet untuk VM workload.
Jika traffic Apigee dirutekan melalui koneksi lokal Anda, Apigee tidak lagi menggunakan alamat IP eksternal yang dikonfigurasi untuk komunikasi keluar ke layanan backend API eksternal. Jika Anda mengandalkan alamat IP eksternal Apigee untuk konfigurasi firewall, Anda harus mengupdate konfigurasi firewall untuk mengizinkan traffic dari jaringan lokal Anda.
Host ESXi mungkin kehilangan konektivitas sementara selama pengumpulan informasi diagnostik
Host ESXi di lingkungan dengan perangkat NVMe PCIe mungkin kehilangan konektivitas sementara selama pengumpulan informasi diagnostik.
Akar masalah
Saat Anda menggunakan perintah vm-support atau UI vCenter untuk mengumpulkan informasi tentang sistem ESXi, log akan disimpan sementara di direktori ramdisk /tmp. Jika sistem memiliki banyak perangkat NVMe PCIe atau file log berukuran besar, direktori ramdisk /tmp akan cepat penuh, yang dapat menyebabkan host ESXi kehilangan konektivitas sementara hingga pengumpulan vm-support selesai.
Solusi:
Mengecualikan manifes NVME dari bagian log yang dipilih di halaman pembuatan paket log akan mencegah direktori ramdisk /tmp menjadi penuh dan memverifikasi bahwa host EXSi tidak kehilangan konektivitas jaringan. Untuk mengecualikan manifes NVMe, lakukan hal berikut:
- Login ke vCenter menggunakan nama pengguna dan sandi
cloudowner. - Di inventaris, klik kanan instance vCenter Server tempat Anda ingin melakukan pengecualian.
- Klik Export System Logs....
- Pilih host ESXi yang log paketnya ingin Anda kecualikan.
- Di bagian Select Logs, scroll ke Storage dan hapus centang opsi NVMe, lalu klik Exported logs. Manifes NVMe kini dikecualikan.
Untuk mengetahui informasi selengkapnya tentang perbaikan ini, lihat VMware ESXi 7.0 Update 3q.
Error terjemahan nama resource cloud pribadi
Jika Anda menjalankan VMware Engine Horizon (VDI) di Google Cloud VMware Engine, Anda mungkin mengalami error setelah mengubah penamaan resource cloud pribadi untuk memenuhi standar Google Cloud CLI dan VMware Engine API.
Contoh error berikut terjadi saat mengubah nama resource cloud pribadi tanpa mengedit Penyediaan Kumpulan Desktop Horizon dengan benar:
Error during Provisioning Cloning of VM Desktop-UK-005 has failed. No resource pool available for the pool: ic-pool-1
Error during Provisioning Cloning of VM Desktop-UK-005 has failed. No datastores available for the pool: {}ic-pool-1
Untuk mengatasi masalah ini, selesaikan langkah-langkah berikut sebelum tanggal terjemahan nama terjadwal:
- Akses dasbor VMware Horizon.
- Edit semua Kumpulan Desktop Horizon untuk Kumpulan Klon Penuh dan Kumpulan Klon Instan, lalu tetapkan ke Disable Provisioning.
Setelah perubahan nama resource cloud pribadi selesai, selesaikan langkah-langkah berikut:
Edit setiap Kumpulan Desktop dan konfigurasi ulang setelan berikut di tab vCenter Settings untuk Kumpulan Klon Penuh dan Kumpulan Klon Instan:
- Kumpulan Resource
- Datastore
Tetapkan kembali status setiap Kumpulan ke Enable Provisioning.
Uji setiap kumpulan dengan menambahkan atau menghapus desktop dari Kumpulan untuk memverifikasi bahwa penyediaan berfungsi dengan benar.
Tim VMware Engine aktif berupaya memberikan solusi interoperabilitas sesegera mungkin. Untuk mengetahui informasi terbaru tentang ketersediaan fitur, hubungi tim akun Anda.