Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

已知問題

本頁列出在 Google Cloud的 VMware 解決方案中，部署及操作 VMware Cloud Foundation (VCF) 的已知問題和解決方法。

部署 VCF 時，主機 vMotion 和 vSAN IP 位址不符

部署 VCF 管理網域時，VCF 安裝程式會依數字遞增順序排序 vMotion 和 vSAN IP 位址集區，並按照 ESXi 主機在 hostSpecs 陣列中顯示的順序，依序指派 IP 位址。建立 VI 工作負載網域或擴充叢集時，SDDC Manager 會從設定的 IP 位址集區分配 vMotion 和 vSAN VMkernel IP 位址，不會保留 hostSpecs 主機順序。

由於 Google Cloud 虛擬私有雲網路會對每個裸機節點的 Dynamic NIC 執行嚴格的來源和目的地 IP 檢查，因此 VCF 指派給主機 vmk1 (vMotion) 或 vmk2 (vSAN) 轉接器的 IP 位址，必須與對應 Compute Engine Dynamic NIC (nic0.VLAN_ID) 上設定的 IP 位址相符。如果主機的 Dynamic NIC IP 位址與 VCF 指派的執行階段 IP 位址不符，Hypervisor 會接收或傳輸 IP 位址不符的流量，導致網路驗證或叢集部署失敗。

舉例來說，假設管理網域部署作業有四個主機，並採用下列 Compute Engine Dynamic NIC 分配：

主機 FQDN	vMotion IP (`vmk1`)	vSAN IP (`vmk2`)	NSX-TEP IP (`vmk10`)
`esxi-h0.40-vmware.gve`	`10.40.2.2`	`10.40.3.2`	`10.40.4.2`
`esxi-h1.40-vmware.gve`	`10.40.2.5`	`10.40.3.5`	`10.40.4.5`
`esxi-h2.40-vmware.gve`	`10.40.2.3`	`10.40.3.3`	`10.40.4.3`
`esxi-h3.40-vmware.gve`	`10.40.2.4`	`10.40.3.4`	`10.40.4.4`

如果主機在輸入設定中的排序為 esxi-h0、esxi-h2、esxi-h1、esxi-h3，VCF 安裝程式會排序集區 (10.40.2.2、10.40.2.3、10.40.2.4、10.40.2.5)，並依序將位址對應至 esxi-h0、esxi-h2、esxi-h1 和 esxi-h3。主機 esxi-h1 會從安裝程式接收 10.40.2.4，即使其基礎 Compute Engine Dynamic NIC 預期為 10.40.2.5。

解決方法：視您要部署新的管理網域，還是擴充現有的工作負載網域或叢集，採用下列任一選項。

選項 1：預先排序管理網域部署作業的主機規格

使用 VMware 解決方案工具包 (self-managed-vmware-solution-toolkit) 時，工具包會自動查詢裸機節點的 Dynamic NIC IP 位址，並在 VCF 部署 JSON 檔案中排序 hostSpecs 和 includeIpAddressRanges 陣列。

如果您手動編寫或修改 VCF 部署 JSON 檔案，請調整 hostSpecs 陣列中的項目順序，使其與分配的 Dynamic NIC IP 位址遞增數字排列順序相符 (以上述範例來說：10.40.2.2 對應 esxi-h0.40-vmware.gve、10.40.2.3 對應 esxi-h2.40-vmware.gve、10.40.2.4 對應 esxi-h3.40-vmware.gve，以及 10.40.2.5 對應 esxi-h1.40-vmware.gve)：

設定 IP 位址集區：視 IP 分配是否連續而定，使用連續範圍或明確 IP 位址指定集區：

連續 IP 範圍：

"includeIpAddressRanges": [
  {
    "startIpAddress": "10.40.2.2",
    "endIpAddress": "10.40.2.5"
  }
]

不連續的 IP 位址：

"includeIpAddress": [
  "10.40.2.2",
  "10.40.2.3",
  "10.40.2.4",
  "10.40.2.5"
]

預先排序 hostSpecs 陣列，讓主機按照分配的 IP 位址遞增排序：

"hostSpecs": [
  {
    "hostname": "esxi-h0.40-vmware.gve"
  },
  {
    "hostname": "esxi-h2.40-vmware.gve"
  },
  {
    "hostname": "esxi-h3.40-vmware.gve"
  },
  {
    "hostname": "esxi-h1.40-vmware.gve"
  }
]

方法 2：在工作負載網域或叢集擴充期間，重新設定 Dynamic NIC

