VMware NSX for vSphere 6.3.0 发行说明

VMware NSX for vSphere 6.3.0 | 2017 年 2 月 2 日发行 | 内部版本 5007049

发行说明内容

本发行说明包含以下主题：

• 新增功能
• 版本、系统要求和安装说明
• 已弃用和已停用的功能
• 升级说明
• 已知问题
• 已解决的问题
• 文档修订历史

新增功能

NSX 6.3.0 中的新功能可以分为以下几类：

• 平台和合规性功能
• 运维增强功能
• 服务和路由增强功能
• 安全增强功能
• CMP 和合作伙伴集成
• 安装和升级
• 备份和还原

平台和合规性功能

• 在平台端：

  • 跨 vCenter NSX 活动-备用 DFW 增强功能：NSX 6.3.0 具有以下增强功能：

    • 现在支持多个通用 DFW 区域。通用和本地规则可以在源、目标和应用对象字段中使用通用安全组。

    • 通用安全组：可以按静态或动态方式定义通用安全组成员资格。可以在每个虚拟机中手动添加通用安全标记以获得静态成员资格。可以根据动态条件（虚拟机名称）将虚拟机添加为成员以获得动态成员资格。

    • 通用安全标记：您现在可以在主 NSX Manager 上定义通用安全标记，并标记与辅助 NSX Manager 的通用同步。可以按静态（根据选择的唯一 ID）或动态方式为虚拟机分配通用安全标记，以响应防病毒软件或漏洞扫描等条件。

    • 唯一 ID 选择条件：在早期版本的 NSX 中，安全标记位于 NSX Manager 本地，并使用虚拟机的受管对象 ID 将其映射到虚拟机。在活动/备用环境中，给定虚拟机的受管对象 ID 在活动和备用数据中心可能不相同。NSX 6.3.x 允许在主 NSX Manager 上配置一个唯一 ID 选择条件，以用于在连接到通用安全标记时识别虚拟机：虚拟机实例 UUID、虚拟机 BIOS UUID、虚拟机名称或这些选项的组合。有关详细信息，请参阅《NSX 管理指南》中的“唯一 ID 选择”。

  • 控制层面代理 (netcpa) 自动恢复：netcpa 进程的增强自动恢复机制可以确保持续的数据路径通信。自动 netcpa 监控进程还会在出现任何问题时自动重新启动，并通过 syslog 服务器提供警报。优点摘要：

    • 自动 netcpa 进程监控
    • 在出现问题时自动重新启动进程，例如，系统挂起时
    • 自动生成核心文件以进行调试
    • 通过 syslog 提供自动重新启动事件警报

  • vSphere 6.5 兼容性：NSX 6.3.0 引入了对 vSphere 6.5a 和更高版本的支持。NSX 6.3.0 保留与 vSphere 5.5 和 6.0 的兼容性。

  • 技术预览版：控制器断连操作 (CDO) 模式：已将控制器断连操作 (CDO) 模式作为技术预览版功能引入。在主机与控制器断开连接时，该模式确保数据层面连接不会受到影响。请参阅《NSX 管理指南》中的“控制器断连操作 (CDO) 模式”部分。另请参阅问题 1803220。

• 合规性功能：

  • FIPS：NSX 6.3.0 具有 FIPS 模式，该模式仅使用符合 FIPS 的密码套件。NSX Manager 和 NSX Edge 具有 FIPS 模式，可以通过 vSphere Web Client 或 NSX REST API 启用。有关 FIPS 模式影响的功能列表，请参见《NSX 管理指南》中的“FIPS 模式和非 FIPS 模式之间的功能差异”。

    注意：VMware 开发合作伙伴正在认证符合 FIPS 模式的新合作伙伴解决方案以在 NSX 中使用。NSX 6.3.0 出站连接为 TLS 1.1 或更高版本，并且仅使用 FIPS 批准的密码套件。这意味着，收到回调的合作伙伴设备必须将安全 Web 侦听器配置为更安全的密码套件。下面列出了默认模式密码和 FIPS 模式密码：

    • 默认模式密码：（FIPS 模式 OFF）[TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]

    • FIPS 模式密码：[TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA]

    默认模式和 FIPS 模式都支持 TLS 1.1 和 1.2 协议。请参阅《VMware 兼容性指南》以验证合作伙伴解决方案是否通过 FIPS 模式认证。

  • 通用条件：对于通用条件合规性，NSX 已经过测试，符合 EAL2+ 保证级别。要运行符合通用条件的 NSX 安装，您需要按照《NSX 管理指南》的“针对通用条件配置 NSX”部分中的说明配置 NSX。

  • ICSA：这是一个在行业范围内广泛接受的标准认证，它测试和认证一些产品，其中包括防病毒软件、防火墙、IPSec VPN、加密、SSL VPN、网络 IPS、防间谍软件和 PC 防火墙产品。分布式防火墙和 Edge 防火墙已通过 ICSA 企业防火墙标准认证。

  • 根据 ICSA 认证要求更改 DFW 数据包日志格式：NSX 6.3.0 引入了对 DFW 数据包日志的更改。在 6.3.0 和更高版本中，我们加入了 ICMP 类型和代码以满足 ICSA 认证要求。

    以下是 6.3.0 之前版本的日志内容，其中没有 ICMP 代码和类型：

    2016-09-29T20:52:21.983Z 6673 INET6 match PASS domain-c27/1001 IN 96 ICMP
fe80:0:0:0:21d:b502:f984:c601->ff02:0:0:0:0:0:0:1

    在 6.3.0 和更高版本中，日志类似于以下内容，其中包含 ICMP 代码和类型。在此示例中，8 表示代码，0 表示类型：

    2016-09-29T20:54:16.051Z 42991 INET match PASS domain-c27/1001 IN 84 ICMP 8 0 10.113.226.5->10.28.79.55

运维增强功能

• 故障排除仪表板：在 NSX 6.3.0 中更新了 NSX 仪表板以包括更多功能，例如，服务部署状态、NSX Manager 备份状态和 Edge 设备通知。

• 安全标记：这允许通过 API 调用为给定虚拟机分配和清除多个标记。

• syslog 增强功能：为负载平衡器专门提供了新的 syslog 更新。

• Log Insight 内容包：已针对负载平衡器更新了该内容包，以便从用户界面 (UI) 中提供集中式仪表板、端到端监控以及更好的容量规划。

• 基于角色的访问控制：该功能限制为仅由企业管理员进行用户管理，因此，NSX 管理员不再具有创建新用户或将角色分配给新用户的权限。从安全角度看，这有助于明确划分这两个管理员角色。

• 负载平衡器池成员的引流状态：您现在可以将池成员置于“引流”状态，这会强制服务器正常关闭以进行维护。如果将池成员设置为引流状态，则会将后端服务器从负载平衡中移除，但仍允许该服务器接受新的持久性连接。

服务和路由增强功能

• BGP 的 4 字节 ASN 支持：提供了具有 4 字节 ASN 支持的 BGP 配置，并与以前存在的 2 字节 ASN BGP 对等项保持向后兼容。
• NAT 五元组匹配增强功能：为了向 NAT 规则提供更精细的配置和灵活性，为 NSX 6.3.0 提供了五元组匹配支持：
  • 匹配条件基于 5 个参数 - 协议、源 IP、源端口、目标 IP 和目标端口。
  • 更改了用户界面 (UI) 以帮助您更轻松地指定 SNAT/DNAT 配置。在旧 Edge 版本上更改 DNAT/SNAT 配置时，UI 仍会显示旧样式的窗格。
  • NSX REST API 为新参数添加了字段：

    <natRules> <natRule> {...}<!-- new fields applicable for DNAT --> <dnatMatchSourceAddress>any</dnatMatchSourceAddress> <dnatMatchSourcePort>any</dnatMatchSourcePort> </natRule> <natRule> {...}<!-- new fields applicable for SNAT --> <snatMatchDestinationAddress>any</snatMatchDestinationAddress> <snatMatchDestinationPort>any</snatMatchDestinationPort> </natRule> </natRules>

• 提高了第 2 层 VPN 性能：提高了第 2 层 VPN 的性能。这允许单个 Edge 设备支持高达 1.5 Gb/s 吞吐量，这大大高于以前的 750 Mb/s。

• 改进了 OSPF 可配置性：在 Edge 服务网关 (ESG) 上配置 OSPF 时，NSSA 可以将所有 7 型 LSA 转换为 5 型 LSA。

安全增强功能

分布式防火墙具有以下几处改进：

• DFW 定时器：NSX 6.3.0 引入了会话定时器，它定义了闲置后在防火墙中保留会话的时间。协议的会话超时过期后，会话会关闭。在防火墙上，您可以为 TCP、UDP 和 ICMP 会话定义超时，并将其应用于用户定义的虚拟机或 vNIC 集。请参阅《NSX 管理指南》中的“会话定时器”。

• 用于支持微分段的新功能：为了在可见性和规划工具中支持微分段，引入了两个新功能：

  • 应用程序规则管理器简化了为现有应用程序创建安全组和防火墙规则白名单的过程。

  • 端点监控允许应用程序所有者分析其应用程序，并确定建立网络连接的进程。

• Guest Introspection 的 Linux 支持：NSX 6.3.0 为 Linux 虚拟机启用 Guest Introspection。在基于 Linux 的客户机虚拟机上，NSX Guest Introspection 功能使用 Linux 内核提供的 fanotify 和 inotify 功能。有关详细信息，请参阅《NSX 管理指南》中的“为 Linux 安装 Guest Introspection”。有关 NSX 支持的 Linux 版本列表，请参见版本。

• 服务编排的发布状态：现在提供了服务编排发布状态以检查是否同步了策略。这提高了在主机上将安全策略转换为 DFW 规则的可见性。

云管理平台 (CMP) 和合作伙伴集成

• 在 vCloud Director 8.20 和 NSX 6.3.0 之间具有更好的互操作性，这可以帮助服务提供商向其租户提供高级网络和安全服务。借助与 NSX 6.3.0 的良好互操作性，vCloud Director 8.20 可以提供原生 NSX 功能以支持多个租户和租户自助服务。

• NSX 6.3.0 支持新的 vRO 插件版本 1.1，该插件支持 vRA 并引入相应的功能以支持其他非 vRA 应用程序。

• NSX NetX 6.3.0 提供了与服务插入相关的扩展和性能改进。

安装和升级

• NSX 内核模块现在独立于 ESXi 版本：从 NSX 6.3.0 开始，NSX 内核模块仅使用公开提供的 VMKAPI，以确保可以在不同的版本中使用这些接口。该增强功能有助于降低主机升级由于不正确的内核模块版本而失败的可能性。在早期版本中，NSX 环境中的每次 ESXi 升级需要至少重新引导两次，以确保 NSX 功能继续正常工作（由于需要为每个新的 ESXi 版本推送新的内核模块）。

• 在将主机退出维护模式之前，NSX 6.3.0 还会检查 NSX 准备情况。这确保 DRS 仅将工作负载移动到 NSX 准备就绪的主机。这可防止某些工作负载虚拟机的网络中断。

• OVF 参数现在以逗号分隔：以下 OVF 参数从以空格分隔更改为以逗号分隔：

  • DNS 服务器列表 (vsm_dns1_0)
  • 域搜索列表 (vsm_domain_0)
  • NTP 服务器列表 (vsm_ntp_0)

备份和还原

从 NSX 6.3.0 开始，SFTP 备份支持以下密码︰

• 加密: aes128-cbc、aes128-ctr、aes192-cbc、aes192-ctr、aes256-cbc、aes256-ctr
• 消息身份验证 (mac)：hmac-sha2-256
• 密钥交换︰diffie-hellman-group-exchange-sha256

注意：不支持 hmac-sha1，仅支持 hmac-sha2-256。如果使用 SFTP 进行备份，请在升级到 6.3.0 之后更改为 hmac-sha2-256。有关详细信息，请参阅 VMware 知识库文章 2149282。

版本、系统要求和安装说明

注意：

• 下表列出了建议的 VMware 软件版本。这些建议只是常规建议，具体应考虑特定的环境需求。

• 此信息为截至本文档发布之日的最新信息。

• 有关 NSX 和其他 VMware 产品的最低支持版本，请参见 VMware 产品互操作性列表。VMware 的最低支持版本声明基于内部测试。

产品或组件	建议的版本
NSX for vSphere	对于新部署以及从 6.1.x 升级的部署，VMware 建议使用最新的 NSX 6.3 版本。 在升级现有部署时，请在计划升级之前参考 NSX 发行说明，或者与 VMware 技术支持代表联系以了解某些特定问题的详细信息。
vSphere	vSphere 5.5U3 和更高版本 vSphere 6.0U3 和更高版本。vSphere 6.0U3 解决了在重新引导 vCenter Server 后在 ESXi 主机中出现的重复 VTEP 问题。有关详细信息，请参见 VMware 知识库文章 2144605。 vSphere 6.5U1 和更高版本。vSphere 6.5U1 解决了 EAM 由于内存不足而失败的问题。有关详细信息，请参见 VMware 知识库文章 2135378。
适用于 Windows 的 Guest Introspection	支持所有版本的 VMware Tools。某些基于 Guest Introspection 的功能需要使用较新的 VMware Tools 版本： 使用 VMware Tools 10.0.9 和 10.0.12 启用 VMware Tools 附带的可选瘦代理网络自检驱动程序组件。 升级到 VMware Tools 10.0.8 和更高版本，以解决在 NSX/vCloud Networking and Security 中升级 VMware Tools 后虚拟机速度缓慢问题（请参见 VMware 知识库文章 2144236）。 使用 VMware Tools 10.1.0 和更高版本以支持 Windows 10。
适用于 Linux 的 Guest Introspection	该 NSX 版本支持以下 Linux 版本： RHEL 7 GA（64 位） SLES 12 GA（64 位） Ubuntu 14.04 LTS（64 位）
vRealize Orchestrator	NSX-vRO 插件 1.1.0 或更高版本。

注意：VMware 目前不支持 vRealize Networking Insight 3.2 与 NSX for vSphere 6.3.x 的互操作性。

系统要求和安装说明

有关 NSX 安装必备条件的完整列表，请参见《NSX 安装指南》中的 NSX 的系统要求一节。

有关安装说明，请参见《NSX 安装指南》或《跨 vCenter NSX 安装指南》。

已弃用和已停用的功能

产品周期终止和支持期终止警告

有关必须尽快升级的 NSX 和其他 VMware 产品的信息，请参见 VMware 生命周期产品列表。

• NSX for vSphere 6.1.x：NSX for vSphere 6.1.x 已于 2017 年 1 月 15 日终止提供 (EOA) 和终止支持 (EOGS)。（另请参见 VMware 知识库文章 2144769。）

• 新增：已移除 NSX 数据安全：从 NSX 6.3.0 开始，已从产品中移除 NSX 数据安全功能。

• 新增：已弃用 NSX 活动监控 (SAM)：从 NSX 6.3.0 开始，活动监控不再是受支持的 NSX 功能。作为替代，请使用端点监控。有关详细信息，请参见《NSX 管理指南》中的“端点监控”。

