[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-01。"],[],[],null,["vSphere feature incompatibility\n\nThis section describes the vSphere features that are incompatible with Google Distributed Cloud.\n\nVM snapshot\n\n[VM\nsnapshot](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-CA948C69-7F58-4519-AEB1-739545EA94E5.html)\nis not compatible with Google Distributed Cloud. Taking snapshots of VMs created\nby Google Distributed Cloud will break many features including cluster upgrade,\ncluster update, [node auto-repair](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/node-auto-repair) and\n[admin cluster control plane\nrecovery](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/repair-admin-control-plane). When\nGoogle Distributed Cloud tries to manage a VM with snapshots, you will see\nfailures such as `Invalid configuration for device '0'` in the\n`csi-controller-manager` and `vsphere-controller-manager` logs. For more information on snapshots, see [Best Practices for using\nVMware snapshots](https://kb.vmware.com/s/article/1025279).\n\nDon't create snapshots on Google Distributed Cloud VMs. To recover from VM or storage failures,\nsee [Recovery from VM\nfailures](/kubernetes-engine/distributed-cloud/vmware/docs/concepts/high-availability-disaster-recovery#recovery_from_vm_failures)\nand [Recovery from storage\nfailures](/kubernetes-engine/distributed-cloud/vmware/docs/concepts/high-availability-disaster-recovery#recovery_from_storage_failures).\n| **Note:** Using a third-party solution, such as Commvault, to back up VMs isn't supported by Google Distributed Cloud. Backing up VMs with a third-party solution may lead to unforeseen errors in cluster operations.\n\nVM clone\n\n[Cloning a\nVM](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-1E185A80-0B97-4B46-A32B-3EF8F309BEED.html)\nthat is created and managed by Google Distributed Cloud may result in data and\ncluster state inconsistencies.\n\nDon't clone Google Distributed Cloud VMs. To recover from VM or storage failures, see [Recovery\nfrom VM\nfailures](/kubernetes-engine/distributed-cloud/vmware/docs/concepts/high-availability-disaster-recovery#recovery_from_vm_failures)\nand [Recovery from storage\nfailures](/kubernetes-engine/distributed-cloud/vmware/docs/concepts/high-availability-disaster-recovery#recovery_from_storage_failures).\n\nvSAN File Service\n\n[Using vSAN File Service to Provision File Volumes](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.storage.doc/GUID-C3C722F2-02E0-45BB-B005-E3A8AB03FFA7.html)\nsupports `ReadWriteMany` or `ReadOnlyMany` persistent volumes that can be shared between multiple pods or applications.\n\nDon't use that in Google Distributed Cloud as it may block node drain and fail the diagnose.\n\nYou can run the following command to list all PVCs: \n\n```\nkubectl --kubeconfig CLUSTER_KUBECONFIG get pvc --all-namespaces \\\n -ojson | jq '.items[] | {namespace: .metadata.namespace, name: .metadata.name, accessModes: .spec.accessModes}'\n```\n\nIf there is any PVC having `ReadWriteMany` or `ReadOnlyMany` in its `accessModes`, contact Google support for a workaround.\n\nStorage vMotion\n\n[Storage\nvMotion](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vcenterhost.doc/GUID-A15EE2F6-AAF5-40DC-98B7-0DF72E166888.html)\nlets you migrate the virtual disks of a VM from one datastore to another.\nThis is different from the regular\n[vMotion](/kubernetes-engine/distributed-cloud/vmware/docs/concepts/high-availability-disaster-recovery#vsphere_ha_and_vmotion),\nwhich migrates a VM from one host to another. vMotion is supported by\nGoogle Distributed Cloud.\n\nStorage vMotion is only compatible with Google Distributed Cloud when the clusters are\nconfigured with [storage policies](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/configure-storage-policy).\nOtherwise, operations such as cluster update, upgrade, user cluster creation and [node\nauto-repair](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/node-auto-repair) will fail when you use storage vMotion.\n\nTo recover from unplanned storage vMotion migration, or to plan a workaround, contact Google support.\n\nStorage DRS\n\n[Storage\nDRS](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.resmgmt.doc/GUID-827DBD6D-08B7-4411-9214-9E126671457F.html)\nmanages virtual machine disk placement and migration to balance the storage\nspace or I/O resources between datastores in the datastore cluster.\n\nDon't activate Storage DRS as it is not compatible with Google Distributed Cloud.\n\nChanged Block Tracking(CBT)\n\n[Changed Block\nTracking(CBT)](https://kb.vmware.com/s/article/1020128) is a\nVMkernel feature that identifies blocks of data that have changed or are in use,\nwhich is enabled through VMware API calls by 3rd-party backup software or\nappliances.\n\nDon't use 3rd-party backup software or appliances to backup\nGoogle Distributed Cloud VMs. They usually enable CBT through the VMware API that is\nnot compatible with Google Distributed Cloud.\n\nNetworking incompatibility\n\nThis section applies to you if you are using the [Seesaw load balancer](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/user-cluster-configuration-file-latest#loadbalancer-seesaw-section).\n\nCisco ACI with Dataplane IP Learning [Cisco Application Centric Infrastructure (ACI)](https://www.cisco.com/site/us/en/products/networking/cloud-networking/application-centric-infrastructure/index.html) with [Dataplane IP Learning](https://www.cisco.com/c/en/us/td/docs/dcn/aci/apic/5x/l3-configuration/cisco-apic-layer-3-networking-configuration-guide-51x/m_dataplane_ip_learning_v2.pdf) is incompatible with Seesaw and MetalLB load balancers. We recommend that you use [manual load balancing](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/manual-load-balance), or disable Dataplane IP Learning when using Seesaw or MetalLB as your load balancer. Additionally, Seesaw is in maintenance mode. As of Google Distributed Cloud version 1.32, upgrades are blocked for clusters using Seesaw. You must [migrate clusters to\nrecommended features](/kubernetes-engine/distributed-cloud/vmware/docs/concepts/migrate-recommended-features) before upgrading to 1.32.\n\nStateful NSX-T Distributed Firewall (DFW)\n\nStateful [NSX-T\nDFW](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.2/administration/GUID-6AB240DB-949C-4E95-A9A7-4AC6EF5E3036.html)\nis not compatible with the Seesaw load balancer. We recommend that you use\nMetalLB as your load balancer as Seesaw is in maintenance mode, or configure a\nstateless NSX-T DFW policy for the Seesaw VMs when using Seesaw as your load\nbalancer. For more information, see [Configuring stateless NSX-T distributed\nfirewall policies for use with Seesaw load\nbalancer](/anthos/clusters/docs/on-prem/1.16/how-to/bundled-load-balance#configuring_stateless_nsx-t_distributed_firewall_policies_for_use_with_seesaw_load_balancer) in the version 1.16 documentation."]]