使用 SDDC Manager 部署 VI 工作負載網域或擴充叢集時，請將 vMotion 和 vSAN Dynamic NIC 與 VCF 指派的執行階段 IP 位址進行協調：

在 SDDC Manager 和 vCenter Server 中委託裸機 ESXi 主機，並啟動工作負載網域或叢集建立工作流程。允許工作流程在 vSAN 和 vMotion 連線能力驗證階段暫停或失敗。
使用 SDDC Manager 資料庫或 SDDC Manager REST API，擷取 VCF 分配的執行階段 IP 位址 (或在 vSphere Client 中檢查 VMkernel 轉接器)：
- VCF 資料庫查詢 (在 SDDC Manager 設備上執行)：
```
psql -h localhost -U postgres -d platform -c "select * from host;"
```
- SDDC Manager REST API：
```
curl -u ADMIN_USER:ADMIN_PASSWORD \
   -X GET https://SDDC_MANAGER_FQDN/v1/hosts
```
  執行 curl 指令前，請先替換下列項目：
  - ADMIN_USER：SDDC Manager 管理員使用者名稱。
  - ADMIN_PASSWORD：SDDC Manager 管理員密碼。
  - SDDC_MANAGER_FQDN：SDDC Manager 設備的完整網域名稱或 IP 位址。
請先刪除所有受影響 ESXi 主機上不相符的 Dynamic NIC (nic0.VLAN_ID)。您必須先刪除所有主機的 Dynamic NIC，才能重新新增任何介面。否則，如果其他主機仍持有目標 IP 位址，Compute Engine 會因 IP 位址衝突而拒絕新增介面：
```
gcloud compute instances network-interfaces delete HOST_INSTANCE_NAME \
   --zone=ZONE \
   --network-interface=nic0.VLAN_ID \
   --project=PROJECT_ID
```
從所有主機刪除不相符的 Dynamic NIC 後，請在每部主機上重新新增 Dynamic NIC (nic0.VLAN_ID)，並使用 VCF 指派的確切 IPv4 位址。

注意： --private-network-ip 旗標接受 IPv4 位址或預留內部 IP 位址資源的名稱。如果您使用預留 IP 位址，請指定與 VCF 指派 IP 位址相符的現有預留 IP 位址，該位址原本是預留給其他主機。請勿刪除或重新建立預留的內部 IP 位址資源。
```
gcloud compute instances network-interfaces add HOST_INSTANCE_NAME \
   --zone=ZONE \
   --parent-nic-name=nic0 \
   --vlan=VLAN_ID \
   --subnetwork=SUBNET_NAME \
   --no-address \
   --private-network-ip=VMWARE_ASSIGNED_IP \
   --project=PROJECT_ID
```
執行上述指令前，請先替換下列項目：
- HOST_INSTANCE_NAME：Compute Engine 中裸機 ESXi 執行個體的名稱。
- ZONE：裸機執行個體所在的可用區。
- VLAN_ID：對應至 Dynamic NIC 的 VLAN ID (例如 vSAN 的 2 或 vMotion 的 3)，會形成介面名稱 nic0.VLAN_ID。
- SUBNET_NAME：vSAN 或 vMotion 子網路的名稱。
- VMWARE_ASSIGNED_IP：IPv4 位址或現有的預留內部 IP 位址資源名稱，與 VCF 指派給主機 VMkernel 轉接器的 IP 位址相符。
- PROJECT_ID： Google Cloud 專案的 ID。
在 SDDC Manager 中繼續並完成叢集部署作業。

主機上的 NSX-TEP IP 位址不相符

在 NSX 傳輸節點準備期間，NSX Manager 會從設定的 NSX IP 集區分配傳輸端點 (TEP) IP 位址 (vmk10 或 vmk3) ( Google Cloud VPC 子網路不支援 Dynamic NIC 的 DHCP)。由於 NSX Manager 會從集區隨機指派 IP 位址，因此在 ESXi 主機 vmk10 轉接器上設定的 TEP IP 位址，可能與主機 NSX-TEP Dynamic NIC (nic0.TEP_VLAN_ID) 上預先分配的 IP 位址不符。

解決方法：NSX 傳輸節點設定完成後，請更新主機上的 NSX-TEP Dynamic NIC，以符合 NSX 指派的 TEP IP 位址：

在 NSX Manager UI (在 VCF 9.1 中，依序前往「System」(系統) >「Fabric」(網狀架構) >「Hosts」(主機)) 或 vSphere Client 中，檢查指派給各 ESXi 主機的 TEP IP 位址。

修改 NSX-TEP 網路介面前，請先從 NSX 網路端點群組 (NEG) 移除所有裸機主機執行個體：

