Google 会使用 AI 技术将内容翻译成您偏好的语言。AI 翻译可能包含错误。

已知问题

本页面列出了在 VMware Solution on Google Cloud中部署和运行 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 VPC 网络会对每个裸金属节点的 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），该 ID 构成接口名称 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）（动态 NIC 的 Google Cloud VPC 子网不支持 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 界面（在 VCF 9.1 中，前往系统 > Fabric > 主机）或 vSphere 客户端中，检查分配给每个 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），该 ID 构成接口名称 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 VPC 巨型帧不匹配

Google Cloud VPC 网络支持的最大传输单元 (MTU) 最多为 8896 字节（巨型帧）。默认情况下，VCF 会配置 vSphere Distributed Switch (VDS)、VMkernel 适配器（vSAN、vMotion 和 NSX-TEP）以及 MTU 为 9000 字节的 NSX 传输节点配置文件。如果主机通过 VPC 底层发送大于 8896 字节的数据包，VPC 网络会丢弃超大帧，从而导致 vSAN 复制错误、vMotion 超时或 NSX 叠加层分片问题。

权宜解决方法：在启动之前，在 VCF 部署规范中将 MTU 配置为 8896 字节，或在部署后更新 vCenter Server 和 NSX Manager 中的 MTU 设置：

在 vSphere 客户端中更新 VDS MTU

在 vSphere 客户端中，前往网络，然后选择集群的 vSphere 分布式交换机。
右键点击分布式交换机，然后依次选择设置 > 修改设置。
点击高级标签页，将 MTU（字节）设置为 8896，然后点击确定。

更新 VMkernel 适配器和 NSX 配置文件

对于集群中的每个 ESXi 主机，依次前往配置 > 网络 > VMkernel 适配器，修改 vMotion (vmk1) 和 vSAN (vmk2) 适配器，并将 MTU 设置为 8896。
在 NSX Manager 界面中，依次前往系统 > Fabric > 配置文件 > 上行链路配置文件，修改活跃主机和边缘上行链路配置文件，并将 MTU 设置为 8896（在系统 > Fabric > 设置 > 全局 Fabric 设置中将全局物理 Fabric MTU 设置为 8896）。

NSX 虚拟交换机模式

在 VCF 9.x 中，NSX Manager 中配置的默认虚拟交换机模式设置为增强型数据路径标准，VMware 解决方案主机不支持此模式。

解决方法：在 VCF 安装程序的 NSX 部分中，清除应用在 NSX Manager 中配置的默认虚拟交换机模式复选框，然后为操作模式选择标准，如以下屏幕截图所示（点击可放大）：

NSX 配置，其中默认虚拟交换机模式复选框已清除，且操作模式设置为“标准”。

在第 2 层广播子网上使用 Cloud DNS 入站转发时 DNS 解析失败

在托管 VMware 解决方案节点的 VPC 网络上启用 Cloud DNS 入站服务器政策时，Cloud DNS 会自动在 VPC 网络的每个区域子网中预留一个内部 DNS_RESOLVER IP 地址。这包括未加标记的 ESXi 管理 (MGMT) 子网和加 VLAN 标记的 Dynamic NIC 子网（vSAN、vMotion 和 NSX-TEP），这些子网使用第 2 层地址解析协议 (ARP) 广播和自定义 MAC 学习 (ARP_BROADCAST_PRIMARY_RANGE_WITH_LEARNING)。

如果您将 ESXi 主机或 VCF 管理设备配置为从同一子网（或从任何启用了 ARP 广播和 MAC 学习的节点子网）查询 DNS_RESOLVER IP 地址，则主机会将转发器 IP 地址视为本地第 2 层邻居，并发送 ARP 广播请求来解析其 MAC 地址。由于 Cloud DNS 入站转发器是Google Cloud 代理服务，而不是子网上的第 2 层端点，因此它不会响应 ARP 请求，也不会参与自定义 MAC 学习。因此，邻居条目仍不完整 (esxcli network ip neighbor list)，并且 DNS 查询 (nslookup) 超时。

同样的行为也适用于 Private Service Connect (PSC) 端点 (GCE_ENDPOINT)，例如用于连接到区域级离线代码库的端点。如果您在第 2 层 ARP 广播或加 VLAN 标签的节点子网中部署 Private Service Connect 端点，则端点 IP 地址的 ARP 解析会失败，并且与离线代码库的连接会超时。

解决方法：在同一区域和 VPC 网络中使用现有的标准（非 VLAN、非第 2 层广播）子网，或者为 Cloud DNS 入站 DNS_RESOLVER IP 地址（以及 Private Service Connect 离线代码库端点）创建专用标准子网（如果尚不存在）。如果该区域中已存在标准子网，则 Cloud DNS 已在该子网中分配了一个 DNS_RESOLVER IP 地址，供您使用：

如果同一区域和 VPC 网络中尚不存在标准子网，请创建一个专用标准子网，而不指定 --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：您的 VPC 网络的名称。
- 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 地址。