Known issues

This page describes known issues that you might run into while using Google Cloud VMware Engine.

General issues

The following are known general issues affecting VMware Engine.

Virtual Machine with Windows Server 2022 KB5022842 (OS Build 20348.1547) configured with secure boot enabled not booting up (90947)

After installing Windows Server 2022 update KB5022842 (OS Build 20348.1547) guest OS can't boot up when the virtual machine(s) is configured with secure boot enabled. To work around this issue, you can do one of the following:

There is a 100 prefix limit for route advertisements from your private cloud to your VPC network

If your route advertisement exceeds this limit, some prefixes may be dropped. To stay within this limit, implement aggregation on NSX-T Edge.

VMware Engine relies on Cloud Routers to advertise IP address ranges (prefixes or CIDRs) from NSX to a service producer VPC network. These prefixes become custom dynamic routes in the service producer VPC network that is peered with your VPC network.

When you configure your VPC network to import custom dynamic routes in this peering relationship, the NSX prefixes peer custom routes in your VPC network. The number of NSX prefixes you can import is limited by two factors:

Private cloud operations attempted before the private cloud is fully deployed fail

Operations such as privilege escalation, private cloud expansion, and node replacement are allowed in the Google Cloud VMware Engine portal on operational private clouds that are not fully provisioned yet. However, if you attempt these operations in VMware Engine before the private cloud is fully deployed (including NSX-T and HCX), these operations fail. Don't attempt these operations until you have fully deployed your private cloud.

VMware Engine is not yet fully [supported by VPC Service Controls][vpc sc supported products]

VPC Service Controls implements an interim solution (workaround) to allow you to still consume VMware Engine from within a project in a VPC Service Controls perimeter. See VPC Service Controls for more information.

ESXi hosts might temporarily lose connectivity during collection of diagnostic information

ESXi hosts in environments with NVMe PCIe devices might temporarily lose connectivity during the collection of diagnostic information.

Root cause

When you use the vm-support command or vCenter UI to collect information about ESXi systems, logs are temporarily stored in the ramdisk /tmp directory. If the system has many NVMe PCIe devices or the log file is large, the ramdisk /tmp directory quickly becomes full, which can lead to your ESXi host to temporarily lose connectivity until the vm-support collection completes.

Workaround:

Excluding the NVME manifest from the select logs section in the log bundle creation page prevents the ramdisk /tmp directory from becoming full and ensures that the EXSi host doesn't lose network connectivity. To exclude the NVMe manifest, do the following:

  1. Sign in to vCenter using the cloudowner username and password.
  2. In the inventory, right-click the vCenter Server instance where you want the exclusion.
  3. Click Export System Logs....
  4. Select the ESXi host that you want to exclude the logs bundle from.
  5. Under Select Logs, scroll to Storage and clear the NVMe option, then click Exported logs. The NVMe manifest is now excluded.

For more information on this fix, see VMware ESXi 7.0 Update 3q.

Private cloud resource name translation error

If you are running VMware Engine Horizon (VDI) on Google Cloud VMware Engine, you may encounter errors after changing your private cloud resource naming to meet the standards for Google Cloud CLI and VMware Engine API.

The following example error occurs when changing private cloud resource names without editing properly provisioning Horizon Desktop Pools:

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

To resolve this issue, complete the following steps before your scheduled name translation date:

  1. Access the VMware Horizon dashboard.
  2. Edit all Horizon Desktop Pools for both Full Clone and Instant Clone Pools and set them to Disable Provisioning.

Once the private cloud resource name change is complete, complete the following steps:

  1. Edit each Desktop Pool and reconfigure the following settings on the vCenter Settings tab for both Full Clone and Instant Clone Pools:

    • Resource Pool
    • Datastore

  2. Set each Pool status back to Enable Provisioning.

  3. Test each pool by adding or removing a desktop from the Pool to ensure provisioning is functioning properly.

The VMware Engine team is actively working to provide an interoperability solution as soon as possible. To stay up to date on feature availability, contact your account team.