• 新增：已移除 Web Access 终端：Web Access 终端 (WAT) 已从 NSX 6.3.0 中移除。您无法配置 Web Access SSL VPN-Plus 并启用通过 NSX Edge 的公共 URL 访问。VMware 建议在 SSL VPN 部署中使用完全访问权限客户端以提高安全性。如果在早期版本中使用 WAT 功能，您必须在升级到 6.3.0 之前将其禁用。

• 新增：已从 NSX Edge 中移除 IS-IS：从 NSX 6.3.0 开始，您无法从路由选项卡中配置 IS-IS 协议。

• 新增：不再支持 vCNS Edge。在升级到 NSX 6.3.x 之前，您必须先升级到 NSX Edge。

API 移除和行为变化

删除防火墙配置或默认区域：

• 如果指定了默认区域，现在将拒绝删除防火墙区域的请求：DELETE /api/4.0/firewall/globalroot-0/config/layer2sections|layer3sections/sectionId
• 引入了新方法以获取默认配置。请使用该方法的输出替换整个配置或任何默认区域：
  • 使用 GET api/4.0/firewall/globalroot-0/defaultconfig 获取默认配置
  • 使用 PUT /api/4.0/firewall/globalroot-0/config 更新整个配置
  • 使用 PUT /4.0/firewall/globalroot-0/config/layer2sections|layer3sections/{sectionId} 更新单个区域

仅从逻辑（分布式）路由器 NSX Edge 设备的以下方法中移除了 defaultOriginate 参数：

• GET/PUT /api/4.0/edges/{edge-id}/routing/config/ospf
• GET/PUT /api/4.0/edges/{edge-id}/routing/config/bgp
• GET/PUT /api/4.0/edges/{edge-id}/routing/config

若在 NSX 6.3.0 或更高版本中将 defaultOriginate 设为 true，逻辑（分布式）路由器 Edge 设备将失败。

从 NSX Edge 路由中移除了所有 IS-IS 方法。

• GET/PUT/DELETE /4.0/edges/{edge-id}/routing/config/isis
• GET/PUT /4.0/edges/{edge-id}/routing/config

升级说明

• 与 NSX 和 vSphere 相关的升级说明
• 与 NSX 组件相关的升级说明
• 与 FIPS 相关的升级说明

注意：如果您使用 SFTP 进行 NSX 备份，请参阅备份和还原以获取从 6.3.x 开始受支持的安全算法列表。

注意：有关影响安装和升级的已知问题列表，请参见安装和升级已知问题一节。

与 NSX 和 vSphere 相关的升级说明

• 要升级 NSX，您必须执行完整的 NSX 升级，包括主机群集升级（将升级主机 VIB）。有关说明，请参见《NSX 升级指南》，包括“升级主机群集”部分。

• 系统要求：有关安装和升级 NSX 时的系统要求信息，请参见 NSX 文档中的 NSX 的系统要求部分。

  在 NSX 6.3.0 中，已更改 NSX Edge 设备磁盘大小：

  • 精简、中型、大型：1 个磁盘 584 MB + 1 个磁盘 512 MB

  • 超大型：1 个磁盘 584 MB + 1 个磁盘 2 GB + 1 个磁盘 256 MB

• 从 NSX 6.x 升级的途径：VMware 产品互操作性列表提供了有关从 VMware NSX 升级的途径的详细信息。在《NSX 升级指南》中讲述了跨 vCenter NSX 升级过程。

• 不支持降级：

  • 请务必先备份 NSX Manager，然后再执行升级。

  • 成功升级 NSX 后，无法对 NSX 进行降级。

• 要验证是否成功升级到 NSX 6.3.x，请参见知识库文章 2134525。

• 不支持从 vCloud Networking and Security 升级到 NSX 6.3.0。您必须先升级到支持的 6.2.x 版。

• 升级到 vSphere 6.5a：从 vSphere 5.5 或 6.0 升级到 vSphere 6.5a 时，您必须先升级到 NSX 6.3.0。请参见《NSX 升级指南》中的“在 NSX 环境中升级 vSphere”。

  注意：NSX 6.2.x 与 vSphere 6.5 不兼容。

• 合作伙伴服务兼容性：如果您的站点使用 VMware 合作伙伴服务来实施 Guest Introspection 或网络自检，则在升级之前，必须查阅《VMware 兼容性指南》，以确认供应商的服务与此版本的 NSX 兼容。

• 如果在您的环境中安装了硬件网关（硬件 VTEP），将阻止升级到 NSX 6.3.0。您必须与 VMware 支持部门联系以进行升级。有关详细信息，请参阅 VMware 知识库文章 2148511。

• 重置 vSphere Web Client：升级 NSX Manager 后，必须按照 NSX 升级文档中的说明重置 vSphere Web Client 服务器。如未执行此操作，网络和安全选项卡可能不会在 vSphere Web Client 中显示。您可能还需要清除浏览器缓存或历史记录。

• 无状态环境：无状态主机环境中的 NSX 升级使用新的 VIB URL：在无状态主机环境中执行 NSX 升级时，新的 VIB 将在 NSX 升级过程中预先添加到主机映像配置文件。因此，无状态主机上的 NSX 升级过程遵循以下顺序：

  1. 通过 NSX Manager 从固定 URL 手动下载最新 NSX VIB。

  2. 将 VIB 添加到主机映像配置文件。

  在 NSX 6.2.0 之前，您只能在 NSX Manager 上通过单个 URL 找到适用于特定版本的 ESX 主机的 VIB。（这意味着管理员只需知道一个 URL，而不管使用的是哪种 NSX 版本。）在 NSX 6.2.0 和更高版本中，新的 NSX VIB 通过不同的 URL 提供。要找到合适的 VIB，您必须执行以下步骤：

  • 从 https://<NSX-Manager-IP>/bin/vdn/nwfabric.properties 找到新的 VIB URL。
  • 从相应的 URL 获取所需 ESX 主机版本的 VIB。
  • 将这些 VIB 添加到主机映像配置文件。

与 NSX 组件相关的升级说明

• 升级 Edge 服务网关 (ESG)：
  从 NSX 6.2.5 开始，将在升级 NSX Edge 时执行资源预留。如果在资源不足的群集上启用 vSphere HA，由于违反 vSphere HA 限制，升级操作可能会失败。

  为了避免此类升级失败，请在升级 ESG 之前执行以下步骤：

  如果在安装或升级时没有明确设置值，NSX Manager 将使用以下资源预留。

  NSX Edge 规格大小	CPU 预留	内存预留
  精简	1000MHz	512 MB
  中型	2000MHz	1024 MB
  大型	4000MHz	2048 MB
  超大型	6000MHz	8192 MB

  1. 始终确保您的安装遵循为 vSphere HA 建议的最佳做法。请参见 VMware 知识库文章 1002080 文档。

  2. 使用 NSX 优化配置 API：
     PUT https://<NSXManager>/api/4.0/edgePublish/tuningConfiguration
     确保 edgeVCpuReservationPercentage 和 edgeMemoryReservationPercentage 值在相应规格大小的可用资源范围内（请参见下表以了解默认值）。

• 在升级 NSX Edge 设备之前，必须为 NSX 准备主机群集：从 6.3.0 开始，不再支持通过 VIX 通道在 NSX Manager 和 Edge 之间进行的管理层面通信。仅支持消息总线通道。从 NSX 6.2.x 或更低版本升级到 NSX 6.3.0 或更高版本时，您必须确认为 NSX 准备了部署 NSX Edge 设备的主机群集，并且消息基础架构状态为绿色。如果没有为 NSX 准备主机群集，NSX Edge 设备升级将失败。有关详细信息，请参见《NSX 升级指南》中的升级 NSX Edge。

  请执行以下操作以验证部署 NSX Edge 的主机的消息基础架构状态是否为绿色：

  • 使用 API 方法 GET /api/2.0/nwfabric/status?resource={resourceId}，其中 resourceId 是群集或主机的 vCenter 受管对象 ID（例如，domain-c33 或 host-21）。有关查找群集和主机的资源 ID 的说明，请参见《NSX API 指南》中的“查找 vCenter 对象 ID”。
  • 在响应正文中查找与 com.vmware.vshield.vsm.messagingInfra 的 featureId 对应的状态：

    <nwFabricFeatureStatus> <featureId>com.vmware.vshield.vsm.messagingInfra</featureId> <updateAvailable>false</updateAvailable> <status>GREEN</status> <installed>true</installed> <enabled>true</enabled> <allowConfiguration>false</allowConfiguration> </nwFabricFeatureStatus>

• 在启用 vSphere HA 并部署 Edge 时，请禁用 vSphere 的虚拟机启动选项。在将 6.2.4 或更低版本的 NSX Edge 升级到 6.2.5 或更高版本后，您必须为已启用 vSphere HA 并部署 Edge 的群集中的每个 NSX Edge 禁用 vSphere 虚拟机启动选项。为此，请打开 vSphere Web Client，找到 NSX Edge 虚拟机所在的 ESXi 主机，单击“管理”>“设置”并在“虚拟机”下面选择“虚拟机启动/关机”，单击“编辑”并确保该虚拟机处于手动模式（即，确保该虚拟机未添加到自动启动/关机列表中）。

• 控制器磁盘布局：从 6.2.2 和更早版本中升级不会收到 6.2.3 中引入的新磁盘布局，该布局为数据和日志提供单独的磁盘分区以提高控制器稳定性。

• 在升级到 NSX 6.2.5 或更高版本之前，确保所有的负载平衡器密码列表均以冒号分隔。如果您的密码列表使用逗号等其他分隔符，请对 https://nsxmgr_ip/api/4.0/edges/EdgeID/loadbalancer/config/applicationprofiles 执行 PUT 调用，并将 <clientSsl> 和 <serverSsl> 中的每个 <ciphers> 列表替换为以冒号分隔的列表。例如，请求正文中的相关分段可能类似于以下内容。对所有的应用程序配置文件重复此过程：

  <applicationProfile><name>https-profile</name><insertXForwardedFor>false</insertXForwardedFor><sslPassthrough>false</sslPassthrough><template>HTTPS</template><serverSslEnabled>true</serverSslEnabled><clientSsl><ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers><clientAuth>ignore</clientAuth><serviceCertificate>certificate-4</serviceCertificate></clientSsl><serverSsl><ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers><serviceCertificate>certificate-4</serviceCertificate></serverSsl>...
  </applicationProfile>

• 在早于 6.2.0 的 vROPs 版本中为负载平衡的客户端设置正确的密码版本：早于 6.2.0 的 vROPs 版本中的 vROPs 池成员使用 TLS 版本 1.0，因此，您必须在 NSX 负载平衡器配置中设置 "ssl-version=10" 以显式设置监控扩展值。请参见《NSX 管理指南》中的“创建服务监控器”以了解相应的说明。

  {"expected" : null,"extension" : "ssl-version=10","send" : null,"maxRetries" : 2,"name" : "sm_vrops","url" : "/suite-api/api/deployment/node/status","timeout" : 5,"type" : "https","receive" : null,"interval" : 60,"method" : "GET"}

• 主机可能会停滞在正在安装状态：在大规模的 NSX 升级过程中，主机可能会长时间停滞在正在安装状态。出现这种情况可能是由于卸载旧 NSX VIB 的过程中出现问题。在这种情况下，与此主机关联的 EAM 线程将在 VI Client 任务列表中被报告为停滞。
  解决办法：执行以下操作：

  • 使用 VI Client 登录到 vCenter。
  • 右键单击停滞的 EAM 任务并将其取消。
  • 从 vSphere Web Client 中，对群集执行“解决”操作。停滞的主机现在可能显示为“正在进行中”。
  • 登录到主机，然后执行重新引导以强制完成该主机上的升级操作。

与 FIPS 相关的升级说明

• 从 NSX 6.3.0 之前的 NSX 版本升级到 NSX 6.3.0 或更高版本时，不能在完成升级之前启用 FIPS 模式。如果在完成升级之前启用 FIPS 模式，将中断升级的组件和未升级的组件之间的通信。有关详细信息，请参见《NSX 升级指南》中的“了解 FIPS 模式和 NSX 升级”。

• 在 OS X Yosemite 和 OS X El Capitan 上支持的密码：如果在 OS X 10.11 (EL Capitan) 上使用 SSL VPN 客户端，您可以使用 AES128-GCM-SHA256、ECDHE-RSA-AES128-GCM-SHA256、ECDHE-RSA-AES256-GCM-SHA38、AES256-SHA 和 AES128-SHA 密码进行连接，使用 OS X 10.10 (Yosemite) 的客户端只能使用 AES256-SHA 和 AES128-SHA 进行连接。

• 在完成到 NSX 6.3.0 的升级之前，不要启用 FIPS。有关详细信息，请参见《NSX 升级指南》中的“了解 FIPS 模式和 NSX 升级”。

• 在启用 FIPS 之前，请确认任何合作伙伴解决方案都已通过 FIPS 模式认证。请参见《VMware 兼容性指南》和相关的合作伙伴文档。

已知问题

已知问题分为以下几类：

• 一般已知问题
• 安装和升级已知问题
• NSX Manager 已知问题
• 逻辑网络已知问题和 NSX Edge 已知问题
• 安全服务已知问题
• 监控服务已知问题
• 解决方案互操作性已知问题
• NSX Controller 已知问题

一般已知问题

新增：问题 1740625、1749975：Mac OS 上 Firefox 和 Safari 中的 UI 问题
如果在 Mac OS 中使用 Firefox 或 Safari，则“返回”导航按钮在 vSphere 6.5 Web Client 的“网络和安全”页面中的 NSX Edge 上无法正常工作，并且 UI 有时在 Firefox 中冻结。

解决办法：在 Mac OS 上使用 Google Chrome，或者单击“主页”按钮，然后根据需要继续操作。

问题 1700980：对于 CVE-2016-2775 漏洞安全修补程序，查询名称过长会导致在 lwresd 中出现段错误

NSX 6.2.4 随产品一起安装了 BIND 9.10.4，但它在named.conf 中不使用 lwres 选项，因此，该产品不存在漏洞。

解决办法：由于该产品不存在漏洞，因此，不需要解决办法。

问题 1558285：从 vCenter 中删除部署了 Guest Introspection 的群集时会导致空指针异常
在从 vCenter 中移除群集之前，必须首先移除 Guest Introspection 等服务

解决办法：对于没有与任何群集关联的服务部署，删除其 EAM 代理机构。

问题 1629030：数据包捕获中央 CLI（调试数据包捕获和显示数据包捕获）需要 vSphere 5.5U3 或更高版本
较早的 vSphere 5.5 版本不支持这些命令。

解决办法：VMware 建议所有 NSX 客户运行 vSphere 5.5U3 或更高版本。

问题 1568180：使用 vCenter Server Appliance (vCSA) 5.5 时，NSX 的功能列表不正确
您可以通过在 vSphere Web Client 中选择许可证，然后单击操作 > 查看功能来查看该许可证的功能。如果您升级到 NSX 6.2.3，您的许可证会升级到企业许可证，这将启用所有功能。然而，如果 NSX Manager 已经在 vCenter Server Appliance (vCSA) 5.5 中注册，那么，选择“查看功能”将会显示升级之前所使用的许可证功能列表，而不是新的企业许可证。

解决办法：所有企业许可证都有相同的功能，即使它们未正确显示在 vSphere Web Client 中也是如此。有关详细信息，请参见 NSX 许可页面。

