Masalah umum

Halaman ini menjelaskan masalah umum yang mungkin Anda alami saat menggunakan Google Cloud VMware Engine.

Masalah umum

Berikut adalah masalah umum yang diketahui dan memengaruhi VMware Engine.

Upgrade HCX Manager salah diberi label sebagai upgrade versi vSphere

Masalah: Upgrade HCX Manager salah diberi label sebagai "upgrade versi vSphere" di Google Cloud konsol.

Detail: Meskipun notifikasi email tertentu yang mengidentifikasi upgrade HCX dikirim setidaknya 14 hari dan 24 jam sebelum acara, notifikasi otomatis "Update Cloud Pribadi Anda telah dimulai" dan "Update Cloud Pribadi Anda telah selesai" notifikasi 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 penuh (misalnya, vSphere 7.x ke 8.x), karena lingkungan tampak 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 "upgrade versi vSphere" di Google Cloud konsol hanya merujuk ke update HCX Manager. Anda tidak perlu melakukan tindakan apa pun.

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:

  • Lewati KB5022842 dan gunakan KB5023705
  • Nonaktifkan "Booting Aman" di VM yang terpengaruh

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:

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) untuk memungkinkan Anda tetap 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 untuk sementara selama pengumpulan informasi diagnostik

Host ESXi di lingkungan dengan perangkat NVMe PCIe mungkin kehilangan konektivitas untuk 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 untuk 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:

  1. Login ke vCenter menggunakan nama pengguna dan sandi cloudowner.
  2. Di inventaris, klik kanan instance vCenter Server tempat Anda ingin melakukan pengecualian.
  3. Klik Export System Logs....
  4. Pilih host ESXi yang paket lognya ingin Anda kecualikan.
  5. 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 Horizon Desktop Pools 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:

  1. Akses dasbor VMware Horizon.
  2. Edit semua Horizon Desktop Pools untuk Full Clone dan Instant Clone Pools, lalu tetapkan ke Disable Provisioning.

Setelah perubahan nama resource cloud pribadi selesai, selesaikan langkah-langkah berikut:

  1. Edit setiap Desktop Pool dan konfigurasi ulang setelan berikut di tab vCenter Settings untuk Full Clone dan Instant Clone Pools:

    • Resource Pool
    • Datastore
  2. Tetapkan kembali status setiap Pool ke Enable Provisioning.

  3. Uji setiap pool dengan menambahkan atau menghapus desktop dari Pool 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.