gcloud compute network-endpoint-groups update NSX_NEG_NAME \
    --zone=ZONE \
    --project=PROJECT_ID \
    --remove-endpoint="instance=HOST_INSTANCE_NAME"

請先刪除所有受影響主機上的 NSX-TEP Dynamic NIC (nic0.TEP_VLAN_ID)。請先在所有主機上完成所有 NSX-TEP Dynamic NIC 刪除作業，再重新新增任何介面，以免主機之間的 IP 位址發生衝突：
```
gcloud compute instances network-interfaces delete HOST_INSTANCE_NAME \
    --zone=ZONE \
    --network-interface=nic0.TEP_VLAN_ID \
    --project=PROJECT_ID
```
刪除所有主機上的所有 NSX-TEP Dynamic NIC 後，請使用 NSX Manager 指派的 TEP IPv4 位址，在每部主機上重新建立 nic0.TEP_VLAN_ID 介面。

注意： --private-network-ip 旗標接受 IPv4 位址或預留內部 IP 位址資源的名稱。如果您使用保留 IP 位址，請指定與 NSX 指派的 TEP IP 位址相符的現有保留 IP 位址，該位址原本是保留給其他主機。請勿刪除或重新建立預留的內部 IP 位址資源。
```
gcloud compute instances network-interfaces add HOST_INSTANCE_NAME \
    --zone=ZONE \
    --parent-nic-name=nic0 \
    --vlan=TEP_VLAN_ID \
    --subnetwork=TEP_SUBNET_NAME \
    --no-address \
    --private-network-ip=TEP_IP_ADDRESS \
    --project=PROJECT_ID
```

將所有裸機主機執行個體重新附加至 NSX NEG：

gcloud compute network-endpoint-groups update NSX_NEG_NAME \
    --zone=ZONE \
    --project=PROJECT_ID \
    --add-endpoint="instance=HOST_INSTANCE_NAME"

執行上述指令前，請先替換下列項目：

NSX_NEG_NAME：NSX 區域性 NEG 的名稱。
HOST_INSTANCE_NAME：裸機 ESXi 執行個體的名稱。
ZONE：裸機執行個體所在的可用區。
TEP_VLAN_ID：指派給 NSX-TEP Dynamic NIC 的 VLAN ID (例如 4)，會形成介面名稱 nic0.TEP_VLAN_ID。
TEP_SUBNET_NAME：NSX-TEP 子網路的名稱。
TEP_IP_ADDRESS：TEP IPv4 位址或現有的預留內部 IP 位址資源名稱，與 NSX Manager 指派給 ESXi 主機 (vmk10) 的 IP 位址相符。
PROJECT_ID： Google Cloud 專案的 ID。

VDS MTU 與 Google Cloud 虛擬私有雲巨型框架不符

Google Cloud 虛擬私有雲網路支援的最大傳輸單位 (MTU) 為 8896 個位元組，適用於巨型框架。根據預設，VCF 會設定 vSphere Distributed Switch (VDS)、VMkernel 轉接器 (vSAN、vMotion 和 NSX-TEP) 和 NSX 傳輸節點設定檔，MTU 為 9000 位元組。如果主機透過虛擬私有雲 underlay 傳送大於 8896 位元組的封包，虛擬私有雲網路會捨棄過大的框架，導致 vSAN 複製錯誤、vMotion 逾時或 NSX 疊加層分割問題。

解決方法：在啟動前，將 VCF 部署規格中的 MTU 設為 8896 位元組，或在部署後更新 vCenter Server 和 NSX Manager 中的 MTU 設定：

在 vSphere Client 中更新 VDS MTU

在 vSphere Client 中，前往「Networking」(網路)，然後選取叢集的 vSphere Distributed Switch。
在分散式交換器上按一下滑鼠右鍵，然後依序選取「Settings」 >「Edit Settings」。
按一下「進階」分頁標籤，將「MTU (位元組)」設為 8896，然後按一下「確定」。

更新 VMkernel 轉接器和 NSX 設定檔

針對叢集中的每個 ESXi 主機，依序前往「Configure」(設定) >「Networking」(網路) >「VMkernel adapters」(VMkernel 轉接器)，編輯 vMotion (vmk1) 和 vSAN (vmk2) 轉接器，然後將「MTU」設為 8896。
在 NSX Manager UI 中，依序前往「System」(系統) >「Fabric」(網狀架構) >「Profiles」(設定檔) >「Uplink Profiles」(上行連結設定檔)，編輯有效的主機和邊緣上行連結設定檔，並將「MTU」設為 8896 (並依序前往「System」(系統) >「Fabric」(網狀架構) >「Settings」(設定) >「Global Fabric Settings」(全域網狀架構設定)，將全域實體網狀架構 MTU 設為 8896)。