安装和升级已知问题

升级之前，请阅读本文档前文的升级说明一节。

新增：问题 1734245：“数据安全”导致升级到 6.3.0 的操作失败
如果将“数据安全”配置为服务策略的一部分，则升级到 6.3.0 的操作将会失败。确保在升级之前从所有服务策略中移除“数据安全”。

新增：问题 1801685：从 6.2.x 升级到 6.3.0 后因无法连接到主机而看不到 ESXi 上的筛选器
在从 NSX 6.2.x 升级到 6.3.0 并将群集 VIB 升级到 6.3.0 之后，即使安装状态显示成功并且启用了防火墙，“通信通道运行状况”也会将“NSX Manager 到防火墙代理”连接和“NSX Manager 到控制层面代理”连接显示为关闭。这将导致防火墙规则发布和安全策略发布失败，以及 VXLan 配置无法发送到主机。

解决办法：使用 API POST https://<NSX-IP>/api/2.0/nwfabric/configure?action=synchronize 对群集运行消息总线同步 API 调用。
API 正文：

<nwFabricFeatureConfig><featureId>com.vmware.vshield.vsm.messagingInfra</featureId><resourceConfig><resourceId>{Cluster-MOID}</resourceId></resourceConfig>
</nwFabricFeatureConfig>

新增：问题 1808478：如果从 NSX 6.2.x 升级到 NSX 6.3.0 后无法分配 vmvisor 内存，vsfwd 服务将无法启动
如果从 NSX 6.2.x 升级到 NSX 6.3.0 后无法分配 vmvisor 内存，vsfwd 服务将无法启动。有关详细信息，请参阅 VMware 知识库文章 2148974。

解决办法：与 VMware 客户支持人员联系。

新增：问题 1818257：在 ESXi 6.0 上将 NSX 6.2.x 升级到 6.3.0 时，如果 VXLAN 中使用增强 LACP，则主机升级后，不会向控制器报告 VTEP 信息
在 ESXi 6.0 上将 NSX 6.2.x 升级到 6.3.0 时，如果使用增强 LACP，则主机升级后，不会向控制器报告 VTEP 信息。有关详细信息，请参阅 VMware 知识库文章 2149210。

解决办法：与 VMware 客户支持人员联系。

新增：问题 1791371：在将 ESXi 主机升级到 vSphere 6.5a 时，如果并行升级 Guest Introspection 和 VXLAN VIB，则会发出警报
对于 vSphere 6.5a，Guest Introspection 和 VXLAN VIB 是不同的，在并行升级它们时，VXLAN VIB 升级将发出警报，要求重新引导主机。

解决办法：在升级到 vSphere 6.5a 时，先安装 VXLAN VIB，然后安装 Guest Introspection VIB。

新增：问题 1805983：在升级到 NSX 6.2.5、6.2.6 或 6.3.0 时，如果虚拟服务器不包含服务器池，则无法正常工作。
不含服务器池的虚拟服务器只能用于 HTTP/HTTPS 重定向。其他功能均无法使用。

解决办法：创建一个不含任何成员的虚拟池，然后将其分配给虚拟服务器。

新增：问题 1797307：NSX Edge 在升级或重新部署后可能陷入脑裂状况
在备用 NSX Edge 上，show service highavailability CLI 命令将高可用性状态显示为“备用”，但将配置引擎状态显示为“活动”。

解决办法：重新引导备用 NSX Edge。

新增：问题 1789989：在主机群集升级过程中，数据层面可能会出现数据包丢失
在 VIB 升级过程中，保留于 VIB 中的 VSFWD（vShield 防火墙守护进程）密码文件会被移除，因此 VSFWD 无法使用旧密码连接到 NSX Manager，需要等到新密码更新后才能连接。主机重新引导后，此进程需要花一点时间才能完成，但在完全自动化的 DRS 群集中，准备主机启动后会立即移动虚拟机，由于 VSFWD 进程在此时尚未做好准备，因此数据层面中的数据包有可能会在短暂的时间内丢失。

解决办法：请不要在主机重新启动后立即进行故障恢复，而是对这些虚拟机的新准备主机延迟故障恢复。

新增：问题 1797929：消息总线通道在主机群集升级后出现故障
在主机群集升级后，vCenter 6.0（和更低版本）不会生成事件“重新连接”，因此，NSX Manager 也不会在主机上设置消息基础架构。vCenter 6.5 中已修复此问题。

解决办法：重新同步消息基础架构，如下所示：
POST https://<ip&gt:/api/2.0/nwfabric/configure?action=synchronize

<nwFabricFeatureConfig><featureId>com.vmware.vshield.vsm.messagingInfra</featureId><resourceConfig><resourceId>host-15</resourceId></resourceConfig>
</nwFabricFeatureConfig>

新增：问题 1802688：从 NSX 6.2.x 升级到 6.3.0 不会反映更新的 DFW 启用状态
在从 NSX 6.2.x 升级到 6.3.0 并将群集 VIB 升级到 6.3.0 之后，当您向已升级的群集添加新主机时，相关主机和群集的防火墙状态持续繁忙，且不会更新，即使在新主机上安装了新 VIB 也是如此。

解决办法：执行以下操作：

1. 使用 API POST https://<NSX-IP>/api/2.0/nwfabric/configure?action=synchronize 对主机运行消息总线同步 API 调用。这将使主机和群集防火墙状态变为“已禁用”。

   <nwFabricFeatureConfig><featureId>com.vmware.vshield.vsm.messagingInfra</featureId><resourceConfig><resourceId>{HOST-ID}</resourceId></resourceConfig>
   </nwFabricFeatureConfig>

2. 现在通过 UI 中的“安装”>“主机准备”页面为该群集启用防火墙。这会使该群集中的所有主机都变为 DFW 已启用模式。

问题 1768144：在升级或重新部署过程中，超出新限制的旧 NSX Edge 设备资源预留可能会导致失败
在 NSX 6.2.4 及更低版本中，可以为 NSX Edge 设备指定任意大小的资源预留。NSX 不会强制实施最大值。在将 NSX Manager 升级到 6.2.5 或更高版本后，如果现有 Edge 的预留资源（特别是内存）超过为所选规格大小新强制实施的最大值，则在 Edge 升级或重新部署（将会触发升级）过程中会失败。例如，如果用户在 6.2.5 以前版本的中型 Edge 上将内存预留指定为 1000 MB，并在升级到 6.2.5 后将设备大小更改为“精简”，则用户指定的内存预留将超过新强制实施的最大值（在此示例中，精简 Edge 的最大值为 512 MB），并且操作会失败。
有关从 NSX 6.2.5 开始的建议资源分配的信息，请参见升级 Edge 服务网关 (ESG)。

解决办法：使用设备 REST API PUT https://<NSXManager>/api/4.0/edges/<edge-Id>/appliances/ 重新配置内存预留，使其值不超过为该规格大小指定的值，除此之外，无需进行任何其他设备更改。您可以在此操作完成后更改设备大小。

问题 1600281：Guest Introspection 的 USVM 安装状态在“服务部署”选项卡中显示为“失败”

如果 Guest Introspection 通用 SVM 的备用数据存储脱机或变得无法访问，可能需要重新引导或重新部署 USVM 才能恢复。

解决办法：重新引导或重新部署 USVM 以进行恢复。

问题 1660373：vCenter 强制实施已过期的 NSX 许可证

从 vSphere 5.5 Update 3 或 vSphere 6.0.x 开始，vSphere Distributed Switch 包含在 NSX 许可证中。然而，如果 NSX 许可证已过期，vCenter 不允许将 ESX 主机添加到 vSphere Distributed Switch。

解决办法：您的 NSX 许可证必须处于活动状态，才能将主机添加到 vSphere Distributed Switch。

问题 1569010/1645525：在连接到 vCenter 5.5 的系统上，从 6.1.x 升级到 NSX for vSphere 6.2.3 时，“分配许可证密钥”窗口中的“产品”字段将 NSX 许可证显示为通用值“NSX for vSphere”，而不是比较具体的版本，如“NSX for vSphere - Enterprise”。

解决办法：无。

问题 1636916：在 vCloud Air 环境中，当 NSX Edge 版本从 vCNS 5.5.x 升级到 NSX 6.x 时，源协议值为“any”的 Edge 防火墙规则更改为“tcp:any, udp:any”
因此，ICMP 流量会被阻止，并且可能会出现丢弃数据包的情况。

解决办法：在升级您的 NSX Edge 版本之前，创建更加具体的 Edge 防火墙规则，并将“any”替换为具体的源端口值。

问题 1660355：从 6.1.5 迁移到 6.2.3 和更高版本的虚拟机将不支持 TFTP ALG
即使已启用主机，从 6.1.5 迁移到 6.2.3 和更高版本的虚拟机也不支持 TFTP ALG。

解决办法：在排除列表中添加并移除该虚拟机，或重新启动该虚拟机，以便创建支持 TFTP ALG 的新 6.2.3（和更高版本）筛选器。

问题 1474238：执行 vCenter 升级后，vCenter 可能会与 NSX 断开连接
如果您正在使用 vCenter 嵌入式 SSO 并且想要将 vCenter 5.5 升级到 vCenter 6.0，则 vCenter 可能会断开与 NSX 的连接。如果您已使用 root 用户名向 NSX 注册 vCenter 5.5，则会出现这种情况。在 NSX 6.2 中，使用 root 进行 vCenter 注册的做法已弃用。
注意：如果您正在使用外部 SSO，则不需要进行任何更改。您可以保留相同的用户名（例如 admin@mybusiness.mydomain），而且 vCenter 不会断开连接。

解决办法：使用 administrator@vsphere.local 用户名向 NSX 注册 vCenter，而不要使用 root。

问题 1332563：关闭电源之前关闭代理虚拟机 (SVA) 的客户机操作系统
将主机置于维护模式时，会关闭所有服务设备的电源，而不是正常关闭。这可能会导致第三方设备出现错误。

解决办法：无。

问题 1473537：无法打开使用“服务部署”视图部署的服务设备的电源

解决办法：在继续操作之前，请确认以下事项：

• 虚拟机部署已完成。

• vCenter 任务窗格中不显示虚拟机的克隆和重新配置等正在进行的任务。

• 在虚拟机的 vCenter 事件窗格中，启动部署后会显示以下事件：
   
  代理虚拟机 <vm name> 已置备。
  将代理标记为可用，以继续执行代理工作流。
   
  在这种情况下，删除服务虚拟机。在服务部署 UI 中，部署显示为“失败”。单击红色图标后，主机上将显示代理虚拟机不可用的警报。解决警报后，将重新部署和启动虚拟机。

如果未准备好环境中的所有群集，则分布式防火墙的升级消息不会显示在“安装”页面的“主机准备”选项卡上
为网络虚拟化准备群集时，会在这些群集上启用分布式防火墙。如果未准备好环境中的所有群集，则分布式防火墙的升级消息不会显示在“主机准备”选项卡上。

解决办法：使用以下 REST 调用升级分布式防火墙：
PUT https://<nsxmgr-ip>/api/4.0/firewall/globalroot-0/state

问题 1215460：如果在升级后修改服务组以添加或移除服务，则这些更改不会反映在防火墙表中
在升级过程中，Edge 防火墙表中用户创建的服务组展开，例如，防火墙表中的“服务”列显示服务组内的所有服务。如果在升级后修改服务组以添加或移除服务，则这些更改不会反映在防火墙表中。

解决办法：使用其他名称新建一个服务组，并在防火墙规则中使用此服务组。

问题 1413125：升级后无法重新配置 SSO
如果在 NSX Manager 上配置的 SSO 服务器是 vCenter Server 上的本机服务器，则在 vCenter Server 升级到 6.0 版本且 NSX Manager 升级到 6.x 版本后，无法在 NSX Manager 上重新配置 SSO 设置。

解决办法：无。

问题 1266433：SSL VPN 不向远程客户端发送升级通知
SSL VPN 网关不向用户发送升级通知。管理员必须手动通知远程用户 SSL VPN 网关（服务器）已更新，并通知用户必须更新其客户端。

解决办法：用户需要手动卸载旧版本的客户端并安装最新版本。

