VM 快照與 Google Distributed Cloud 不相容。如果對 Google Distributed Cloud 建立的 VM 建立快照,會導致許多功能無法正常運作,包括叢集升級、叢集更新、節點自動修復和管理員叢集控制層復原。當 Google Distributed Cloud 嘗試管理含有快照的 VM 時,您會在 Invalid configuration for device '0'、csi-controller-manager 和 vsphere-controller-manager 記錄檔中看到失敗訊息。如要進一步瞭解快照,請參閱「使用 VMware 快照的最佳做法」。
請勿在 Google Distributed Cloud VM 上建立快照。如要從 VM 或儲存空間故障中復原,請參閱「從 VM 故障中復原」和「從儲存空間故障中復原」。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間: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."]]