NSX 虛擬交換器模式

在 VCF 9.x 中，NSX Manager 設定的預設虛擬交換器模式為「Enhanced Datapath Standard」(增強型資料路徑標準)，VMware 解決方案主機不支援此模式。

解決方法：在 VCF 安裝程式的「NSX」部分，清除「Apply the default virtual switch mode configured in NSX Manager」核取方塊，然後在「Operational Mode」部分選取「Standard」，如下方螢幕截圖所示 (點選可放大)：

NSX 設定，顯示已取消勾選預設虛擬交換器模式核取方塊，且作業模式設為「Standard」。

在第 2 層廣播子網路上，Cloud DNS 傳入轉送功能發生 DNS 解析失敗

在託管 VMware 解決方案節點的虛擬私有雲網路，啟用 Cloud DNS 傳入伺服器政策時，Cloud DNS 會自動在虛擬私有雲網路的各個區域子網路，保留一個內部 DNS_RESOLVER IP 位址。這包括未標記的 ESXi 管理 (MGMT) 子網路，以及使用第 2 層位址解析通訊協定 (ARP) 廣播和自訂 MAC 學習 (ARP_BROADCAST_PRIMARY_RANGE_WITH_LEARNING) 的 VLAN 標記動態 NIC 子網路 (vSAN、vMotion 和 NSX-TEP)。

如果您將 ESXi 主機或 VCF 管理設備設為從相同子網路 (或已啟用 ARP 廣播和 MAC 學習功能的任何節點子網路) 查詢 DNS_RESOLVER IP 位址，主機會將轉送站 IP 位址視為本機第 2 層鄰近節點，並傳送 ARP 廣播要求來解析其 MAC 位址。Cloud DNS 傳入轉送站是Google Cloud Proxy 服務，而非子網路上的第 2 層端點，因此不會回應 ARP 要求，也不會參與自訂 MAC 學習。因此，鄰近項目仍不完整 (esxcli network ip neighbor list)，且 DNS 查詢 (nslookup) 逾時。

Private Service Connect (PSC) 端點 (GCE_ENDPOINT) 也適用相同行為，例如用於連線至區域離線存放區的端點。如果您在第 2 層 ARP 廣播或 VLAN 標記節點子網路中部署 Private Service Connect 端點，端點 IP 位址的 ARP 解析作業會失敗，且連至離線存放區的連線會逾時。

解決方法：針對 Cloud DNS 傳入 DNS_RESOLVER IP 位址 (以及 Private Service Connect 離線存放區端點)，使用相同區域和虛擬私有雲網路中的現有標準 (非 VLAN、非第 2 層廣播) 子網路，或建立專屬標準子網路 (如果尚未建立)。如果該區域已有標準子網路，Cloud DNS 會在該子網路中分配可用的 DNS_RESOLVER IP 位址：

如果相同區域和虛擬私有雲網路中沒有標準子網路，請建立專用標準子網路，不要指定 --resolve-subnet-mask 旗標。請勿將這個子網路連結至節點主要介面或 VLAN 標記的 Dynamic NIC：
```
gcloud compute networks subnets create DNS_SUBNET_NAME \
    --network=VPC_NAME \
    --region=REGION \
    --range=DNS_SUBNET_RANGE \
    --project=PROJECT_ID
```
擷取 Cloud DNS 在標準子網路中保留的 DNS_RESOLVER IP 位址：
```
gcloud compute addresses list \
    --filter="purpose=DNS_RESOLVER AND subnetwork:DNS_SUBNET_NAME" \
    --project=PROJECT_ID
```
執行上述指令前，請先替換下列項目：
- DNS_SUBNET_NAME：Cloud DNS 傳入轉送作業現有或專用的標準子網路名稱。
- VPC_NAME：虛擬私有雲網路的名稱。
- REGION：裸機節點所在的 Google Cloud 區域。
- DNS_SUBNET_RANGE：專用標準子網路的主要 IPv4 CIDR 範圍，不得重疊 (例如 10.0.100.0/28)。
- PROJECT_ID： Google Cloud專案的 ID。
設定 ESXi 主機、VCF 管理設備和 VMware 解決方案工具包 (config.json 中的 dns_server)，使用 DNS_SUBNET_NAME 的 DNS_RESOLVER IP 位址，而非與 ESXi 管理 (MGMT)、vSAN、vMotion 或 NSX-TEP 子網路相關聯的 DNS_RESOLVER IP 位址。