问题 1474066：启用或禁用 IP 检测的 NSX REST API 调用似乎不起作用
如果主机群集准备尚未完成，则启用或禁用 IP 检测的 NSX REST API 调用 (https://<nsxmgr-ip>/api/2.0/xvs/networks/universalwire-5/features) 将不起作用。

解决办法：发出 API 调用之前，请确保主机群集准备已完成。

问题 1459032：配置 VXLAN 网关时出错
使用静态 IP 池配置 VXLAN（网络和安全 > 安装 > 主机准备 > 配置 VXLAN）且配置无法在 VTEP 上设置 IP 池网关 IP（因为网关未正确配置或不可访问）时，主机群集的 VXLAN 配置会进入“错误 (红色)”状态。

错误消息为：无法在主机上设置 VXLAN 网关 (VXLAN Gateway cannot be set on host)，错误状态为：VXLAN_GATEWAY_SETUP_FAILURE。在 REST API 调用 GET https://<nsxmgr-ip>/api/2.0/nwfabric/status?resource=<cluster-moid> 中，VXLAN 的状态如下所示：

<nwFabricFeatureStatus> <featureId>com.vmware.vshield.nsxmgr.vxlan</featureId> <featureVersion>5.5</featureVersion> <updateAvailable>false</updateAvailable> <status>RED</status> <message>VXLAN Gateway cannot be set on host</message> <installed>true</installed> <enabled>true</enabled> <errorStatus>VXLAN_GATEWAY_SETUP_FAILURE</errorStatus> </nwFabricFeatureStatus>

解决办法：要解决此错误，有两种办法。

• 方法 1：移除主机群集的 VXLAN 配置，通过确保网关配置正确且可访问来修复 IP 池中的基础网关设置，然后为主机群集重新配置 VXLAN。

• 方法 2：执行以下步骤。

  1. 通过确保网关配置正确且可访问来修复 IP 池中的基础网关设置。

  2. 将主机置于维护模式，确保主机上没有任何活动的虚拟机流量。

  3. 从主机中删除 VXLAN VTEP。

  4. 使主机退出维护模式。使主机退出维护模式会触发 NSX Manager 上的 VXLAN VTEP 创建过程。NSX Manager 将尝试在主机上重新创建所需 VTEP。

问题 1462319：“esxcli software vib list | grep esx”命令输出不再包含 esx-dvfilter-switch-security VIB。
从 NSX 6.2 开始，esx-dvfilter-switch-security 模块包含在 esx-vxlan VIB 中。为 6.2 安装的 NSX VIB 只有 esx-vsip 和 esx-vxlan。在 NSX 升级至 6.2 的过程中，已从 ESXi 主机中移除旧的 esx-dvfilter-switch-security VIB。
从 NSX 6.2.3 开始，将随 esx-vsip 和 esx-vxlan NSX VIB 一起提供第三个 VIB esx-vdpi。成功安装后将显示全部 3 个 VIB。

解决办法：无。

问题 1481083：升级后，配置了明确故障切换绑定的逻辑路由器可能无法正确转发数据包
主机运行 ESXi 5.5 时，明确故障切换 NSX 6.2 绑定策略不支持分布式逻辑路由器上的多个活动上行链路。

解决办法：更改明确故障切换绑定策略，以便只有一个活动上行链路，其他上行链路处于待机模式。

问题 1485862：从主机群集卸载 NSX 有时会导致出现错误状况
使用安装 > 主机准备选项卡上的“卸载”操作时，可能会发生错误并在主机的 EAM 日志中显示 eam.issue.OrphanedAgency 消息。使用“解决”操作并重新引导主机后，即使已成功卸载 NSX VIB，还是会显示错误状态。

解决办法：从 vSphere ESX Agent Manager 中删除孤立的代理机构（系统管理 > vCenter Server 扩展 > vSphere ESX Agent Manager）。

问题 1411275：在 NSX for vSphere 6.2 中进行备份和还原后，vSphere Web Client 不显示“网络和安全”选项卡
在升级到 NSX for vSphere 6.2 后，当您执行备份和还原操作时，vSphere Web Client 不显示网络和安全选项卡。

解决办法：还原 NSX Manager 备份后，您将从 NSX Manager 虚拟设备管理门户注销。请等待几分钟，然后再登录 vSphere Web Client。

使用“安装”页面上的“服务部署”选项卡部署的服务虚拟机无法开机

解决办法：按照下面的步骤执行操作。

1. 从群集中的 ESX 代理资源池中手动移除服务虚拟机。
2. 单击网络和安全，然后单击安装。
3. 单击服务部署选项卡。
4. 选择相应的服务并单击解决图标。
   将重新部署服务虚拟机。

问题 1764460：完成主机准备后，所有群集成员都显示处于“就绪”状态，但群集级别错误地显示为“无效”
完成主机准备后，所有群集成员都正确地显示处于“就绪”状态，但群集级别显示为“无效”，对此显示的原因是需要重新引导主机，即使该主机已重新引导也是如此。

解决办法：单击红色的警告图标，然后选择“解决办法”。

NSX Manager 已知问题

新增：问题 1800820：如果已从系统中删除旧 UDLR 接口，辅助 NSX Manager 上的 UDLR 接口更新将失败
如果复制程序在主 NSX Manager 上停止工作，您必须删除主 NSX Manager 上的 UDLR（通用分布式逻辑路由器）和 ULS（通用逻辑交换机）接口并创建新的接口，然后在辅助 NSX Manager 上复制这些更改。在这种情况下，不会在辅助 NSX Manager 中更新 UDLR 接口，因为复制期间在辅助 NSX Manager 上创建了新的 ULS 而 UDLR 未连接到新 ULS。

解决办法：确保复制程序正在运行，删除主 NSX Manager 上连接新建 ULS 的 UDLR 接口 (LIF)，然后重新创建 UDLR 接口 (LIF) 并连接相同的 ULS。

新增：问题 1770436：即使不存在重复的 IP，也会生成警示
有时，即使网络中并不存在重复的 NSX Manager IP 地址，arping 命令也会报告存在这种情况。这将生成一个误报事件。

解决办法：与 VMware 客户支持人员联系。

新增：问题 1772911：NSX Manager 的执行速度因磁盘空间消耗变得异常缓慢，任务和作业表大小不断增加，CPU 使用率接近 100%
您将遇到以下问题：

• NSX Manager CPU 使用率达 100%，或其峰值经常达到 100%，即使向 NSX Manager 设备添加额外资源也不起作用。
• 在 NSX Manager 命令行界面 (CLI) 中运行 show process monitor 命令，将显示 CPU 周期消耗最高的 Java 进程。
• 在 NSX Manager CLI 中运行 show filesystems 命令会显示 /common 目录，因为它达到了非常高的使用百分比，如超过 90%。
• 某些配置更改超时（有时长达 50 分钟以上）并且没有效果。

有关详细信息，请参见 VMware 知识库文章 2147907。

解决办法：与 VMware 客户支持人员联系以解决该问题。

新增：问题 1785142：在主和辅助 NSX Manager 之间的通信被阻止时，主 NSX Manager 上会延迟显示“同步问题”。
在主和辅助 NSX Manager 之间的通信被阻止时，您将不会立即在主 NSX Manager 上看到“同步问题”。

解决办法：等候大约 20 分钟以使通信重新建立连接。

新增：问题 1786066：在跨 vCenter NSX 安装中，断开辅助 NSX Manager 的连接可能会使 NSX Manager 无法作为辅助 NSX Manager 重新连接
在跨 vCenter NSX 安装中，如果断开辅助 NSX Manager 的连接，以后可能无法将该 NSX Manager 重新添加为辅助 NSX Manager。尝试作为辅助 NSX Manager 重新连接 NSX Manager 时，此 NSX Manager 将会在 vSphere Web Client 的“管理”选项卡中被列为“辅助”，但不会建立与主 NSX Manager 的连接。

解决办法：执行以下操作：

1. 断开辅助 NSX Manager 与主 NSX Manager 的连接。
2. 再次将辅助 NSX Manager 添加到主 NSX Manager。

新增：问题 1713669：当数据库表 ai_useripmap 增长得过大时，NSX Manager 会因磁盘已满而失败
此问题导致 NSX Manager 设备磁盘被填满，从而造成 NSX Manager 失败。在重新引导后无法启动 postgres 进程。“/common”分区已满。该问题通常发生于使事件日志服务器 (ELS) 负载过重的站点以及 Guest Introspection (GI) 流量较大的站点。使用身份标识防火墙 (IDFW) 的站点会频繁受到影响。有关详细信息，请参见 VMware 知识库文章 2148341。

解决办法：请联系 VMware 客户支持以获取有关从此问题恢复的帮助。

问题 1787542：在主 NSX Manager 上还原数据库后，在辅助 NSX Manager 日志中发生异常
在主 NSX Manager 上还原数据库后，恢复的通用 DFW 区域在辅助 NSX Manager 上不可见。

解决办法：无。重新引导辅助 NSX Manager 以进行恢复。

新增：问题 1715354：REST API 可用性延迟
在切换 FIPS 模式时，在 NSX Manager 重新启动后，NSX Manager API 需要一些时间才会启动并运行。该 API 似乎已挂起，但发生这种情况是因为，控制器需要一些时间以重新建立与 NSX Manager 的连接。建议您等待 NSX API 服务器启动并运行，并确保所有控制器处于已连接状态，然后再执行任何操作。

问题 1441874：在 vCenter 链接模式环境中升级单个 NSX Manager 时显示错误消息
如果环境中的多个 VMware vCenter Server 具有多个 NSX Manager，从 vSphere Web Client 的“网络和安全”>“安装”>“主机准备”中选择一个或多个 NSX Manager 时，将会看到以下错误：
“无法与 NSX Manager 建立通信。请联系管理员。”(Could not establish communication with NSX Manager. Please contact administrator.)

解决办法：有关详细信息，请参见 VMware 知识库文章 2127061。

问题 1696750：通过 PUT API 为 NSX Manager 分配 IPv6 地址需要重新引导才能生效
通过 https://{NSX Manager IP address}/api/1.0/appliance-management/system/network 更改为 NSX Manager 配置的网络设置需要重新引导系统才能生效。在重新引导之前，将显示先前存在的设置。

解决办法：无。

问题 1529178：上载不包含常用名称的服务器证书会返回消息“内部服务器错误”(internal server error)

如果上载的服务器证书不包含常用名称，会显示消息“内部服务器错误”(internal server error)。

解决办法：使用同时包含 SubAltName 和常用名称的服务器证书，或者使用至少包含一个常用名称的服务器证书。

问题 1655388：在日语、简体中文和德语版本的 Windows 10 操作系统上使用 IE11/Edge 浏览器时，NSX Manager 6.2.3 UI 显示英语，而不是本地语言。

在日语、简体中文和德语版本的 Windows 10 操作系统上使用 IE11/Edge 浏览器启动 NSX Manager 6.2.3 时，显示英语。

解决办法：

执行下列步骤：

1. 启动 Microsoft 注册表编辑器 (regedit.exe)，然后转到计算机 > HKEY_CURRENT_USER > SOFTWARE > Microsoft > Internet Explorer > International。
2. 将 AcceptLanguage 文件的值改为本地语言。例如，如果希望将语言改为德语，请更改该文件的值，让 DE 显示在最前面。
3. 重新启动浏览器，然后再次登录 NSX Manager。此时将显示相应的语言。

问题 1435996：从 NSX Manager 导出为 CSV 的日志文件使用 Epoch（而不是日期时间）作为时间戳
使用 vSphere Web Client 从 NSX Manager 导出的 CSV 格式的日志文件，其时间戳标记为 Epoch 时间（以毫秒为单位），而不是基于时区的相应时间。

解决办法：无。

问题 1644297：主 NSX 上任何 DFW 部分的添加/删除操作都会在辅助 NSX 上创建两个已保存的 DFW 配置
在跨 vCenter 安装中，将其他通用或本地 DFW 部分添加到主 NSX Manager 后，会在辅助 NSX Manager 上保存两个 DFW 配置。尽管这个问题并不影响任何功能，但它将导致更快地达到已保存的配置限制，同时还可能会覆盖重要配置。

解决办法：无。

问题 1534877：如果主机名的长度超过 64 个字符，不会启动 NSX 管理服务
要通过 OpenSSL 库创建证书，需要使用少于或等于 64 个字符的主机名。

问题 1537258：NSX Manager 列表在 Web Client 中显示缓慢
在拥有多个 NSX Manager 的 vSphere 6.0 环境中，当通过大型 AD 组集对登录用户进行验证时，vSphere Web Client 可能需要多达两分钟才能显示 NSX Manager 列表。在尝试显示 NSX Manager 列表时，可能会出现数据服务超时错误。没有解决办法。必须等待列表加载/重新登录后，才能看到 NSX Manager 列表。

问题 1534606：“主机准备”页面加载失败
当在链接模式下运行 vCenter 时，每个 vCenter 都必须连接到相同 NSX 版本的 NSX Manager。如果 NSX 版本不同，vSphere Web Client 将只能与运行较高 NSX 版本的 NSX Manager 通信。“主机准备”选项卡将显示类似以下内容的错误：“无法与 NSX Manager 建立通信。请联系管理员”(Could not establish communication with NSX Manager. Please contact administrator)。

解决办法：应当将所有 NSX Manager 都升级到相同的 NSX 软件版本。

问题 1386874：vSphere Web Client 中不显示“网络和安全”选项卡
vSphere 升级到 6.0 后，使用 root 用户名登录到 vSphere Web Client 时，看不到“网络和安全”选项卡。

解决办法：使用 administrator@vsphere.local 登录，或使用升级前 vCenter Server 上其角色已在 NSX Manager 中定义的任何其他 vCenter 用户登录。

问题 1027066：对 NSX Manager 执行 vMotion 操作可能会显示以下错误消息：“虚拟以太网卡网络适配器 1 不受支持 (Virtual ethernet card Network adapter 1 is not supported)”
可以忽略此错误。在执行该 vMotion 操作后，网络将正常工作。

问题 1477041：NSX Manager 虚拟设备摘要页面不显示 DNS 名称
登录到 NSX Manager 虚拟设备时，“摘要”页面显示 DNS 名称字段。即使为 NSX Manager 设备定义了 DNS 名称，此字段仍为空。

解决办法：您可以在“管理”>“网络”页面上查看 NSX Manager 的主机名和搜索域。

问题 1492880：使用 NSX 命令行界面更改密码后，NSX Manager UI 不会自动注销
登录到 NSX Manager 且最近使用 CLI 更改了密码后，可能仍会使用旧密码在 NSX Manager UI 中保持登录状态。通常，如果会话处于不活动状态导致超时，NSX Manager 客户端应自动将您注销。

解决办法：从 NSX Manager UI 注销并使用新密码重新登录。

问题 1468613：无法编辑网络主机名
登录到 NSX Manager 虚拟设备并导航到“设备管理”后，单击“管理设备设置”，然后单击“设置”下的“网络”以编辑网络主机名，您可能会收到无效域名列表的错误。“搜索域”字段中指定的域名以空白字符而非逗号分隔时会发生此情况。NSX Manager 只接受以逗号分隔的域名。
解决办法：执行下列步骤：

1. 登录到 NSX Manager 虚拟设备。

2. 在设备管理下面，单击管理设备设置。

3. 在“设置”面板中，单击网络。

4. 单击 DNS 服务器旁边的编辑。

5. 在“搜索域”字段中，将所有空白字符替换为逗号。

6. 单击确定保存更改。

问题 1436953：即使成功从备份还原 NSX Manager，也会生成错误的系统事件
成功从备份还原 NSX Manager 后，当您导航到网络和安全 > NSX Manager > 监控 > 系统事件时，vSphere Web Client 中会显示以下系统事件。

• 无法从备份还原 NSX Manager (严重性=严重)(Restore of NSX Manager from backup failed (with Severity=Critical))。

• 已成功还原 NSX Manager (严重性=信息)(Restore of NSX Manager successfully completed (with Severity=Informational))。

解决办法：如果最后的系统事件消息显示为成功，您可以忽略系统生成的事件消息。

问题 1489768：在数据中心添加命名空间的 NSX REST API 调用的行为更改
在 NSX 6.2 中，POST https://<nsxmgr-ip>/api/2.0/namespace/datacenter/ REST API 调用返回包含绝对路径的 URL，例如 http://198.51.100.3/api/2.0/namespace/api/2.0/namespace/datacenter/datacenter-1628/2。在先前版本的 NSX 中，此 API 调用返回包含相对路径的 URL，例如：/api/2.0/namespace/datacenter/datacenter-1628/2。

解决办法：无。

逻辑网络已知问题和 NSX Edge 已知问题

新增：问题 1825416：在升级到 NSX for vSphere 6.3.x 后，受保护的 vApp 在 vCloud Director 8.20 中失败
在 vCloud Director 8.20 中升级到 NSX 6.3.x 并将 NSX Edge 网关升级到 6.3.x 后，受保护的 vApp 失败，并且受保护的网络中的虚拟机无法与其网关进行通信。有关详细信息，请参阅 VMware 知识库文章 2150010。

解决办法：与 VMware 客户支持人员联系。

新增：问题 1781438：在 ESG 或 DLR NSX Edge 设备上，如果多次收到 BGP 路径属性 MULTI_EXIT_DISC，路由服务不会发送错误消息。
如果多次收到 BGP 路径属性 MULTI_EXIT_DISC，Edge 路由器或分布式逻辑路由器不会发送错误消息。根据 RFC 4271 [第 5 节]，相同的属性（具有相同类型的属性）不能在特定更新消息的“路径属性”字段中多次出现。

解决办法：无。

新增：问题 1860583：如果无法访问 DNS，应避免将远程系统日志记录程序作为 FQDN。
在 NSX Edge 上，如果使用 FQDN 配置远程系统日志记录程序并且无法访问 DNS，则路由功能可能会受到影响。可能不会持续出现该问题。

解决办法：建议使用 IP 地址而不是 FQDN。

新增：问题 1791264：双击传输区域无法启用/禁用 CDO 模式。
当您从 vSphere Web Client 中双击某个传输区域，然后尝试在出现的“摘要”页面中启用或禁用 CDO 模式时，该操作不起任何作用。

解决办法：执行以下操作：

1. 返回到传输区域列表页面︰安装 > 逻辑网络准备 > 传输区域，然后选择所需的传输区域。
2. 从操作下拉菜单中选择启用 CDO 模式/禁用 CDO 模式。
3. 所选的操作随即将会生效。

新增：问题 1773500：无效的路由 (0.0.0.0/32) 导致 NSX 崩溃
如果您在 NSX DLR 上推送路由 0.0.0.0/32，NSX DLR 将不支持并拒绝该路由。但是，在删除关联的 LIF 并通过同一子网中的 IP 地址对其重新添加时，这仍会导致崩溃 (PSOD)。

解决办法：0.0.0.0/32 不是有效的路由。请不要配置该路由，或者使用 routemap 拒绝该路由。

新增：问题 1769941：DLR PMAC 因存在重复的 ARP 回复而使 L2VPN 网桥表“中毒”
主机上的 L2VPN 服务器 vxlan 中继端口不丢弃从客户端虚拟机发送的目标 MAC 为 pMAC 的 ARP 回复，这会导致网桥上的 MAC 表中毒，从而造成流量丢弃。

解决办法：要解决此问题，请为 VXLAN 中继 dvport 添加流量筛选器以丢弃目标为 pMAC 的 ARP 回复。

要添加流量限定符，请执行以下操作︰

1. 转到连接 NSX Edge 的 dvport。
2. 导航到“编辑设置”>“流量筛选和标记”。
3. 添加目标设置为 pMAC 的 MAC 限定符。

新增：问题 1782321：即使正确显示高可用性状态，某些 NSX Edge 也可能会出现脑裂情况
由于 HA 机制中存在争用情况，即使正确显示“高可用性状态”(Highavailability Status)，某些升级到 NSX 6.2.5 和更高版本的 NSX Edge 也可能会出现脑裂情况。在重新部署 Edge 后，也可能会出现该问题。

解决办法：重新引导备用 NSX Edge。

新增：问题 1764258：在配置了子接口的 NSX Edge 上进行 HA 故障切换或强制同步后，流量产生黑洞长达八分钟之久
如果通过子接口触发 HA 故障切换或启动强制同步，流量会产生黑洞长达八分钟之久。

解决办法：不要对 HA 使用子接口。

新增：问题 1771760：启用 NAT 后，NSX Edge 将丢弃包含 OID 类型 Counter64 的 SNMP 响应数据包。
NSX Edge 中的 SNMP ALG 无法处理 SNMP 响应数据包中的 Counter64 类型，并且该数据包将被丢弃。因此，客户端不会获得请求的响应。

解决办法：如果遇到此问题，请与 VMware 客户支持人员联系。

新增：问题 1767135：在尝试访问负载平衡器中的证书和应用程序配置文件时出错
具有安全管理员权限和 Edge 范围的用户无法访问负载平衡器中的证书和应用程序配置文件。vSphere Web Client 将显示错误消息。

解决办法：无。

新增：问题 1792548：NSX Controller 可能会停滞并显示以下消息：“正在等待加入群集”(Waiting to join cluster)
NSX Controller 可能会停滞并显示以下消息：“正在等待加入群集”(Waiting to join cluster)（CLI 命令：show control-cluster status）。出现该问题是因为，在控制器启动时，为控制器的 eth0 和 breth0 接口配置了相同的 IP 地址。您可以在控制器上使用以下命令验证是否存在这种情况：show network interface

解决办法：与 VMware 客户支持人员联系。

新增：问题 1747978：在 NSX Edge HA 故障切换后，删除了具有 MD5 身份验证的 OSPF 邻接
在为 NSX Edge 配置了 HA、配置了 OSPF 正常重新启动并使用 MD5 进行身份验证的 NSX for vSphere 6.2.4 环境中，OSPF 无法正常启动。只有在失效定时器在 OSPF 邻居节点上到期后，才会形成邻接。

解决办法：无

新增：问题 1803220：当控制器与主机连接断开时，将与启用了 CDO 的主机断开 VXLAN 连接
控制器断连操作 (CDO) 功能可在整个控制器群集出现故障或不可访问时确保 VXLAN 连接。但是，在控制器群集工作正常，但主机与其断开连接的情况下，仍可能会丢弃从与控制器连接的其他主机传至该主机的数据层面流量。当发生这种情况时，该主机会被从每个 VNI VTEP 列表中移除，并且将丢弃远程主机发送的 ARP。对于来自与控制器断开连接的主机的流量，CDO 功能可确保流量将能够到达正确的目标。

新增：问题 1804116：在与 NSX Manager 通信中断的主机上，逻辑路由器进入错误状态
如果在与 NSX Manager 通信中断的主机（因 NSX VIB 升级/安装失败或主机通信问题所致）上打开或重新部署逻辑路由器，此逻辑路由器将进入错误状态，而且通过强制同步执行的持续自动恢复操作将失败。

解决办法：在解决了主机和 NSX Manager 通信问题后，手动重新引导 NSX Edge 并等待显示所有界面。此解决办法仅适用于逻辑路由器，而不适用于 NSX Edge 服务网关 (ESG)，因为通过强制同步执行的自动恢复进程会重新引导 NSX Edge。

新增：问题 1783065：无法同时使用 IPv4 和 IPv6 地址来针对 UDP 端口及 TCP 配置负载平衡器
UDP 仅支持 ipv4-ipv4、ipv6-ipv6（前端-后端）。NSX Manager 中存在一个错误，即使将 IPv6 链路本地地址以分组对象 IP 地址的形式读取和推送，您也无法选择要在 LB 配置中使用的 IP 协议。

以下是一个用于展示此问题的示例 LB 配置：
在负载平衡器配置中，池“vCloud_Connector”将分组对象 (vm-2681) 配置为池成员，并且此对象同时包含 IPv4 和 IPv6 地址，LB L4 引擎不支持这种情况。

{"algorithm" : {...},"members" : [{...  ,...}],"applicationRules" : [],"name" : "vCloud_Connector","transparent" : {"enable" : false}}{"value" : ["fe80::250:56ff:feb0:d6c9","10.204.252.220"],"id" : "vm-2681"}

解决办法：

• 方法 1：输入池成员的 IP 地址，而不是池成员中分组对象的 IP 地址。
• 方法 2：请不要在虚拟机中使用 IPv6。

新增：问题 1773127：在涉及大量主机和逻辑交换机的设置中，显示给定逻辑交换机相关主机的屏幕未能正确加载。
当从涉及大量主机的设置中选择“逻辑交换机”>“相关对象”>“主机”时，vSphere Web Client 在等待了数分钟之后加载失败并显示以下错误：数据服务超时，因为某个后端任务运行了超过 120 秒 (The data service timed out because a back-end task took more than 120 seconds)。发生该问题是因为对 NSX Manager 的远程 API 调用需要太长时间才能返回。

解决办法：可通过以下两种方法解决此问题：

• 第一种方法：可以按照 VMware 知识库文章 2040626 中所述，增加 API 超时以避免该问题。您可能需要在增加此超时后重新启动 vSphere Web Client。增加超时有可能会导致如下结果：虽然不会出现任何错误，但是您将需要等待 2 至 4 分钟才能重新加载页面。
• 第二种方法：如果您只希望正确查看相关主机，则可以转到“主页”>“网络”>“端口组”>“相关对象”>“主机”，以查看与逻辑交换机关联的主机列表。

新增：问题 1777792：设置为“ANY”的对等端点导致 IPSec 连接失败
当 NSX Edge 上的 IPSec 配置将远程对等端点设置为“ANY”时，Edge 将充当 IPSec“服务器”，并等待远程对等端点启动连接。但是，如果启动程序使用 PSK 和 XAUTH 发送身份验证请求，则 Edge 显示以下错误消息：“在 XXX.XXX.XX.XX:500 上收到初始主模式消息，但是连接没有通过 policy=PSK+XAUTH 进行授权”(initial Main Mode message received on XXX.XXX.XX.XX:500 but no connection has been authorized with policy=PSK+XAUTH)，并且无法建立 IPSec。

解决办法：在 IPSec VPN 配置中使用特定的对等端点 IP 地址或 FQDN，而不是“ANY”。

新增：问题 1770114：成功准备主机后没有清除群集级别的错误消息。
当将 IP 池分配给没有足够 IP 地址的群集，然后尝试向该群集添加主机时，会收到错误“IP 地址不足”(Insufficient IP addresses)。即使在您更改此池以添加其他 IP 地址，并且可以成功向该群集添加主机之后，此错误消息依然存在于群集级别。

解决办法：与 VMware 客户支持人员联系。

问题 1789088：NSX Edge 停滞在 grub 命令行提示符中
NSX Edge 可能引导失败并停滞在 grub 命令行提示符中。

解决办法：

• 首先，调查以下项：
  1. 使用 set 命令检查现有环境。
  2. 使用 ls 和 cat 命令找到并转储 /boot/grub/grub.cfg 文件。

     grub> ls /boot
     grub> ls /boot/grub
     grub> cat /boot/grub/grub.cfg
     

  3. 捕获与所发生问题当时尽可能接近的主机日志。可能存在一些指示 NFS 存储问题的 NFS 日志。

• 接下来，手动引导 NSX Edge。按顺序依次尝试以下步骤（只有在前一个步骤未能成功引导 Edge 时才尝试下一个选项）：

  1. 通过在 vSphere Web Client 中选择“电源重置”选项重新引导 Edge 虚拟机。

  2. 或者再次指定 grub 配置文件，应当会立即加载用于启动 Edge 的菜单。
     在 grub 提示符下调用以下命令：

     grub> configfile /boot/grub/grub.cfg

  3. 或者在 grub 提示符下使用以下命令：

     grub> insmod ext2
     grub> set root=(hd0,1)
     grub> linux /boot/vmlinuz loglevel=3 root=/dev/sda1
     grub> boot
     

问题 1741158：如果创建新 NSX Edge 而未进行配置，则应用配置可能会导致 Edge 服务过早激活。
如果使用 NSX API 创建新 NSX Edge 而未进行配置，然后执行 API 调用以禁用该 Edge 上的某个 Edge 服务（例如，将 dhcp-enabled 设置为“false”），最后将配置更改应用到禁用的 Edge 服务，则该服务将会被立即激活。

解决办法：在对希望保持禁用状态的 Edge 服务进行配置更改后，立即执行 PUT 调用以将该服务的 enabled 标记设置为“false”。

问题 1758500：对于具有多个下一跃点的静态路由，如果配置的下一跃点中至少有一个是 Edge 的 vNIC IP 地址，则该静态路由将不会安装在 NSX Edge 路由表和转发表中
在使用 ECMP 和多个下一跃点地址时，如果下一跃点 IP 地址中至少有一个有效，则 NSX 便允许将 Edge 的 vNIC IP 地址配置为下一跃点。系统会接受配置而不出现任何错误或警告，但该网络的路由会从 Edge 的路由表/转发表中移除。

解决办法：使用 ECMP 时，不要将 Edge 本身的 vNIC IP 地址配置为静态路由中的下一跃点。

问题 1716464：NSX 负载平衡器不会路由到使用安全标记新标记的虚拟机。
如果我们部署两个具有给定标记的虚拟机，然后配置一个 LB 以路由到该标记，该 LB 将成功路由到这两个虚拟机。但是，如果我们随后部署第三个具有该标记的虚拟机，该 LB 仅路由到前两个虚拟机。

解决办法：在 LB 池上单击“保存”。这会重新扫描虚拟机，并开始路由到新标记的虚拟机。

问题 1753621：在具有专用本地 AS 的 Edge 将路由发送到 EBGP 对等项时，将从发送的 BGP 路由更新中删除所有专用 AS 路径。
NSX 目前存在一个限制，即，在 AS 路径仅包含专用 AS 路径时，无法与 eBGP 邻居共享完整 AS 路径。虽然这在大多数情况下是预期行为，但在某些情况下，管理员可能希望与 eBGP 邻居共享专用 AS 路径。

解决办法：没有解决办法可以使 Edge 在 BGP 更新中声明所有 AS 路径。

问题 1461421：NSX Edge 的“show ip bgp neighbor”命令输出保留以前建立连接的历史计数

“show ip bgp neighbor”命令显示 BGP 状态计算机在给定对等连接中转换到“已建立”状态的次数。更改基于 MD5 身份验证的密码会导致对等连接被损毁并重新创建，这转而将清除计数器。Edge DLR 不会发生此问题。

解决办法：要清除计数器，请执行“clear ip bgp neighbor”命令。

问题 1676085：如果资源预留失败，将无法启用 Edge HA

从 NSX for vSphere 6.2.3 开始，如果无法为第二个 Edge 虚拟机设备预留足够的资源，在现有 Edge 上启用高可用性将失败。配置将回滚到上一个已知正常的配置。在以前的版本中，如果在 Edge 部署和资源预留失败后启用 HA，仍会创建 Edge 虚拟机。

解决办法：这是预期的行为更改。

问题 1656713：HA 故障切换之后 NSX Edge 上缺少 IPSec 安全策略 (SP)，流量无法流过隧道

待机 > 活动切换对于 IPSec 隧道上的流量无效。

解决办法：在切换 NSX Edge 后禁用/启用 IPSec。

问题 1354824：Edge 虚拟机由于电源故障等原因被损坏或无法访问时，如果 NSX Manager 中的运行状况检查失败，会引发系统事件

“系统事件”选项卡将报告事件“Edge 不可访问”(Edge Unreachability)。NSX Edge 列表可能会继续报告“已部署”状态。

解决办法：使用 https://NSX-Manager-IP-Address/api/4.0/edges/edgeId/status API 并设置 detailedStatus=true。

问题 1556924：L3 连接丢失，发生 VXLAN would block 错误

在主机上配置了 DLR LIF，但基础 VXLAN 层没有完全准备好时，通过某些 DLR LIF 建立的连接可能会受影响。无法访问某些属于 DLR 的虚拟机。在 /var/log/vmkernel.log 文件中可能会显示日志“VXLAN 中继状态创建失败: Would block”。

解决办法：您可以删除 LIF，然后再重新创建。另一种做法是重新引导受影响的 ESX 主机。

问题 1647657：在启用 DLR（分布式逻辑路由器）的 ESXi 主机上，显示命令只能为每个 DLR 实例最多显示 2000 个路由

在启用 DLR 的 ESXi 主机上，显示命令只能为每个 DLR 实例最多显示 2000 个路由，即使正在运行的路由数量超出此最大限制也是如此。这是一个显示问题，数据路径对所有路由都将按预期工作。

解决办法：无。

问题 1634215：OSPF CLI 命令输出不指示是否已禁用路由

禁用 OSPF 后，路由 CLI 命令输出不显示任何指示“OSPF 已禁用”(OSPF is disabled) 的消息。输出为空。

解决办法：show ip ospf 命令将显示正确的状态。

问题 1647739：执行 vMotion 操作之后重新部署 Edge 虚拟机会导致 Edge 或 DLR 虚拟机被放回原始群集。

解决办法：要将 Edge 虚拟机放到其他资源池或群集，请使用 NSX Manager UI 来配置所需的位置。

问题 1463856：启用 NSX Edge 防火墙后，现有 TCP 连接会被阻止
由于看不到最初的三次握手，因此会通过 Edge 状态防火墙阻止 TCP 连接。

解决办法：要处理此类现有流量，请执行以下操作。使用 NSX REST API 在防火墙全局配置中启用“tcpPickOngoingConnections”标记。这会将防火墙从严格模式切换到宽松模式。接下来，启用防火墙。现有连接正常工作（在启用防火墙后执行此操作可能需要几分钟时间）后，将“tcpPickOngoingConnections”标记重新设置为 false，以将防火墙返回到严格模式。（这是持久性设置。）

PUT /api/4.0/edges/{edgeId}/firewall/config/global

<globalConfig>
<tcpPickOngoingConnections>true</tcpPickOngoingConnections>
</globalConfig>

问题 1374523：在安装 VXLAN VIB 后需要重新引导 ESXi 或运行 [services.sh restart]，才能通过 esxcli 使用 VXLAN 命令

在安装 VXLAN VIB 后，您必须重新引导 ESXi 或运行 [services.sh restart] 命令，之后才能通过 esxcli 使用 VXLAN 命令。

解决办法：使用 localcli，而不是 esxcli。

问题 1604514：单击“发布”后，在未受管的 DLR 上编辑/配置默认网关失败

向未受管的 DLR 添加默认网关时，发布操作会失败，并显示错误消息“路由距离仅在已部署 NSX Edge 虚拟机的 NSX Edge 6.2.0 及更高版本上受支持”(Routing Distance is support only on NSX Edge version 6.2.0 and later with NSX Edge VMs deployed)。这是因为在 UI 上填充了默认管理距离“1”。

解决办法：移除默认填充的管理距离“1”。

问题 1642087：修改 IPSec VPN 扩展中的 securelocaltrafficbyip 参数值后，转发到目标网络失败

使用 NSX Edge 服务网关时，您会遇到以下症状：

• 在 NSX UI（“编辑 IPSec VPN”屏幕）中，将 securelocaltrafficbyip 值改为 0 后，无法再转发到 IPSec VPN 隧道的远程子网
• 更改此参数后，您再也看不到 IP 路由表中远程子网的正确信息

解决办法：禁用后重新启用 IPSec VPN 服务。然后，验证 CLI 和 UI 中是否显示预期的路由信息。

问题 1525003：使用不正确的密码短语还原 NSX Manager 备份时将会静默失败，因为无法访问关键引导文件夹

解决办法：无。

问题 1637639：使用 Windows 8 SSL VPN PHAT 客户端时，不会从 IP 池分配虚拟 IP。
在 Windows 8 上，当由 Edge 服务网关分配新 IP 地址，或者 IP 池改为使用不同的 IP 范围时，不会按预期从 IP 池中分配虚拟 IP 地址。

解决办法：此问题仅在 Windows 8 上出现。使用其他 Windows 操作系统可避免遇到此问题。

问题 1628220：在接收器侧看不到 DFW 或 NetX 观察。
如果与目标 vNIC 关联的交换机端口发生更改，跟踪流可能不在接收器侧显示 DFW 和 NetX 观察。将不为 vSphere 5.5 版本修复此问题。vSphere 6.0 及更高版本不存在此问题。

解决办法：不要禁用 vNIC。重新引导虚拟机。

问题 1534603：即使未启用 IPSec 和 L2 VPN 服务，其状态也显示为关闭
在 UI 中的“设置”选项卡下，L2 服务状态显示为关闭，而 API 将 L2 服务状态显示为启动。L2 VPN 和 IPSec 服务在“设置”选项卡中始终显示为关闭，除非刷新 UI 页面。

解决办法：刷新页面。

问题 1534799：关闭具有最高 IP 地址的 OSPF 区域边界路由器后，聚合缓慢
关闭或重新引导具有最高 IP 地址的基于 NSX 的 OSPF 区域边界路由器 (ABR) 后，聚合需要花费较长时间。如果关闭或重新引导 IP 地址数值并非最高的 ABR，则流量会快速聚合到其他路径。但是，如果关闭或重新引导具有最高 IP 地址的 ABR，则重新聚合需要花费数分钟时间。可以手动清除 OSPF 进程以缩短聚合时间。

问题 1446327：通过 NSX Edge 连接时，某些基于 TCP 的应用程序可能会超时
TCP 建立连接的默认非活动状态超时为 3600 秒。NSX Edge 会删除闲置时间超过非活动状态超时的任何连接，并丢弃这些连接。

解决办法：

1. 如果应用程序处于非活动状态的时间相对较长，请在主机上启用 TCP Keepalive，并将 keep_alive_interval 设置为少于 3600 秒。
2. 使用以下 NSX REST API，将 Edge TCP 非活动状态超时延长为大于 2 小时。例如，将非活动状态超时延长为 9000 秒。NSX API URL：
   /api/4.0/edges/{edgeId}/systemcontrol/config PUT Method <systemControl> <property>sysctl.net.netfilter.nf_conntrack_tcp_timeout_established=9000</property> </systemControl>

问题 1089745：无法在多个 DLR Edge 上行链路上配置 OSPF
目前，无法在多个 DLR Edge 上行链路（共 8 个）上配置 OSPF。该限制是由于每个 DLR 实例共享单个转发地址造成的。

解决办法：这是当前的系统限制，没有解决办法。

问题 1498965：Edge syslog 消息无法到达远程 syslog 服务器
Edge syslog 服务器无法在部署后立即解析任何已配置的远程 syslog 服务器的主机名。

解决办法：使用 IP 地址配置远程 syslog 服务器，或通过 UI 强制同步 Edge。

问题 1494025：更新 REST Edge API 后，逻辑路由器的 DNS 客户端配置设置未完全应用

解决办法：使用 REST API 配置 DNS 转发器（解析程序）时，请执行以下步骤：

1. 指定 DNS 客户端 XML 服务器的设置，以便使其与 DNS 转发器设置相匹配。

2. 启用 DNS 转发器，并确保转发器设置与 XML 配置中指定的 DNS 客户端服务器设置相同。

问题 1243112：启用了 ECMP 的静态路由中无效的下一跃点未显示验证和错误消息
尝试添加启用了 ECMP 的静态路由时，如果路由表不包含默认路由且静态路由配置中存在无法访问的下一跃点，将不会显示任何错误消息且不会安装静态路由。

解决办法：无。

问题 1288487：如果通过 vCenter Web Client 用户界面删除一个子接口受逻辑交换机支持的 NSX Edge 虚拟机，数据路径可能不适用于连接至同一端口的新虚拟机
当通过 vCenter Web Client 用户界面（而非 NSX Manager）删除 Edge 虚拟机时，在 dvPort 上通过不透明通道配置的 VXLAN 中继不会重置。这是因为中继配置由 NSX Manager 管理。

解决办法：按照下面的步骤手动删除 VXLAN 中继配置：

1. 通过在浏览器窗口中键入以下内容导航至 vCenter Managed Object Browser：
   https://<vc-ip>/mob?vmodl=1
2. 单击内容。
3. 按照下面的步骤检索 dvsUuid 值。
   1. 单击 rootFolder 链接（例如，group-d1(Datacenters)）。
   2. 单击数据中心名称链接（例如，datacenter-1）。
   3. 单击 networkFolder 链接（例如，group-n6）。
   4. 单击 DVS 名称链接（例如，dvs-1）。
   5. 复制 uuid 的值。
4. 单击 DVSManager，然后单击 updateOpaqueDataEx。
5. 在 selectionSet 中，添加以下 XML。

   <selectionSet xsi:type="DVPortSelection"><dvsUuid>value</dvsUuid><portKey>value</portKey> <!--port number of the DVPG where trunk vnic got connected-->
   </selectionSet>

6. 在 opaqueDataSpec 中，添加以下 XML

   <opaqueDataSpec><operation>remove</operation><opaqueData><key>com.vmware.net.vxlan.trunkcfg</key><opaqueData></opaqueData></opaqueData>
   </opaqueDataSpec>

7. 将 isRuntime 设置为 false。
8. 单击调用方法。
9. 为在已删除 Edge 虚拟机上配置的每个中继端口重复步骤 5 至 8。

问题 1637939：在部署硬件网关时，不支持 MD5 证书
将硬件网关交换机部署为用于逻辑 L2 VLAN 到 VXLAN 之间桥接的 VTEP 时，物理交换机应至少支持用于在 NSX Controller 和 OVSDB 交换机之间建立 OVSDB 连接的 SHA1 SSL 证书。

解决办法：无。

问题 1637943：对于具有硬件网关绑定的 VNI，不支持混合或多播复制模式
硬件网关交换机在用作 L2 VXLAN 到 VLAN 之间桥接的 VTEP 时，只支持单播复制模式。

解决办法：只使用单播复制模式。

安全服务已知问题

新增：问题 1847753：在检索启用了 ALG 的协议流量时，主机出现故障并显示紫色诊断屏幕
在环境中启用了流量监控的情况下将 NSX for vSphere 6.2.4 升级到 6.3.0 或 6.3.1 后，ESXi 主机显示紫色诊断屏幕。有关详细信息和解决办法，请参见 VMware 知识库文章 2149908。

问题 1474650：对于 NetX 用户，ESXi 5.5.x 和 6.x 主机显示紫色诊断屏幕，警示用户 ALERT: NMI: 709: NMI IPI received
在服务虚拟机发送或收到大量数据包时，DVFilter 持续占用 CPU，从而导致检测信号丢失并显示紫色诊断屏幕。有关详细信息，请参见 VMware 知识库文章 2149704。

解决办法：将 ESXi 主机升级到使用 NetX 所需的任何以下最低 ESXi 版本：

• 5.5 Patch 10
• ESXi 6.0U3
• ESXi 6.5

新增：问题 1676043：虚拟机在排除列表中同时添加两次后会从该列表中移除
如果两个用户同时将相同的虚拟机添加到排除列表而未刷新 UI，将导致从排除列表中移除已添加的虚拟机。

解决办法：刷新 vSphere Web Client UI，然后再将虚拟机添加到排除列表中。

新增：问题 1770259：不能将 DFW 规则的应用对象字段修改为具有多个应用对象
如果将 DFW 规则应用于一组 vNIC 或虚拟机或者群集或数据中心，发布该规则，然后希望在应用对象字段中添加其他对象以修改该规则，即使发布成功，新更改也不会生效。

解决办法：无。

新增：问题 1798779：在将 NSX 从 6.2.x 升级到 6.3.0 之后，vSphere Web Client 的 GUI 错误地允许您添加通用安全标记
6.3.0 引入了通用安全标记。尝试向升级到 NSX 6.3.0 之前在 6.2.x 中创建的通用安全组添加通用安全标记时，操作将失败并显示错误“请求的成员不是有效的成员”(The requested member is not a valid member)。此错误是正常的，因为您不能向 NSX 6.2.x 通用安全组添加通用安全标记。GUI 具有误导性。

解决办法：升级后，创建 NSX 6.3.0 通用安全组并向该组添加通用安全标记。

新增：问题 1799543：从 NSX 6.2.x 升级到 6.3.0 之后，当您创建第一个活动-备用通用安全组时，vSphere Web Client 错误地显示并允许您选择 NSX 6.2.x 通用安全组和非活动-备用通用安全组。
在创建第一个活动-备用通用安全组时，vSphere Web Client UI 错误地显示并允许您添加在 NSX 6.2.x 中创建的通用安全组。该操作将失败并显示错误“请求的成员不是有效的成员”(The requested member is not a valid member)。

解决办法：创建至少一个活动-备用通用安全组，这样以后在创建下一个活动-备用通用安全组时，将不会发生此问题。

新增：问题 1786780：在服务编排 UI 中重新排序/移动策略因对 CPU 占用率过高而需要用很长时间
在服务编排 UI 中重新排序/重新定位策略因对 CPU 占用率过高而需要用很长时间。

解决办法：以下步骤将对您有所帮助：

• 在创建策略时，尝试给予策略正确的优先级（权重），这样在首次尝试中它会被放置在正确位置，从而无需再次对策略进行重新排序。
• 如果您必须将策略移到其他位置，请编辑要移动的策略并将优先级（权重）更改为适当的值。这将对单个策略进行修改并且会很快完成。

新增：问题 1787680：在 NSX Manager 处于转换模式时，删除通用防火墙区域失败
在尝试从处于转换模式的 NSX Manager 的 UI 中删除通用防火墙区域并进行发布时，发布将失败，因而无法将 NSX Manager 设置为独立模式。

解决办法：使用单个删除区域 REST API 删除通用防火墙区域。

问题 1741844：使用 ARP 侦听功能检测具有多个 IP 地址的 vNIC 的地址时，导致 100% CPU 消耗
当虚拟机的 vNIC 配置有多个 IP 地址，并且启用了 ARP 侦听功能来进行 IP 检测时，会出现此问题。IP 发现模块会持续不断地将 vNIC-IP 更新发送到 NSX Manager，以更改配置有多个 IP 地址的所有虚拟机的 vNIC-IP 映射。

解决办法：没有解决办法。ARP 侦听功能当前仅支持每个 vNIC 具有一个 IP 地址的情况。有关详细信息，请参见《NSX 管理指南》中的“虚拟机的 IP 发现”一节。

问题 1689159：“流量监控”中的“添加规则”功能无法正常用于 ICMP 流量。
在从“流量监控”中添加规则时，如果未明确将“服务”字段设置为“ICMP”，则该字段将保留为空，结果，您最终可能会添加服务类型为“ANY”的规则。

解决办法：更新“服务”字段以反映 ICMP 流量。

问题 1632235：在 Guest Introspection 安装过程中，网络下拉列表仅显示“已在主机上指定”
使用 NSX 仅防病毒许可证和 vSphere Essential 或 vSphere Standard 许可证安装 Guest Introspection 时，网络下拉列表将仅显示现有的 DV 端口组列表。此类许可证不支持创建 DVS。

解决办法：在 vSphere 主机上使用其中一种许可证安装 Guest Introspection 之前，先在“代理虚拟机设置”窗口中指定网络。

问题 1652155：在某些情况下，使用 REST API 创建或迁移防火墙规则可能会失败，并报告 HTTP 404 错误

以下情况不支持使用 REST API 添加或迁移防火墙规则：

• 设置 autosavedraft=true 时通过批量操作创建防火墙规则。
• 在多个部分同时添加防火墙规则。

解决办法：执行防火墙规则批量创建或迁移时，在 API 调用中将 autoSaveDraft 参数设置为 false。

问题 1509687：在一次 API 调用中，一次将一个安全标记分配给多个虚拟机时，URL 长度最多支持 16000 个字符
如果 URL 长度超过 16,000 个字符，则无法在一次 API 调用中将一个安全标记同时分配给大量虚拟机。

解决办法：为了优化性能，请在一次调用中最多标记 500 个虚拟机。

问题 1662020：发布操作失败导致在 DFW UI 的“常规”和“合作伙伴安全服务”部分中显示错误消息“上次在主机 host number 上发布失败”(Last publish failed on host host number)

更改任何规则后，UI 都会显示“上次在主机 host number 上发布失败”(Last publish failed on host host number)。UI 上所列主机的防火墙规则版本可能不正确，从而导致安全性缺乏和/或网络中断。

通常在以下场景中会出现此问题：

• 从旧版 NSX 升级到最新版本之后。
• 将主机移出群集后再将其移回时。
• 将主机从一个群集移动到另一个群集时。

解决办法：要解决此问题，您必须强制同步受影响的群集（仅限防火墙）。

问题 1481522：不支持从 6.1.x 向 6.2.3 迁移防火墙规则草稿，因为这些草稿在这两个版本之间不兼容

解决办法：无。

问题 1628679：使用基于身份标识的防火墙时，已移除用户的虚拟机会继续保持在安全组中

将用户从 AD 服务器上的组中移除后，该用户登录的虚拟机继续保持在这个安全组中。这会在管理程序上保留虚拟机虚拟网卡的防火墙策略，因此，会授予用户对服务的完全访问权限。

解决办法：无。这是设计的预期行为。

问题 1462027：在跨 vCenter NSX 部署中，已保存防火墙配置的多个版本被复制到辅助 NSX Manager
通用同步将在辅助 NSX Manager 上保存通用配置的多个副本。已保存配置的列表包含在 NSX Manager 之间进行同步而创建的多个草稿，这些草稿具有相同名称且在同一时间创建或时间相差 1 秒。

解决办法：运行 API 调用删除重复的草稿。

DELETE : https://<nsxmgr-ip>/api/4.0/firewall/config/drafts/

查看所有草稿，找到要删除的草稿：

GET: https://<nsxmgr-ip>/api/4.0/firewall/config/drafts

在以下示例输出中，草稿 143 和 144 的名称和创建时间均相同，因此这两个草稿是重复的。同样，草稿 127 和 128 的名称相同且创建时间相差 1 秒，因此也是重复的。

<firewallDrafts> <firewallDraft id="144" name="AutoSaved_Wednesday, August 5, 2015 11:08:40 PM GMT" timestamp="1438816120917"> <description>Auto saved configuration</description> <preserve>false</preserve> <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user> <mode>autosaved</mode> </firewallDraft> <firewallDraft id="143" name="AutoSaved_Wednesday, August 5, 2015 11:08:40 PM GMT" timestamp="1438816120713"> <description>Auto saved configuration</description> <preserve>false</preserve> <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user> <mode>autosaved</mode> </firewallDraft> <firewallDraft id="128" name="AutoSaved_Wednesday, August 5, 2015 9:08:02 PM GMT" timestamp="1438808882608"> <description>Auto saved configuration</description> <preserve>false</preserve> <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user> <mode>autosaved</mode> </firewallDraft> <firewallDraft id="127" name="AutoSaved_Wednesday, August 5, 2015 9:08:01 PM GMT" timestamp="1438808881750"> <description>Auto saved configuration</description> <preserve>false</preserve> <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user> <mode>autosaved</mode> </firewallDraft> </firewallDrafts>

问题 1449611：当服务编排中的防火墙策略因删除了安全组而不同步时，无法在 UI 中修复该防火墙规则

解决办法：在 UI 中，您可以删除无效的防火墙规则，然后重新添加。或者，在 API 中，您可以通过删除无效的安全组来修复防火墙规则。然后同步防火墙配置：选择服务编排 >安全策略，然后对具有关联防火墙规则的每个安全策略，单击操作并选择同步防火墙配置。为防止出现此问题，请修改防火墙规则，以便在删除安全组之前防火墙规则不会引用安全组。

问题 1557880：如果规则中使用的虚拟机 MAC 地址被修改，第 2 层 (L2) 规则可能会缺失
由于 L2 规则优化在默认情况下处于启用状态，因此只有在 vNIC MAC 地址与源或目标 MAC 地址列表相匹配的情况下，同时指定了“源”和“目标”字段（非“任意”）的 L2 规则才会应用于 vNIC（或筛选器）。如果虚拟机与源或目标 MAC 地址不匹配，主机将不会应用这些 L2 规则。

解决办法：要让 L2 规则应用于所有 vNIC（或筛选器），请将“源”或“目标”字段中的一个设置为“任意”。

问题 1496273：UI 允许创建无法应用到 Edge 的入站/出站 NSX 防火墙规则
当 NSX 防火墙规则包含按“入站”或“出站”方向传输的流量并且数据包类型为 IPV4 或 IPV6 时，Web Client 错误地允许创建该规则并将其应用到一个或多个 NSX Edge。UI 不应允许创建此类规则，因为 NSX 无法将其应用到 NSX Edge。

解决办法：无。

问题 1557924：在本地 DFW 规则的“应用对象”字段中允许使用通用逻辑交换机
当通用逻辑交换机用作安全组成员时，DFW 规则可在“应用对象”字段中使用该安全组。这会间接在通用逻辑交换机上应用该规则，而此操作应该是禁止的，因为它可能会导致这些规则出现未知的行为。

解决办法：无。

问题 1559971：如果一个群集上的防火墙被禁用，不发布跨 vCenter NSX 防火墙排除列表
在跨 vCenter NSX 中，当一个群集上的防火墙被禁用时，不会向任何群集发布防火墙排除列表。

解决办法：强制同步受影响的 NSX Edge。

问题 1407920：使用 DELETE API 后，重新发布防火墙规则失败
如果您通过 DELETE API 方法删除整个防火墙配置，然后尝试从以前保存的防火墙规则草稿重新发布所有规则，则规则发布操作将失败。

问题 1494718：无法创建新的通用规则，且无法从流量监控 UI 编辑现有通用规则

解决办法：无法通过流量监控 UI 添加或编辑通用规则。EditRule 将自动禁用。

问题 1442379：服务编排防火墙配置不同步
在 NSX 服务编排中，任何防火墙策略无效时（例如，您删除了防火墙规则中当前使用的安全组），删除或修改其他防火墙策略都会导致服务编排不同步，并显示错误消息：防火墙配置不同步 (Firewall configuration is not in sync)。

解决办法：删除任何无效的防火墙规则，然后同步防火墙配置。选择服务编排 >安全策略，然后对具有关联防火墙规则的每个安全策略，单击操作并选择同步防火墙配置。为防止出现此问题，请始终修复或删除无效的防火墙配置，然后再进一步更改防火墙配置。

问题 1066277：安全策略名称不允许超过 229 个字符
服务编排的“安全策略”选项卡中的安全策略名称字段最多允许 229 个字符。这是因为策略名称在内部预置了前缀。

解决办法：无。

问题 1443344：第三方网络虚拟机系列的某些版本无法使用 NSX Manager 默认设置
默认情况下，某些 NSX 6.1.4 或更高版本的组件会禁用 SSLv3。升级前，请确保所有与 NSX 部署集成的第三方解决方案均不依赖于 SSLv3 通信。例如，Palo Alto Networks 虚拟机系列解决方案的某些版本需要 SSLv3 支持，所以请向您的供应商确认其版本要求。

问题 1660718：服务编排策略状态在 UI 中显示为“正在进行中”，在 API 输出中显示为“挂起”

解决办法：无。

问题 1620491：服务编排中策略级别的同步状态不显示策略中规则的发布状态

创建或修改策略后，服务编排将显示成功状态，该状态仅表示持久性状态，而不反映是否已将规则成功发布到主机。

解决办法：使用防火墙 UI 查看发布状态。

问题 1317814：如果在一个 Service Manager 关闭的情况下进行策略更改，服务编排将不同步
如果在多个 Service Manager 中有一个关闭的情况下进行策略更改，则更改将失败，并且服务编排将不同步。

解决办法：确保 Service Manager 有响应，然后从服务编排执行强制同步。

问题 1070905：无法从受 Guest Introspection 和第三方安全解决方案保护的群集中移除主机并重新添加
如果通过断开主机连接然后将其从 vCenter Server 中移除，从受 Guest Introspection 和第三方安全解决方案保护的群集中移除主机，则在将同一主机重新添加到同一群集时可能会遇到一些问题。

解决办法：要从受保护的群集中移除主机，请先将该主机置于维护模式。接下来，将该主机移动到不受保护的群集中或置于所有群集之外，然后断开连接并移除该主机。

问题 1648578：在创建基于 NetX 主机的新服务实例时，NSX 强制添加群集/网络/存储
从 vSphere Web Client 中为基于 NetX 主机的服务（例如，防火墙、IDS 和 IPS）创建新的服务实例时，将强制添加群集/网络/存储，即使不需要使用这些群集/网络/存储也是如此。

解决办法：在创建新的服务实例时，您可以为群集/网络/存储添加任何信息以填写这些字段。这样，就可以创建服务实例了，并且您可以根据需要继续操作。

问题 1772504：服务编排不支持具有 MAC 集的安全组
服务编排允许在策略配置中使用安全组。如果具有的安全组包含 MAC 集，服务编排将直接接受该安全组，但无法为该特定 MAC 集强制实施规则。这是因为服务编排在第 3 层上工作，而不支持第 2 层结构。请注意，如果安全组同时具有 IP 集和 MAC 集，则 IP 集将仍然有效，但会忽略 MAC 集。引用包含 MAC 集的安全组没有什么坏处，但用户必须知道 MAC 集会被忽略。

解决办法：如果用户打算使用 MAC 集创建防火墙规则，用户应使用 DFW 第 2 层/以太网配置，而不是服务编排。

问题 1718726：用户使用 DFW REST API 手动删除服务编排的策略部分后，无法强制同步服务编排

在跨 vCenter NSX 环境中，如果只有一个策略部分，而该策略部分（服务编排管理的策略部分）之前已通过调用 REST API 删除，则用户尝试强制同步 NSX 服务编排配置将会失败。

解决办法：请勿通过调用 REST API 来删除服务编排管理的策略部分。（请注意，UI 已经阻止删除这部分。）

监控服务已知问题

问题 1466790：无法使用 NSX 跟踪流工具选择桥接网络上的虚拟机
无法使用 NSX 跟踪流工具选择未连接到逻辑交换机的虚拟机。这意味着无法按虚拟机名称选择 L2 桥接网络上的虚拟机来作为跟踪流检测的源或目标地址。

解决办法：对于连接到 L2 桥接网络的虚拟机，请使用要作为跟踪流检测目标的接口的 IP 地址或 MAC 地址。您无法选择将连接到 L2 桥接网络的虚拟机作为源。有关详细信息，请参见知识库文章 2129191。

问题 1626233：在 NetX 服务虚拟机 (SVM) 丢弃数据包时，跟踪流不生成已丢弃观察数

在将数据包发送到 NetX 服务虚拟机 (SVM) 后，跟踪流会话将退出。在 SVM 丢弃数据包时，跟踪流不会生成已丢弃观察数。

解决办法：没有解决办法。如果未注回跟踪流数据包，则可以认为 SVM 已丢弃数据包。

解决方案互操作性已知问题

问题 1568861：从没有 vCenter 侦听器的 vCloud Director 单元部署任何 Edge 期间，NSX Edge 部署会失败

从没有 vCenter 侦听器的 vCloud Director 单元部署任何 Edge 期间，NSX Edge 部署会失败。还有，从 vCloud Director 进行的 NSX Edge 操作（包括重新部署）会失败。

解决办法：从拥有 vCenter 侦听器的 vCloud Director 单元中部署 NSX Edge。

NSX Controller 已知问题

问题 1765354：<deployType> 是必需属性，但并未使用该属性
<deployType> 是必需属性，但并未使用该属性，而且该属性也没有任何意义。

问题 1516207：在 NSX Controller 群集中重新启用 IPsec 通信后，控制器可能会被隔离
如果 NSX Controller 群集设置为允许控制器之间以明文形式进行通信（禁用 IPsec），并在稍后重新启用基于 IPsec 的通信，则一个或多个控制器可能会由于预共享密钥 (PSK) 不匹配而导致与群集主体隔离。出现此情况时，NSX API 可能无法更改控制器的 IPSec 设置。

解决办法：

按照以下步骤进行操作以解决此问题：

1. 使用 NSX API 禁用 IPSec。

   PUT /2.0/vdn/controller/node

   <controllerNodeConfig><ipSecEnabled>false</ipSecEnabled>
   </controllerNodeConfig>

2. 使用 NSX API 重新启用 IPSec。

   PUT /2.0/vdn/controller/node

   <controllerNodeConfig><ipSecEnabled>true</ipSecEnabled>
   </controllerNodeConfig>

按照以下最佳做法进行操作可避免此问题：

• 始终使用 NSX API 来禁用 IPSec。不支持使用 NSX Controller CLI 来禁用 IPSec。
• 在使用此 API 来更改 IPSec 设置之前，始终确认所有控制器都处于活动状态。

问题 1306408：必须按顺序下载 NSX Controller 日志
不能同时下载多个 NSX Controller 日志。即使从多个控制器下载，您也必须等待从当前控制器下载完成后，再开始从下一个控制器下载。另请注意，开始日志下载后便无法取消。

解决办法：等待当前控制器日志下载完成，然后再开始其他日志下载。

已解决的问题

新增：NSX 6.3.0 中解决的问题

NSX 6.3.0 中解决的问题分为以下几类：

• NSX 6.3.0 中解决的一般问题
• NSX 6.3.0 中解决的安装和升级问题
• NSX 6.3.0 中解决的 NSX Manager 问题
• NSX 6.3.0 中解决的网络和 Edge 服务问题
• NSX 6.3.0 中解决的安全服务问题
• NSX 6.3.0 中解决的解决方案互操作性问题

NSX 6.3.0 中解决的一般问题

已修复问题 1497389：具有 NSX 管理员特权的用户可以将他们的特权更改为企业管理员（一种更高级别的用户角色）。从 NSX 6.3.0 开始，具有 NSX 管理员特权的用户无法管理用户，只有具备企业管理员特权的用户才能管理用户。6.3.0 中已修复此问题。

已修复问题 1575342 和 1719402：在 NSX for vSphere 6.x 环境中，在使用 vMotion/SvMotion 迁移服务虚拟机 (SVM) 时，服务可能会中断，或者 ESXi 主机可能会崩溃
从 6.3.0 开始，您无法使用 vMotion/SvMotion 迁移服务虚拟机 (SVM)。SVM 必须位于所部署的主机上才能正常运行。
以前，允许迁移到其他主机，但不支持这种迁移，因此导致服务中断以及主机出现问题。
有关详细信息，请参阅 VMware 知识库文章 2141410。6.3.0 中已修复此问题。

已修复问题 1708769：在 NSX 中运行 SVM（服务虚拟机）快照后，SVM 延迟增加
出现该问题的原因是，运行服务虚拟机 (SVM) 快照可能导致网络延迟增加。快照有时会被环境中运行的备份应用程序调用。6.3.0 中已修复此问题。

已修复问题 1760102：在删除 NSX Controller 并重新部署以从存储故障中恢复后，虚拟机可能无法通信
出现存储故障时，适用于 vSphere 的 NSX Controller 6.2.4/6.2.5 环境可能会进入只读模式，如果先删除再重新部署控制器以从该状态中恢复，则某些虚拟机可能无法通信。控制器上出现存储故障时，预期行为是重新引导控制器应会将其从只读模式中恢复，但当前在 NSX 中并未实现此预期行为。6.3.0 中已修复此问题。

已修复问题 1662842：Guest Introspection：尝试解析不可解析的 Windows SID 时，MUX 和 USVM 之间的连接丢失
随着每个 Guest Introspection 进入和退出警告状态，Guest Introspection 服务将进入警告状态。在 Guest Introspection 虚拟机重新连接之前，网络事件将不会被递送到 NSX Manager。当通过 Guest Introspection 路径检测到登录事件时，这会同时影响活动监控和 ID 防火墙。6.3.0 中已修复此问题。

已修复问题 1752051：当 NSX Manager 与 USVM 的通信超时时，Guest Introspection 的服务状态报告为“未就绪”

当通过 NSX Manager 在内部消息总线 (rabbit MQ) 上执行预期的密码更改流程失败时，系统可能会对 Guest Introspection 通用 SVM 报告类似以下内容的错误消息：“拒绝明文登录: 用户‘usvm-admin-host-14’- 无效的凭据”(PLAIN login refused: user 'usvm-admin-host-14' - invalid credentials)。6.3.0 中已修复此问题。

已修复问题 1716328：移除处于维护模式的主机可能会导致之后的群集准备失败。

如果管理员将启用了 NSX 的 ESXi 主机置于维护模式，然后将该主机从准备好 NSX 的群集中移除，NSX 将无法删除所移除主机的 ID 号记录。安装处于此状态中后，如果另一个群集中还有另一个使用相同 ID 的主机，或者如果该主机将被添加到另一个群集，则该群集的准备过程将失败。6.3.0 中已修复此问题。

已修复问题 1710624：如果未在 REST API 请求正文中指定 serverType，则将添加的 Windows 2008 事件日志服务器的“TYPE”设置为“WIN2K3”类型

如果您创建事件日志服务器 API 请求，则将添加的服务器的“TYPE”设置为“WIN2K3”。如果您只对 IDFW 使用事件日志服务器，IDFW 可能无法正常工作。6.3.0 中已修复此问题。

NSX 6.3.0 中解决的安装和升级问题

已修复问题 1463767：在跨 vCenter 部署中，通用防火墙配置区域可能位于本地配置区域下（从属于本地配置区域）
如果将辅助 NSX Manager 置于独立（过渡）状态，然后将其更改回辅助状态，则会在复制的继承自主 NSX Manager 的通用配置区域上方列出临时处于独立状态时所做的任何本地配置更改。这会产生错误状况：辅助 NSX Manager 上的通用区域必须在所有其他区域上面 (universal section has to be on top of all other sections on secondary NSX Managers)。
6.3.0 中已修复此问题。

已修复问题 1402307：如果 vCenter 在 NSX for vSphere 升级过程中重新引导，将显示错误的群集状态
对于具有多个准备好 NSX 部署的群集，如果在升级过程中进行主机准备，并且 vCenter Server 在至少准备了一个群集后重新引导，其他群集的“群集状态”可能会显示为“未就绪”，而不是“更新”链接。此外，vCenter 中的主机可能会显示“需要重新引导”。
6.3.0 中已修复此问题。

已修复问题 1495307：升级过程中，L2 和 L3 防火墙规则未发布到主机
将更改发布到分布式防火墙配置后，UI 和 API 中无限期保持正在进行中状态，且 L2 或 L3 规则的日志均未写入到 vsfwd.log 文件中。6.3.0 中已修复此问题。

已修复问题 1491820：升级到 NSX 6.2 后，NSX Manager 日志收集到 WARN messagingTaskExecutor-7 消息
从 NSX 6.1.x 升级到 NSX 6.2 后，NSX Manager 日志中充满类似以下内容的消息：WARN messagingTaskExecutor-7 ControllerInfoHandler:48 - host is unknown: host-15 return empty list.这对操作并无影响。6.3.0 中已修复此问题。

NSX 6.3.0 中解决的 NSX Manager 问题

已修复问题 1671067：同时安装了 ESXTOP 插件时，NSX 插件不会显示在 vCenter Web Client 中
在部署 NSX 并在 vCenter 中成功注册之后，NSX 插件不会显示在 vCenter Web Client 中。此问题是由于 NSX 插件和 ESXTOP 插件之间存在冲突所导致。6.3.0 中已修复此问题。

NSX 6.3.0 中解决的网络和 Edge 服务问题

已修复问题 1740231：无法在 HA 接口上添加 IP 地址
从 6.3.0 开始，可以在 DLR HA 接口上添加 IP 地址。此功能在某些较早的 NSX 版本中不可用，但是，为了符合 DLR HA 管理接口的 API 行为重新引入了此功能。6.3.0 中已修复此问题

已修复问题 1716333：在启用或禁用 Edge HA 的同时更改 Edge 虚拟机大小或放置参数，可能创建额外的 Edge 虚拟机
同步进行更改 Edge 虚拟机大小或放置参数（如数据存储或资源池）和启用或禁用 Edge HA 操作，可能会损坏 NSX 受管对象数据库，从而遗留不可使用的 Edge 虚拟机。此外，在具有跨 vCenter 的环境中，遗留的 Edge 虚拟机将被复制到辅助站点。6.3.0 中已修复此问题。

已修复问题 1717369：在 HA 模式下进行配置时，可能会在同一主机上部署活动和备用 Edge 虚拟机
出现此问题是因为，在重新部署和升级操作期间，未在 vSphere 主机上自动创建并应用反关联性规则。在现有 Edge 上启用 HA 后，将不会出现此问题。

6.3.0 中已修复此问题。以下为预期行为：

• 启用 vSphere HA 后，将在重新部署和升级期间为 HA 对的 Edge 虚拟机创建反关联性规则。
• 禁用 vSphere HA 后，将不会为 HA 对的 Edge 虚拟机创建反关联性规则。

已修复问题 1675659：优先使用浮动静态路由而不是 OSPF 动态路由
如果启用了路由重新分发，则在 Edge 的路由表中错误地输入备用浮动静态路由，即使 OSPF 路由可用也是如此。6.3.0 中已修复此问题。

已修复问题 1733165：IPsec 可能会导致从 NSX Edge 转发表中移除动态路由
如果使用可通过动态路由访问的子网作为 IPsec 配置的远程子网，则 NSX Edge 会从转发表中移除该子网，并且即使在从 IPsec 配置中删除该子网后，也不会重新安装该子网。6.3.0 中已修复此问题。

已修复问题 1663902：重命名 NSX Edge 虚拟机会中断流经 Edge 的流量
重命名 NSX Edge 虚拟机将中断流经 Edge 的流量。6.3.0 中已修复此问题。

已修复问题 1624663：单击“配置高级调试”后，系统会刷新 vCenter UI，但更改未保留
在单击特定的 Edge ID >“配置”>“操作”>“配置高级调试”后，将导致刷新 vCenter UI，但不会保留更改。6.3.0 中已修复此问题。

已修复问题 1706429：初次部署逻辑（分布式）路由器后，在启用高可用性 (HA) 时出现的通信问题可能会导致两个逻辑路由器设备均处于活动状态。
如果在不启用 HA 的情况下部署一个逻辑路由器，然后再启用 HA（部署一个新的逻辑路由器设备），或者，如果先禁用 HA，然后再重新启用 HA，有时其中一个逻辑路由器设备会缺失到 HA 接口的连接路由。这会导致两个设备都处于活动状态。6.3.0 中已修复此问题。

已修复问题 1542416：使用子接口进行 Edge 重新部署和 HA 故障切换后，数据路径会有 5 分钟时间无法工作
如果使用子接口，执行重新部署或 HA 故障切换操作后，将出现五分钟的故障时间。接口中未发现问题。6.3.0 中已修复此问题。

已修复问题 1492547：关闭或重新引导具有最高 IP 地址的基于 NSX 的 OSPF 区域边界路由器后，聚合时间延长
如果关闭或重新引导 IP 地址并非最高的 NSSA 区域边界路由器，流量会快速聚合到其他路径。如果关闭或重新引导具有最高 IP 地址的 NSSA 区域边界路由器，重新聚合需要花费数分钟时间。可以手动清除 OSPF 进程以缩短聚合时间。6.3.0 中已修复此问题。

已修复问题 1510724：创建新通用分布式逻辑路由器 (UDLR) 后，不在主机上填充默认路由
将 NSX Manager 从“独立”模式更改为“主”模式以在 NSX for vSphere 6.2.x 中进行跨 vCenter 配置后，您可能会遇到以下症状：

• 创建新 UDLR 时，不在主机实例上填充默认路由。
• 在 UDLR 控制虚拟机上填充路由，而不在主机实例上填充。
• 运行 show logical-router host host-ID dlr Edge-ID route 命令时，未能显示默认路由。

6.3.0 中已修复此问题。

已修复问题 1704540：通过 NSX L2 网桥和 LACP 进行大量 MAC 校准表更新可能会导致内存不足
当 NSX L2 网桥发现其他上行链路上的 MAC 地址时，它会通过 netcpa 进程向控制器报告 MAC 校准表变更。使用 LACP 的网络连接环境将校准多个接口上的相同 MAC 地址，从而导致校准表更新量非常大，并且可能会耗尽 netcpa 进程所需的内存来进行报告。请参阅 VMware 知识库文章 2147181。6.3.0 中已修复此问题。

已修复问题 1716545：更改 Edge 的设备大小不更改备用 Edge 的 CPU 和内存预留
只有作为 HA 对的一部分创建的第一个 Edge 虚拟机才分配有预留设置。

已修复问题 1772004：从节点 0 到节点 1 的 Edge HA 故障切换所用的时间比预期长
在配置了 Edge HA 的环境中，从节点 0 到节点 1 的故障切换所用的时间比预期长，而从节点 1 到节点 0 的流量故障切换则是正常的。6.3.0 中已修复此问题。

已修复问题 1726379：如果 IP 多播范围的上限值在最后三个八位字节中超过 99，VXLAN 中继端口组配置将失败。
在配置分段 ID 时，如果创建的多播 IP 范围的上限值在最后三个八位字节中超过 99（如 1.100.100.100），并且创建具有相同多播 IP 范围的多播或混合逻辑交换机，VXLAN 中继端口组配置将失败。6.3.0 中已修复此问题。

NSX 6.3.0 中解决的安全服务问题

已修复问题 1767402：无法将“应用对象”设置为“安全组”的 DFW 规则发布到主机
如果 DFW 规则的“应用对象”字段设置为“安全组”，则无法将该规则推送到新群集中的 ESXi 主机。6.3.0 中已修复此问题。

已修复问题 1743366：默认禁用 NSX 阈值监控以避免潜在的崩溃
在防火墙模块运行时，NSX 会禁用内存阈值监控以避免发生潜在的崩溃。当主机运行 ESX 6.5P01 或者 ESX 6.0U3 或更高版本时，内存阈值监控将会自动启用。6.3.0 中已修复此问题。

已修复问题 1491046：不会自动批准 IPv4 IP 地址
在 VMware NSX for vSphere 6.2.x 中将 SpoofGuard 策略设置为“首次使用时信任”(TOFU) 时，不会自动批准 IPv4 IP 地址。6.3.0 中已修复此问题。

已修复问题 1686036：删除默认部分后，无法添加、编辑或移除防火墙规则
如果删除了默认的第 2 层或第 3 层部分，发布防火墙规则可能会失败。6.3.0 中已修复此问题。

已修复问题 1717994：分布式防火墙 (DFW) 状态 API 查询间歇性报告“500 内部服务器错误”
如果在向准备好主机的群集中添加新主机时发出 DFW 状态 API 查询，有些 API 查询尝试会失败，并显示“500 内部服务器错误”，然后在主机开始安装 VIB 后返回正确的响应。6.3.0 中已修复此问题。

已修复问题 1717635：如果环境中存在多个群集，并且同时进行更改，则防火墙配置操作会失败
在具有多个群集的环境中，如果两个或更多用户接连不断地修改防火墙配置（例如，添加/删除区域或规则），有些操作会失败，并且用户将看到类似以下内容的 API 响应：org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update; nested exception is javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update
6.3.0 中已修复此问题。

已修复问题 1707931：在服务编排中定义了服务策略时，如果在防火墙 UI 中应用筛选器来修改或发布防火墙规则，分布式防火墙规则的顺序会发生更改
从“网络和安全”>“防火墙”UI 中执行一个或多个发布操作后，如果更改在服务编排中创建的服务策略的顺序或者添加或删除服务策略，将导致防火墙规则顺序发生变化，并且可能会造成意想不到的后果。6.3.0 中已修复此问题。

已修复问题 1682552：不报告分布式防火墙 (DFW) 的 CPU/内存/CPS 的阈值事件
即使设置为报告 CPU/内存/CPS 的 DFW 阈值，超过阈值时也不会报告阈值事件。6.3.0 中已修复此问题。

已修复问题 1620460：NSX 无法阻止用户在服务编排规则区域创建规则
在 vSphere Web Client 中，“网络和安全: 防火墙”界面无法阻止用户向服务编排规则区域添加规则。应允许用户在服务编排区域的上方/下方添加规则，但不应允许在此区域内部添加规则。6.3.0 中已修复此问题。

已修复问题 1445897：在 VMware NSX for vSphere 6.1.x 和 6.2.x 中删除引用的对象后，发布分布式防火墙 (DFW) 规则失败 6.2.3 中已修复此问题。

已修复问题 1704661 和 1739613：虚拟机断开网络连接并显示以下错误：“无法恢复 PF 状态: 超出限制”(Failed to restore PF state: Limit exceeded)
虚拟机断开网络连接并显示以下错误：“无法恢复 PF 状态: 超出限制。”(Failed to restore PF state: Limit exceeded.)6.3.0 中已修复此问题。

NSX 6.3.0 中解决的解决方案互操作性问题

已修复问题 1527402：具有 NSX 网络自检驱动程序的 Windows 虚拟机断开 TCP 连接
在 VMware NSX for vSphere 6.x 环境中，连接到 USVM (Guest Introspection SVM) 并具有 NSX 网络自检驱动程序 (vnetflt.sys) 的 Windows 虚拟机断开临时 TCP 网络连接。6.3.0 中已修复此问题。

已修复问题 1530360：NSX Manager 虚拟机进行故障切换后，Site Recovery Manager (SRM) 错误地报告超时错误
在 NSX Manager 虚拟机进行故障切换后，在等待 VMware Tools 时，SRM 错误地报告超时错误。在这种情况下，VMware Tools 实际已在 300 秒超时内启动并运行。6.3.0 中已修复此问题。

文档修订历史

2017 年 2 月 2 日：NSX 6.3.0 第一版。
2017 年 2 月 3 日：NSX 6.3.0 第二版。添加了已知问题 1799543
2017 年 2 月 22 日：NSX 6.3.0 第三版。已更新 CDO 信息
2017 年 2 月 27 日：NSX 6.3.0 第四版。添加了已知问题 1808478 和 1818257
2017 年 3 月 30 日：NSX 6.3.0 第五版。添加了已知问题 1474650 和 1782321。
2017 年 4 月 10 日：NSX 6.3.0 第六版。在“升级说明”部分中添加了一些信息。
2017 年 5 月 3 日：NSX 6.3.0 第七版。添加了有关弃用 vCNS Edge 和 VIX 的信息。
2017 年 6 月 2 日：NSX 6.3.0 第八版。添加了已知问题 1860583、1781438 和 1825416。
2017 年 6 月 22 日：NSX 6.3.0 第九版。添加了已知问题 1847753。
2017 年 8 月 21 日：NSX 6.3.0 第十版。添加了已修复的问题 1463767 并删除了以前的几个问题。
2017 年 10 月 2 日：NSX 6.3.0 第十一版。更新了建议的最低版本。