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

已知问题

本页面列出了在 VMware Solution on Google Cloud中部署和运行 VMware Cloud Foundation (VCF) 的已知问题和解决方法。

VCF 部署期间的 ESX 主机 vSAN HCL 兼容性

当您部署 VCF 管理网域并将运行 VCF 安装程序的节点作为管理网域的一部分时，运行 VCF 安装程序的节点的 ESXi HCL 兼容性检查会失败。这是 VCF 9.x 中的一个已知问题。为确保检查通过，请使用以下方法之一在 VCF 安装程序中启用 Allow auto claim of HCL incompatible disks（允许自动声明 HCL 不兼容的磁盘）：

Terraform 和工具包：如果您使用 Terraform 和工具包部署节点和 VCF，则 skipHclAutoDiskClaim 选项会在部署配置 JSON 文件中自动设置为 true。
VCF 安装程序界面：如果您使用部署向导，请在 vSAN 架构部分下的部署 VMware Cloud Foundation > 计划 > 存储选项页面上选择允许自动声明 HCL 不兼容的磁盘。

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），构成接口名称 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：与 NSX Manager 分配给 ESXi 主机 (vmk10) 的 IP 地址匹配的 TEP IPv4 地址或现有预留内部 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 Client 中更新 VDS MTU

在 vSphere 客户端中，前往网络，然后选择集群的 vSphere Distributed Switch。
右键点击分布式交换机，然后依次选择设置 > 修改设置。
点击高级标签页，将 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 配置，其中清除了默认虚拟交换机模式复选框，并将“Operational Mode”（操作模式）设置为“Standard”（标准）。

在第 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 地址。