VMware NSX-T 2.1.0.1   |   2018 年 2 月 8 日   |   組建編號 7725122

VMware NSX-T 2.1   |   2017 年 12 月 21 日   |   組建編號 7395507

請定期查看這些版本說明的增補和更新。

版本說明的內容

此版本說明涵蓋下列主題:

新增功能

新增功能
NSX-T 2.1 是累加式升級版本,可增強針對雲端和容器提供的全新多 Hypervisor 平台。
 
NSX-T 2.1.0.1 是維護版本,專門用於 NSX Container Plug-in (NCP) 功能。具有下列改善功能:
  • 支援在設定入口 URI 路徑以進行負載平衡時使用萬用字元。
  • 支援在 Kubernetes 環境中使用完整標籤。NCP 將標準化完整標籤,以納入 NSX 標記。
  • 支援在 Kubernetes 環境中使用完整名稱。NCP 可處理超過 NSX 標記名稱長度上限 (40 個字元) 的資源名稱。
  • 在 Pivotal Cloud Foundry 環境中,NCP 可處理在多個 diego 儲存格中建立的應用程式執行個體。
NSX-T 2.1 版本中提供了下列新功能和增強功能。
                                                           
                                                                                                                         新的 NSX-T 功能
負載平衡器
適用於工作負載的內嵌和單一裝載負載平衡器拓撲支援。OpenStack 部署中的 NSX-T 負載平衡器支援和 Kubernetes 容器部署中的入口。
 
Pivotal Application Service 整合 (PAS/PCF)
NSX-T 2.1 與 Pivotal Application Service 2.0 整合 (CNI 整合)。
 
Pivotal Container Service
Pivotal Container Service 的網路和安全性功能支援。
 
原則管理員
原則管理員支援允許基於意圖的防火牆原則。
 
                                                                                                                                 NSX-T 增強功能
 
分散式防火牆
分散式防火牆現在支援規則叫用總計數。
 
可用性工作流程
增強型 NSX-T 儀表板、入門工作流程和強大的搜尋與篩選功能。
 
NSX Edge 節點部署
更新的 NSX Edge 節點部署。

相容性和系統需求

如需相容性和系統需求資訊,請參閱 NSX-T 安裝指南

API 參考資訊

最新的 API 參考位於〈NSX-T 產品資訊〉內。請使用最新的 API 參考,而不要使用 NSX Manager 使用者介面中提供的版本。

已過時的 API 呼叫和內容

以下是已過時的 API 呼叫和內容。這些項目在 API 參考中標示為「已過時」。您仍可加以斟酌使用,但請注意,這些項目將在未來的版本中從 NSX-T 中移除。

已過時的 API 呼叫

  • GetLogicalRouterRouteTableInCsvFormat (/logical-routers/<logical-router-id>/routing/route-table?format=csv) 針對 RIB 使用 /logical-routers/<logical-router-id>/routing/routing-table,針對 FIB 則使用 /logical-routers/<logical-router-id>/routing/forwarding-table。針對具有指定傳輸節點識別碼的節點上的邏輯路由器,傳回 CSV 格式的路由資料表。查詢參數 "transport_node_id =<transport-node-id>" 為必要項。不支援查詢參數 "source=cached"。
  • UpdateServiceProfile (/service-profiles/<service-profile-id>) 會修改指定的服務設定檔。PUT 要求必須包含 resource_type 參數。可修改參數包括說明和 display_name。其他參數可能可修改,視指定的服務類型而定。
  • DeleteService (/services/<service-id>) 會刪除指定的邏輯路由器服務。
  • ListServices (/services) 會傳回所有已設定的邏輯路由器服務的相關資訊,這些服務可套用到一或多個邏輯路由器連接埠。您必須先建立服務設定檔,才能建立服務。目前僅支援 DhcpRelayService。
  • DeleteServiceProfile (/service-profiles/<service-profile-id>) 會刪除指定的服務設定檔。
  • ListServiceProfiles (/service-profiles) 會傳回所有服務設定檔的相關資訊。服務設定檔是您可用於建立服務,然後將服務套用到一或多個邏輯路由器連接埠的組態。目前僅支援 DhcpRelayProfile。
  • CreateServiceProfile (/service-profiles) 會建立服務設定檔,隨後可使用該設定檔建立服務。然後,會將服務套用到一或多個邏輯路由器連接埠。
  • DeleteLicense (/licenses/<license-key>) 改為使用 POST /licenses?action=delete API。
  • GetLicense (/license) 改為使用 GET /licenses API。
  • ReadServiceProfile (/service-profiles/<service-profile-id>) 會傳回指定服務設定檔的相關資訊。
  • UpdateLicense (/license) 改為使用 POST /licenses API
  • CreateService (/services) 會建立可套用到一或多個邏輯路由器連接埠的服務。對於某些服務類型,您必須先建立服務設定檔,才能建立服務。
  • UpdateService (/services/<service-id>) 會修改指定的邏輯路由器服務。resource_type 參數為必要項。可修改的參數取決於服務類型。
  • ReadService (/services/<service-id>) 會傳回指定服務的相關資訊。
  • GetLicenseByKey (/licenses/<license-key>) 改為使用 GET /licenses API。
  • GetLogicalRouterRouteTable (/logical-routers/<logical-router-id>/routing/route-table) 針對 RIB 使用 /logical-routers/<logical-router-id>/routing/routing-table,針對 FIB 則使用 /logical-routers/<logical-router-id>/routing/forwarding-table。針對具有指定傳輸節點識別碼的節點上的邏輯路由器,傳回路由資料表。查詢參數 "transport_node_id =<transport-node-id>" 為必要項。不支援查詢參數 "source=cached"。
  • PerformNodeAction (/fabric/nodes/<node-id>) 針對 EdgeNode 支援的網狀架構節點動作是 enter_maintenance_mode、exit_maintenance_mode。使用 TransportNode 維護模式 API 更新維護模式,請參閱「更新傳輸節點維護模式」。

 

已過時的類型定義

  • LogicalService
  • 邏輯服務的 LogicalServiceResourceTypes 資源類型。
  • NodeActionParameters 網狀架構節點動作參數。
  • 服務設定檔的 ServiceProfileResourceTypes 資源類型。

 

已過時的 API 內容定義

  • BgpNeighbor.filter_in_routemap_id 改為使用 'address_family'。
  • BgpNeighbor.remote_as 改為使用 'remote_as_num'。
  • BgpNeighbor.filter_out_ipprefixlist_id 改為使用 'address_family'。
  • BgpNeighbor.filter_out_routemap_id 改為使用 'address_family'。
  • BgpNeighbor.source_address 不提供此欄位的值。改為使用 source_addresses。
  • BgpNeighbor.filter_in_ipprefixlist_id 改為使用 'address_family'。
  • HostSwitch.static_ip_pool_id,已設定靜態 IP 集區的識別碼。如果已指定,則從集區中為端點配置 IP。否則,假設已從 DHCP 為端點指派 IP。此欄位已過時,改為使用 ip_assignment_spec 欄位。
  • AddControllerNodeSpec.control_plane_server_certificate 不提供此內容的值。
  • BgpConfig.as_number 改為使用 'as_num'。
  • TransportNode.host_switches 改為使用 'host_switch_spec'。內容 'host_switches' 只能用於 NSX-T 受管理傳輸節點。'host_switch_spec' 可用於 NSX-T 受管理或手動預先設定的主機交換器。

已解決的問題

已解決的問題分類如下。

一般已解決的問題
  • 問題 1901714:啟用 SpoofGuard 時會捨棄 IPv6 流量

    如果為邏輯連接埠開啟 Spoofguard,即使將全域範圍 IP 加入 [手動位址繫結] 白名單中,IPv6 封包仍有可能被捨棄。

    因應措施:啟用 Spoofguard 時,將全域範圍 IPv6 位址和連結本機 IPv6 位址加入 [手動位址繫結] 白名單中。

  • 問題 1948580:重新開機 RHEL 傳輸節點會遺失虛擬通道端點 DHCP IP 位址

    如果傳輸節點組態將 DHCP IP 用於虛擬通道端點,則傳輸節點重新開機不會取得 DHCP IP 位址。

    因應措施:傳輸節點完全開機後,將 dhclient 重新啟動至虛擬通道端點、介面,以提供 DHCP IP 位址給該介面。

  • 問題 1958277:應用裝置升級之後外部 Syslog 伺服器的 iptables 規則不會持續

    在管理平面、NSX Controller 和 NSX Edge 節點從 NSX-T 1.1 升級至 NSX-T 2.0 之後,設定外部 Syslog 伺服器時由 NSX-T CLI 或 API 自動新增的所有自訂 iptables 規則不會新增。因此,設定的 Syslog 匯出工具無法將記錄轉送至外部伺服器。此外,在 NSX Manager 中,如果外部 Syslog 伺服器是在 NSX-T 1.1 中設定,則捨棄的封包會記錄至 /var/log/iptables.log,從而導致升級之後 /var/log/iptables.log 檔案飽和。

    因應措施:應用裝置升級之後刪除外部 Syslog 伺服器,然後再次新增這些外部 Syslog 伺服器。

  • 問題 1958295:如果 Hypervisor 和金鑰管理員一併登錄,金鑰管理員登錄可能會失敗

    在 Hypervisor 和金鑰管理員一併或並行登錄的情況下,金鑰管理員登錄可能會失敗。

    因應措施:分別登錄 Hypervisor 和金鑰管理員。

  • 問題 1958302:在 ESX 6.5 上,且流量繁重的情況下,NSX-Exporter 會由於記憶體不足而失敗

    當 vNIC 上有每秒超過 200 個連線時,ESX vsip 核心會由於佇列已滿而捨棄流量記錄。這會導致 NSX-Exporter 錯過流量更新,而那些流量會累積在處理程序中直到重新啟動。這會導致記憶體不足的情況。

    因應措施:無。

    失敗之後,監視程式會重新啟動處理程序。在此類情況下,系統會關閉規則統計資料。

  • 問題 1905370:可透過 IP 探索發現的 IP 位址數量增加,且 SpoofGuard 連接埠白名單大小更大

    可以探索到的 IP 位址數量以及可以設定為自動填入之 SpoofGuard 連接埠白名單項目的大小已增加。SpoofGuard 連接埠白名單項目支援的最大數量為 128。這些項目可以使用 VMware Tools、DHCP、或 ARP 手動或動態學習。

    在下列案例中,您可以超過 128 個連接埠白名單項目。

    假設 A:對應於手動 PortWhitelist 項目。
    假設 B:對應於所有探索的項目 (DHCP、ARP 和 VMTOOLS)。
    假設 C:對應於透過 API 的 SwitchWhitelist。

    以下其中一個條件必須成立:

    A <= 128,其中 B = C = 0 (或)
    B <= 128,其中 A = C = 0 (或)
    C <= 128,其中 A = B = 0 (或)
    A + C <= 128 (手動繫結會覆寫探索的繫結,所以 B 中的 IP 數量不相關) (或)
    B + C <= 128,其中 A = 0

    因應措施:無。

  • 問題 1951653:/var/log 磁碟分割 80% 已佔用時,不會再將記錄檔寫入 /var/log 目錄

    /var/log 磁碟分割 80% 已佔用時,Cron 工作中的錯誤會修改 /var/log 目錄的群組擁有權,防止任何其他記錄檔寫入 /var/log 目錄。

    因應措施:安裝完成後,立即對所有 NSX Manager、NSX Controller 和 NSX Edge 執行下列步驟。

    1. 檢視 varlog_disk_space_monitor.py 檔案。
      cat /opt/vmware/bin/varlog_disk_space_monitor.py
    2. 找到 _MONITOR_LOG 並檢查其是否為 /var/log/disk_space_monitor.log。
    3. 執行此命令,awk '{if ($1=="_MONITOR_LOG") {print "_MONITOR_LOG = \"/var/log/nvpapi/disk_space_monitor.log\"";} else {print $0}}' /opt/vmware/bin/varlog_disk_space_monitor.py > /tmp/varlog_disk_space_monitor.py ; mv /tmp/varlog_disk_space_monitor.py /opt/vmware/bin/
    4. 檢視 varlog_disk_space_monitor.py 檔案。
      cat /opt/vmware/bin/varlog_disk_space_monitor.py
    5. 找到 _MONITOR_LOG,並確認記錄顯示 /var/log/nvpapi/disk_space_monitor.log。
    6. 檢查 /var/log 目錄的群組擁有權。
    7. 如果群組擁有權為 www-data,請將擁有權變更為 syslog。
      chown root:syslog /var/log
  • 問題 1917672:vIDM 登入頁面上的驗證嘗試失敗未記錄在 NSX-T syslog 中

    在 vIDM 登入頁面上嘗試以遠端使用者身分登入失敗以及帳戶鎖定未做為失敗事件項目傳送到 NSX-T syslog。

    因應措施:在 ./opt/vmware/horizon/workspace/logs/horizon.log 中檢視 vIDM 使用者失敗的驗證嘗試記錄。

安裝已解決的問題
  • 問題 1538016:在直接連線至 ESXi 時,vSphere Client 不支援設定 OVF 額外組態內容,例如 IP 位址
    如果您使用不具 vCenter 的 ESXi,且透過 vSphere Client 部署 NSX-T 應用裝置,則無法編輯 OVF 額外組態內容。

    因應措施:如果您需要在不具 vCenter 的 ESXi 上安裝 NSX Edge、NSX Manager 和 NSX Controller 應用裝置,請使用 ovftool 命令。如果只要安裝 NSX Edge,您可以透過 vSphere Client 來安裝、登入 CLI,並手動設定網路介面。

NSX Manager 已解決的問題
  • 問題 1762527:NSX Manager 在安全掃描期間可能會觸發快取毒害弱點警告
    NSX Manager 在安全掃描期間可能會觸發快取毒害弱點警告,因為 NSX Manager 會使用主機 HTTP 要求標頭建構重新導向回應。
    例如:
    GET /nsxapi/ping.json?_dc=1474040351698 HTTP/1.1
    Host: 10.32.41.238
    User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Cookie: JSESSIONID=DE5258CE9FAD8C160B2BC94E2A63EC0C
    Connection: keep-alive

    快取毒害的風險,可藉由不允許 HTTP 回應在中繼快取內持續保存來降低。

  • 問題 1742510:NSX Manager 資料庫可能因電源關閉事件而損毀
    有時候,NSX Manager 在電源關閉事件之後會無法啟動。即使在 5 分鐘之後,NSX Manager 狀態仍未報告為穩定
    nsxapi.log 檔案中會出現下列記錄訊息:[nsx comp="nsx-manager" errorCode="MP4113" subcomp="manager"] GemFire is in illegal state, restating Proton process com.vmware.nsx.management.container.dao.gemfire.GemFireInitializationException: java.lang.NullPointerException

    因應措施:還原最新的 NSX Manager 備份。

  • 問題 1955778:NSX Manager 上耗用大量記憶體

    整合式應用裝置的預設記憶體設定為中型、4vCPU 和 16 GB RAM。如果是 250 個 Hypervisor 規模的部署,則根據比例增加設定之後,管理平面在執行時會使用 90% 的 RAM。

    因應措施:一般建議針對大規模環境,為管理平面的整合式應用裝置指派較大的設定,即 8vCPU 和 32 GB RAM。

  • 問題 1958317:使用者介面中的 [使用者] 索引標籤不顯示本機使用者、管理員和稽核

    使用者介面中的 [使用者] 索引標籤不顯示本機使用者、管理員和稽核。

    因應措施:無。

  • 問題 1959887:使用 Internet Explorer 進行編輯時,不會儲存 vIDM 組態詳細資料

    在 NSX-T UI 中,當您使用 Internet Explorer 導覽至系統 > 使用者 > 組態檢視和編輯 vIDM 組態時,可能不會正確儲存所編輯的資料。

    因應措施:請使用其他網頁瀏覽器。

NSX Edge 已解決的問題
  • 問題 1747919:透過 Nexthop 建立為 VIP IP 的靜態路由,並未推送至 NSX Edge 節點
    當 VIP 子網路不同於上行介面子網路時,透過 Nexthop 建立為 VIP IP 的靜態路由未推送至 NSX Edge 節點。

    因應措施:對於使用 VIP 的靜態路由,請一律使用來自現有上行子網路 IP 之一的 VIP IP 位址。

  • 問題 1580586:重新分配規則在首碼清單中不支援 LE 或 GE 組態
    重新分配規則在首碼清單中不支援 LE 或 GE 組態、NSX Manager 未驗證此組態,且 NSX Edge 不支援此組態。因此,使用者可能會發現組態並未生效。

    因應措施:不要在 IP 首碼清單中使用 LE 或 GE 組態。

  • 問題 1604923:移除或變更由第 1 層邏輯路由器連結連接埠轉介的 NSX Edge 叢集成員索引,會中斷由北到南的流量

  • 問題 1941888:當 NSX Edge 運作時間超過五天時,NSX Edge 升級會失敗

    NSX Edge 會升級失敗,並顯示下列錯誤訊息:
    [Edge UCP]Edge 節點 <Edge 節點識別碼> 上的升級代理程式無法連線。請重新啟動升級代理程式服務並檢查網路連線。}, ]

    因應措施:手動重新啟動 NSX Edge 升級服務以繼續進行升級。在 NSX Edge 上,輸入 restart service nsx-upgrade-agent

  • 問題 1923325:在某些組態中,當 NSX Edge 節點在修復分裂的核心時,可能會發生流量中斷

    NSX-T 2.0 為 NSX Edge 節點上的第 1 層邏輯路由器引進了新的非先佔式容錯移轉模式。在已設定防火牆或 NAT 服務的非先佔模式中部署時,流量可能會在叢集分裂事件發生並修復之後發生中斷。如果有網路磁碟分割而且兩個邏輯路由器都成為使用中狀態,則會發生叢集分裂。

    因應措施:以先佔式模式設定第 1 層邏輯路由器可以避免流量中斷。

  • 問題 1955002:主機交換器名稱長度限制

    建立傳輸區域時,如果提供的主機交換器名稱長度超過 26 位元組,則作業會發生內部失敗。因此導致 UI 無法顯示特定邏輯路由器的傳輸節點清單。

    因應措施:將主機交換器名稱的長度限制在 26 位元組以下。請注意,每個非 ASCII 字元在 UTF-8 編碼下會佔用 2 到 4 個位元組的空間。如果使用由非 ASCII 字元組成的主機交換器名稱,則會進一步限制 26 位元組空間中可以容納的字元數。

邏輯網路已解決的問題
  • 問題 1763570:在以新的 IP 集區更新傳輸節點之後刪除舊 IP 集區的作業會失敗

    因應措施:刪除所有邏輯路由器的組態,並在所有傳輸節點上套用新的 IP 集區。

  • 問題 1773703:在 IP 首碼清單處於單一序列、且未提供 GE 和 LE 選項的情況下以 OUT 方向新增路由對應時,BGP 會停止通告所有 PERMIT IP 首碼
    當一個 IP 首碼設為 PERMIT,且另一個 IP 首碼設為 DENY 時,隨後若將路由對應中的 IP 首碼清單單一序列動作設為 PERMIT,且 BGP 芳鄰篩選器中的該路由對應採用 OUT 方向,則 BGP 會停止通告所有 PERMIT IP 首碼。

    因應措施:您可以執行下列其中一項工作:

    • 您可以在 BGP 芳鄰篩選器中使用 IP 首碼清單,而不使用路由對應。
    • 在路由對應中的 IP 首碼清單中新增其中一個 IP 首碼時,使用 GE 和 LE 選項。
    • 為每個 IP 首碼建立個別的 IP 首碼清單,並以個別的序列將其新增至路由對應中。

  • 問題 1769491:刪除在 BGP 芳鄰篩選器的 OUT 方向中新增的路由對應,會導致判斷提示錯誤並翻動 BGP 路由

    因應措施:不需要因應措施,因為 BGP 連線會在數秒後重新建立。

  • 問題 1736536:對 MDProxy 服務支援的邏輯交換器數目上限為 1024 個
    若為 MDProxy 服務設定超過 1024 個邏輯交換器,將不允許後端 MDProxy 服務啟動 nginx Web 伺服器。

    因應措施:您可以在支援 MDProxy 服務的所有 NSX Edge 上新增超過 1024 個邏輯交換器。

    1. 以根使用者權限導覽至 /etc/init.d/nsx-edge-mdproxy。
    2. 刪除 ulimit -n 1024 一行。
    3. 以根使用者權限導覽至 etc/init/nsx-edge-nsxa.conf。
    4. 新增 limit nofile 20000 20000 一行。
    5. 在管理主控台中重新啟動 MDProxy 服務。
      restart service local-controller

  • 問題 1721716:即使邏輯路由器連接埠上已設定現有的靜態路由,仍可刪除該連接埠
    當您刪除已設定靜態路由的邏輯路由器連接埠時,靜態路由仍會保留在系統中。

    因應措施:您可以手動刪除靜態路由,或在系統中保留這些不會造成任何損害的路由。

  • 問題 1754187:在多重傳輸區域環境中,從傳輸節點中移除一個傳輸區域後,已移除之傳輸區域中的虛擬機器仍可加入 NSX-T 網路

    因應措施:從傳輸節點中移除傳輸區域之前,請先從邏輯交換器中斷位於該傳輸區域之虛擬機器的連線。

  • 問題 1770041:在 BGP 對等之間,當路由對應設定為附加 ASN 時,待命無法立即加以附加
    在 2 位元組 BGP 對等之間,當路由對應設定為附加 4 位元組 ASN 時,待命需耗費 15 秒才能正確附加 4 位元組 ASN。
    在 4 位元組 BGP 對等之間,當路由對應設定為附加 2 位元組 ASN 時,待命需耗費 15 秒才能正確附加 2 位元組 ASN。

    因應措施:無。

  • 問題 1585874:IP 位址繫結必須透過連接埠 SpoofGuard 設定於邏輯交換器設定檔上
    如果在邏輯交換器設定檔上啟用了連接埠 SpoofGuard,則也必須在屬於邏輯交換器的虛擬機器連接埠上設定 IP 位址繫結。這對於連線至 vCenter 虛擬機器的連接埠而言尤其重要,因為若未設定繫結,虛擬機器連接埠上的流量可能會因為 SpoofGuard 的空白白名單組態而被吸走。

    因應措施:無。

  • 問題 1765476:重新開機之後,NS 群組與 NSX Controller 的同步化可能需要一些時間
    使用管理平面將節點重新開機後,NS 群組與 NSX Controller 的同步化可能需耗時大約 30 分鐘或更久,視 NS 群組的數目而定。

    因應措施:無。

  • 問題 1935535:如果將個別 Containerhost 虛擬機器新增為 NSGroup 的成員,容器邏輯連接埠不會列在 NSGroup 的「有效邏輯連接埠」成員中

    透過成員資格標準將 Containerhost 虛擬機器新增為 NSGroup 的成員時,Containerhost 虛擬機器上的邏輯連接埠會成為相同 NSGroup 的有效成員,但來自相同 Containerhost 虛擬機器之容器的容器邏輯連接埠不會成為 NSGroup 的有效成員。

    因應措施:使用「虛擬機器」以外的可用實體,將容器邏輯連接埠新增至 NSGroup。

  • 問題 1955845:保留相同的實體 NIC 時,編輯傳輸節點以變更傳輸區域會失敗

    使用新的傳輸區域編輯傳輸節點並保留相同的實體 NIC 之後,編輯作業顯示部分成功狀態,並顯示錯誤訊息:主機組態: 實體 NIC 正在使用中: [vmnic1]。可用於主機-交換器的實體 NIC [00 84 9b 21 55 c5 49 f0-a3 d7 76 dd a0 41 66 76]: vmnic2

    因應措施:刪除傳輸節點,並使用新的傳輸區域 NIC 重新建立該節點。
     

安全服務已解決的問題
  • 問題 1759369:NSX Controller 上偏弱的 TLS 組態,讓攻擊者得以讀取或修改 NSX Controller 與 Hypervisor 之間的往返 TLS 流量
    連接埠 1234 上的 TLS 接聽程式設定為支援 TLS 1.0,而此版本容易遭受外部攻擊。

    因應措施:實體保護 NSX Controller 與 Hypervisor 之間的網路。

  • 問題 1643872:將篩選器套用至防火牆規則後,您無法停用該規則
    在 NSX Manager 使用者介面中,如果您將篩選器套用至規則,使用者介面將不允許您加以停用。

    因應措施:移除篩選器並停用防火牆規則。

  • 問題 1721519:中繼資料 Proxy 伺服器與 Nova 伺服器之間的連線未加密或未經授權

    因應措施:無。

  • 問題 1590888:在 [乙太網路] 區段中選取的邏輯連接埠只會套用於相同的第 2 層網路內
    如果您以來源或目的地的邏輯連接埠或 MAC 位址建立了防火牆規則,且您在 [乙太網路] 區段中套用了分散式防火牆規則,則 MAC 位址或邏輯連接埠必須屬於同一個第 2 層網路中的虛擬機器連接埠。換句話說,兩者必須連結至相同的邏輯交換器。

作業和監控服務已解決的問題
  • 問題 1764175:連接埠連線和 Traceflow 工具需要很長的時間來探索虛擬機器
    當 NSX-T 部署開始具有少量的主機 (10 個或更少),隨後增長為大量主機,而 NSX Manager 自初始的少量主機以來並未重新啟動時,如果 NSX Manager 失去與大量主機的連線,它將需要花很長的時間與這些主機進行同步以及探索執行於這些主機的虛擬機器。記錄檔含有如下的訊息:Processing sync_init requests, batch size <calculated batch size>

    因應措施:將 NSX Manager 重新開機。

  • 問題 1743476:將非 NSX-T 管理之交換器上的虛擬機器移至受 NSX-T 管理的交換器時,可能會導致虛擬機器的防火牆停用
    在非 NSX-T 管理之交換器上,將透過 NSX-T 工作流程所部署的虛擬機器移動至受 NSX-T 管理的交換器時,可能會導致虛擬機器的防火牆停用。

    因應措施:關閉虛擬機器的電源,然後重新開啟。

  • 問題 1956097:發出 get logical-router 命令時,路由器名稱遭到截斷

    在 NSX Edge NSX CLI 上執行 get logical-router 命令時,可能會顯示截斷的路由器名稱,以符合內部強制執行的 16 位元組限制。這不會影響實際名稱,因為名稱會維持不受影響。不過,如果路由器名稱共用通用的前置詞,則可能很難加以區分。

    因應措施:依賴 UUID、VRF、LR-ID、類型之類的其他屬性來唯一識別路由器。對實際名稱沒有影響,您可以在 UI 和公開名稱的其他位置中找到的完整名稱。

KVM 網路已解決的問題
  • 問題 1587627:Ops/BFD API 可能會報告異常資訊
    作業資訊是從所有平台收集而得,而 ESXi、NSX Edge 或 KVM 平台上的 BFD/通道實作不一致。

    • NSX Edge 和 KVM 會永久保存 BFD/通道工作階段。
    • ESXi 會在不需要這些工作階段時加以終結,並在需要時建立。
    因此,可能會出現一端顯示通道已關閉、而另一端沒有該通道的異常 BFD 狀態。此外,BFD 對於偵錯並無幫助,因為當 BFD 工作階段刪除時,即失去最後一個失敗導因。

    因應措施:無

API 已解決的問題
  • 問題 1781233:API GET https://<NSX-Manager>/api/v1/fabric/nodes/status 會傳回錯誤
    API GET https://<NSX-Manager>/api/v1/fabric/nodes/status 會取得多個節點的狀態,而可能傳回錯誤。
    因應措施:使用 GET https://<NSX-Manager>/api/v1/fabric/nodes/<node-id>/status 取得個別節點的狀態。

  • 問題 1770207:發出 API 呼叫以變更驗證原則時,變更並未生效
    當您發出 API 呼叫 PUT https://<NSX-Manager>/api/v1/node/aaa/auth-policy 以變更下列任何原則時,變更並未生效。

    • api_failed_auth_lockout_period
    • api_failed_auth_reset_period
    • api_max_auth_failures
    • minimum_password_length

    因應措施:重新啟動 Proxy 服務。

文件勘誤已解決的問題
  • 問題 1622719:先從邏輯交換器中斷相關虛擬機器的連線,再進行特定的傳輸節點和傳輸區域變更
    在執行下列程序之前,請先從邏輯交換器中斷相關虛擬機器的連線。

    • 從傳輸節點中斷邏輯交換器的連線之前。
    • 將傳輸節點從一個傳輸區域移至另一個傳輸區域之前。
    • 刪除傳輸區域之前。

  • 問題 1537399:ESXi 和 KVM 上的 IPFIX 會以不同方式進行通道封包取樣
    在 ESXi 上,系統會將通道封包取樣為兩種記錄:
    具有某些內部封包資訊的外部封包記錄。

    • 參考外部封包的 SrcAddr、DstAddr、SrcPort、DstPort 和通訊協定。
    • 包含一些說明內部封包的企業項目。
    內部封包記錄。
    • 參考內部封包的 SrcAddr、DstAddr、SrcPort、DstPort 和通訊協定。
    在 KVM 上,通道封包會取樣為一筆記錄:
    具有某些外部通道資訊的內部封包記錄。
    • 參考內部封包的 SrcAddr、DstAddr、SrcPort、DstPort 和通訊協定
    • 包含一些說明外部封包的企業項目。

  • 問題 1520687:使用 IPFIX 時效能可能下降
    特定 IPFIX 組態可能會導致 ESXi 和 KVM Hypervisor 的效能下降。例如,為閒置逾時、流量逾時或最大流量設定偏低的值,同時又將取樣機率的值設得偏高,即可能導致效能下降。設定 IPFIX 組態時,請監控對 Hypervisor 效能的影響。

  • 問題 1622362:將 IP 位址範圍 100.64.0.0/10 用於外部傳送網路
    請不要在第 0 層邏輯路由器的上行介面上設定 IP 位址範圍 100.64.0.0/10。此 IP 位址範圍要用於 NSX Edge 上的外部傳送網路。如需詳細資訊,請參閱 RFC 6598。

  • 問題 1444337:支援服務包含有包括使用者名稱的稽核資訊
    您可以產生支援服務包,並在其中納入來自於 NSX-T 應用裝置、而可供「VMware 支援」用來診斷客戶回報問題的資訊。此支援服務包含有稽核資訊,內含應用裝置之有效使用者的使用者名稱。

  • 問題 1608972:要變更 NSX Manager HTTP 連線逾時或工作階段逾時,必須要重新啟動
    要變更 NSX Manager HTTP 連線逾時或工作階段逾時,需要重新啟動。NSX 說明文件並未涵蓋此主題。您可以透過 API 或 CLI 來重新啟動 HTTP 服務。
    API- POST /api/v1/node/services/http?action=restart
    CLI- restart service http

升級已解決的問題
  • 問題 1953721:NSX Edge 升級間歇性失敗

    NSX Edge 升級期間,升級程序可能會由於第一次嘗試升級 NSX Edge 失敗而暫停。

    因應措施:第一次嘗試 NSX Edge 升級失敗後,重新嘗試從 UI 或 API 進行升級。

已知問題

已知問題分類如下。

一般已知問題
  • 問題 1842511:Multihop-BFD 不支援靜態路由

    在 NSX-T 2.0 中,可為 (MH-BGP) Multihop BGP 芳鄰啟用 BFD (雙向轉送偵測)。在 NSX-T 2.0 中無法設定使用 BFD 來支援 Multihop 靜態路由的功能,只有 BGP 可以。請注意,如果您已設定由 BFD 支援的 Multihop BGP 芳鄰,並使用與 BGP 芳鄰相同的 Nexthop 來設定對應的 Multihop 靜態路由,則 BFD 工作階段狀態會同時影響 BGP 工作階段和靜態路由。

    因應措施:無。

  • 問題 1931707:自動傳輸點功能要求叢集中的所有主機都具有相同的 pnics 設定

    自動傳輸點功能要求叢集中的所有主機都具有相同的 pnics 設定。範本中的所有 pnics 必須可供傳輸節點組態的所有主機使用,否則 pnics 遺失或遭佔用之主機上的傳輸節點組態可能失敗。

    因應措施:如果傳輸節點組態失敗,請重新設定個別傳輸節點以便更正。

  • 問題 1909703:NSX 管理員可在 OpenStack 直接從後端所建立的路由器中建立新的靜態路由、NAT 規則和連接埠

    在 NSX-T 2.0 提供的 RBAC 功能中,NSX 管理員無法從 NSX UI/API 直接刪除或修改由 OpenStack 外掛程式所建立的交換器、路由器、安全性群組等資源。這些資源只能由透過 OpenStack 外掛程式所傳送的 API 來加以修改/刪除。此功能有些限制。目前,NSX 管理員只是不能刪除/修改 OpenStack 所建立的資源,但管理員可以在 OpenStack 所建立的現有資源中建立新資源,例如靜態路由、NAT 規則。

    因應措施:無。

  • 問題 1957072:橋接器節點的上行設定檔應該一律對多個上行使用 LAG

    使用未構成 LAG 的多個上行時,流量無法達到負載平衡,且可能無法正常運作。

    因應措施:在橋接器節點上針對多個上行使用 LAG。

  • 問題 1959647:使用資料庫伺服器別名名稱建立 DSN 時,可能會造成 vCenter Server 安裝失敗

    當您使用資料庫伺服器別名名稱建立 DSN 時,含外部 Microsoft SQL 資料庫的 vCenter Server 安裝會失敗。詳細目錄服務安裝期間會出現下列錯誤:啟動 invsvc 時發生錯誤。

    使用資料庫伺服器的 IP 位址或主機名稱建立 DSN。

  • 問題 1775315:從網頁瀏覽器開啟 Postman 用戶端時,會發生 CSRF 攻擊

    對於使用 Postman、CURL 或其他 REST 用戶端所進行的 API 呼叫,您必須明確提供 XSRF-TOKEN 標頭及其值。使用遠端驗證的第一個 API 呼叫或呼叫 /api/session/create (本機驗證) 在回應物件中承載 XSRF-Token。後續的 API 呼叫在 XSRF-TOKEN 標頭中承載 Token 值做為要求的一部分。
     

    因應措施:新增 X-XSRF-TOKEN 標頭。

  • 問題 1970750:搭配使用 LACP 與快速計時器的傳輸節點 N-VDS 設定檔不會套用至 vSphere ESXi 主機

    設定採用快速速率的 LACP 上行設定檔並套用至 NSX Manager 上的 vSphere ESXi 傳輸節點時,NSX Manager 顯示已成功套用此設定檔,但 vSphere ESXi 主機使用的是預設 LACP 緩慢計時器。

    在 vSphere Hypervisor 上,當傳輸節點上使用來自 NSX Manager 的 LACP NSX 受管理分散式交換器 (N-VDS) 設定檔時,您無法查看 LACP 逾時值 (SLOW/FAST) 的效果。

    因應措施:無。

  • 問題 1989407:具有企業管理員角色的 vIDM 使用者無法覆寫物件保護

    具有企業管理員角色的 vIDM 使用者無法覆寫物件保護,且無法建立或刪除主體身分識別。

    因應措施:以管理員權限登入。
     

  • 問題 1989412:還原連線時,不會反映無法連線到 NSX Manager 時的網域刪除

    如果在無法連線到 NSX Manager 時從原則中刪除網域,還原與 NSX Manager 的連線後,防火牆和所刪除網域的對應規則仍然存在。

    因應措施:無法連線到 NSX Manager 時,請勿從原則刪除網域。

  • 問題 1998217:vSphere ESXi 上可能缺少 HyperBus 介面 vmk50,造成容器建立失敗

    由於 vSphere ESXi 上可能缺少 HyperBus 介面 vmk50,因此不會建立容器。
     

    因應措施:完成下列步驟。

    1. 在 vSphere ESXi 上使用 CLI 擷取 vmk50 連接埠識別碼
      net-dvs | grep vmk50 -C 10
    2. 在 vSphere ESXi 上建立 vmk50 介面。
      esxcli network ip interface add -P <port-id from step-1> -s DvsPortset-0 -i vmk50 -N hyperbus
    3. 將 IP 位址指派給 vmk50 介面。
      esxcfg-vmknic -i 169.254.1.1 -n 255.255.0.0 -s DvsPortset-0 -v <port-id from step-1> -N hyperbus

     

  • 問題 2018478:嘗試從儀表板移除 Widget 會導致當機和堆疊追蹤錯誤

    自訂儀表板使用者介面變更 (例如,從多個 Widget 移除 Widget),導致使用者介面當機和堆疊追蹤錯誤。

    因應措施:完成下列步驟。

    1. 建立 Widget。
    2. 找到您想要修改的多個 Widget。
    3. 新增對多個 Widget 中新建立的 Widget 的參考。
安裝已知問題
  • 問題 1944678:NSX-T 整合式應用裝置需要有效的角色類型

    在 KVM 中部署 NSX-T 整合式應用裝置,而無任何指定的角色或無效的角色類型時,其會以不受支援的組態部署,且啟用所有角色。

    因應措施:需要有效的角色類型 nsx-manager 做為部署參數。

  • 問題 1617459:Ubuntu 的主機組態不支援尋找介面組態檔的來源
    如果 pnic 介面不在 /etc/network/interfaces 檔案中,則不會在網路組態檔中正確設定 MTU。因此,傳輸橋接器的 MTU 組態在每次重新開機後都會遺失。

    因應措施:將 PNIC 介面組態移至 /etc/network/interfaces

  • 問題 1906410:嘗試從 UI 刪除主機,但不先刪除傳輸節點,會導致主機進入不一致的狀態

    嘗試從 UI 刪除主機,但不先刪除傳輸節點,會導致主機進入不一致的狀態。如果您嘗試在主機處於不一致的狀態時刪除傳輸節點,則 UI 不允許您刪除此主機。

    因應措施:

    1. 刪除傳輸節點前,先關閉此傳輸節點上部署的所有承租人虛擬機器的電源。
    2. 從傳輸節點中移除傳輸區域。
    3. 刪除傳輸節點。
    4. 如果已成功刪除傳輸節點,然後再刪除相應的主機。

    如果傳輸節點刪除失敗,請完成知識庫 https://kb.vmware.com/s/article/52068 中的步驟。

  • 問題 1957059:嘗試進行主機取消準備時,如果將包含現有 VIB 的主機新增至叢集,則取消準備會失敗

    將主機新增至叢集之前,如果未完全移除 VIB,則主機取消準備作業會失敗。

    因應措施:請確定主機上的 VIB 已完全移除,並重新啟動主機。

  • 問題 1958308:當主機處於鎖定模式時,主機準備或傳輸節點建立會失敗

    當主機處於鎖定模式時,主機準備或傳輸節點建立會失敗。出現下列錯誤訊息:執行此作業的權限遭拒。

    因應措施:在主機上停用鎖定模式,然後重試主機準備。
     

  • 問題 1944669:在 KVM 上部署 NSX-T 應用裝置

    在 ESX 上部署 NSX-T 應用裝置時,您可使用不同的 RAM 組態部署小型、中型和大型應用裝置。但是,在 KVM 上部署 NSX-T 應用裝置時,必須明確設定 RAM 配置。

    因應措施:在 Ubuntu 上使用 KVM 部署虛擬機器。
    sudo virt-install --vnc --import --name <VM_NAME> --ram 2048 --vcpus 2 --network=bridge:virbr0,model=e1000 --disk path=/path/to/<IMAGE>.qcow2,format=qcow

    --ram 命令列選項必須以 MB 為單位。

    NSX-T 整合式應用裝置

    小型 - 2 個 CPU、8 GB 記憶體虛擬安裝...--ram 8192 --vcpus 2
    中型 - 4 個 CPU、16 GB 記憶體虛擬安裝...--ram 16384 --vcpus 4
    大型 - 8 個 CPU、32 GB 記憶體虛擬安裝...--ram 32768 --vcpus 8

    NSX Controller
    4 個 CPU、16 GB 記憶體虛擬安裝...--ram 2048 --vcpus 4

    NSX Edge
    小型 - 2 個 CPU、4 GB 記憶體虛擬安裝...--ram 4096 --vcpus 2
    中型 - 4 個 CPU、8 GB 記憶體虛擬安裝...--ram 8192 --vcpus 4
    大型 - 8 個 CPU、16 GB 記憶體虛擬安裝...--ram 16384 --vcpus 8

  • 問題 1739120:重新啟動管理平面或管理平面中的 Proton 服務之後,網狀架構節點的部署狀態變得無回應

    當您在網狀架構頁面上使用主機認證新增支援的主機時,狀態會變更為安裝進行中。重新啟動管理平面或管理平面中的 Proton 服務之後,主機的部署狀態會無限期顯示安裝進行中解除安裝進行中

    因應措施:刪除部署狀態為無回應的網狀架構節點,然後再次使用認證新增主機。

NSX Manager 已知問題
  • 問題 1978104:在 Internet Explorer 11 上,NSX Manager 使用者介面中的部分頁面無法存取

    在執行 Internet Explorer 11 的 Windows 機器上,NSX Manager 使用者介面中的儀表板、入門工作流程和負載平衡器頁面無法存取。

      因應措施:在您的 Windows 機器上,使用 Microsoft Edge、Google Chrome 或 Mozilla Firefox 瀏覽器來檢視 NSX Manager 頁面。

  • 問題 1950583:系統升級至 NSX-T 2.0.0 後,NSX Manager 已排程的備份可能會失敗

    從先前版本升級至 NSX-T 2.0.0 版後,有些 NSX-T 環境無法執行已排程的備份。  這個問題是由於舊版到新版的 SSH 指紋格式有所變更。

    因應措施:重新設定已排程的備份。

  • 問題 1576112:KVM Hypervisor 若位於不同的第 2 層區段中,則需要手動設定閘道
    如果您在 NSX Manager 上設定了 IP 集區,並使用該 IP 集區建立傳輸節點,則 Ubuntu KVM 方塊並不會針對在「IP 集區」組態中設定的閘道顯示路由。因此,在不同 L2 區段中的 Hypervisor 上存在的虛擬機器相互間的覆疊流量將會失敗,因為基礎網狀架構主機不知道如何聯繫遠端區段中的網狀架構節點。

    因應措施:為閘道新增路由,使其可將流量路由傳送至位於不同區段中的其他 Hypervisor。如果未手動完成此組態,覆疊流量將會失敗,因為網狀架構節點不知道如何聯繫遠端網狀架構節點。

  • 問題 1710152:在相容模式中,NSX Manager GUI 無法在 Internet Explorer 11 中運作

    因應措施:移至工具 > 相容性檢視設定,然後確認 Internet Explorer 在相容模式中並未顯示 NSX Manager GUI。

  • 問題 1928376:還原 NSX Manager 後,Controller 叢集成員節點的狀態會降級

    如果將 NSX Manager 還原至從叢集卸離此成員節點之前製作的備份映像,控制器叢集成員節點可能會變得不穩定並回報健全狀況狀態已降級。

    因應措施:如果叢集成員資格產生變化,請務必製作新的 NSX Manager 備份。

  • 問題 1954293:管理平面升級期間,連線至邏輯交換器的虛擬機器 vMotion 失敗

    升級管理平面時,如果您嘗試對連線到邏輯交換器的虛擬機器執行 vMotion,則 vMotion 會失敗。

    因應措施:等候管理平面升級完成,然後重試 vMotion。

  • 問題 1954297:如果 NSX Manager 的還原完成,並向 NSX Manager 登錄新的非受 VC 管理 ESX 主機,且其虛擬機器連線至現有邏輯交換器,則在 ESX 主機的 MOB 上,虛擬機器的 MAC 位址會變成空白

    如果 NSX Manager 的還原完成,並向管理平面登錄新的非受 VC 管理的 ESX 主機,且其虛擬機器連線至現有邏輯交換器,則在 ESX 主機的 MOB 上,虛擬機器的 MAC 位址會變成空白。
    對於 NSX Manager 上的 MAC 而言,這對虛擬機器的詳細目錄不會造成任何影響。

    因應措施:無。

  • 問題 1954986:當金鑰從 UI 中刪除時,授權金鑰會顯示在記錄中

    NSX 授權金鑰顯示在 /var/log/syslog 中,如下所示:
    <182>1 2017-03-24T05:03:47.008Z bb-mgr-221 NSX - SYSTEM [nsx@6876 audit="true" comp="nsx-manager" reqId="3d146f2b-fa34-460f-8ac3-56e3c7326015" subcomp="manager"] UserName:'admin', ModuleName:'License', Operation:'DeleteLicense, Operation status:'success', New value: ["<license_key>"] <182>1 2017-03-24T05:03:47.009Z bb-mgr-221 NSX - - [nsx@6876 audit="true" comp="nsx-manager" subcomp="manager"] UserName:'admin', ModuleName:'Batch', Operation:'RegisterBatchRequest, Operation status:'success', New value: [{"atomic":false} {"request":[{"method":"DELETE","uri":"/v1/licenses/<license_key>"}]}]

    如果將應用裝置設定為傳送記錄給外部記錄收集器,則外部記錄收集器上任何已獲得授權的使用者也能看到金鑰值。

    因應措施:無。

  • 問題 1956055:當管理平面資料存放區關閉時,本機管理員使用者無法從 UI 存取技術支援服務包

    當管理平面資料存放區關閉時,本機管理員使用者無法從 UI 存取技術支援服務包。

    因應措施:如果 NSX-T UI 無法正常運作,請使用 CLI 或 API 來產生支援服務包。

  • 問題 1956088:當視圖中的規則集已套用篩選時,如果在儲存至 Manager 之前篩選已取消,則對防火牆 UI 檢視進行的變更可能會遺失

    當視圖中的規則集已套用篩選時,如果在儲存至 Manager 之前篩選已取消,則對防火牆 UI 檢視進行的變更可能會遺失

    因應措施:無。

  • 問題 1957165:載入搜尋結果集中的最後一頁時,若結果集包含 10,040 個以上記錄,則會產生搜尋例外狀況

    針對根據搜尋查詢傳回 10,040 個以上可能物件的大型環境中,嘗試從 UI 清單載入結果集的最後幾個記錄時,您可能會看到例外狀況。

    因應措施:縮小搜尋準則的範圍。

  • 問題 1928447:具有重複虛擬通道端點 IP 位址的 Hypervisor 不會登入管理平面節點 Syslog

    具有重複虛擬通道端點 IP 位址的 Hypervisor 不會登入管理平面節點 Syslog。請確定為 Hypervisor 的虛擬通道端點和 NSX Edge 節點的上行介面指派唯一的 IP 位址。

    因應措施:  無。

  • 問題 1932987:還原管理平面後,管理平面和金鑰管理員伺服器之間的連線失效

    當您從管理平面中斷連結金鑰管理員伺服器,還原管理平面,並嘗試重新連結金鑰管理員伺服器時,連線失效。

    因應措施:無。

NSX Edge 已知問題
  • 問題 1762064:在將 NSX Edge 重新開機後立即設定 NSX Edge VTEP IP 集區和上行設定檔,會導致 VTEP BFD 工作階段成為無法聯繫的狀態
    將 NSX Edge 重新開機後,代理需要一些時間才能重設 NSX Edge 連線。

    因應措施:在 NSX Edge 重新開機後等待約五分鐘,讓代理重設 NSX Edge 連線。

  • 問題 1765087:由 NSX Edge 建立、用以將封包從資料路徑傳輸至 Linux 核心的核心介面,僅支援最多 1600 的 MTU
    資料路徑與核心之間的核心介面不支援 Jumbo 框架。超過 1600 的 BGP 封包大小會被 BGP 精靈截斷及捨棄。超過 1600 的 SPAN 封包大小會被截斷,且封包擷取公用程式會顯示警告。裝載不會截斷,且仍然有效。

    因應措施:無。

  • 問題 1738960:如果 DHCP 伺服器設定檔 NSX Edge 節點取代為其他叢集中的 NSX Edge 節點,由 DHCP 伺服器指定給虛擬機器的 IP 位址即會變更
    此問題是由於被取代的節點與新節點之間缺乏協調所致。

    因應措施:無。

  • 問題 1629542:在單一 NSX Edge 節點上設定轉送延遲,會導致路由狀態顯示錯誤
    以單一 NSX Edge 節點的形式 (而非在 HA 配對中) 執行 NSX Edge 時,設定轉送延遲可能會導致路由狀態的報告不正確。在設定轉送延遲後,路由狀態會誤顯示為關閉,此情況會持續直到轉送計時器到期為止。如果路由器收斂已完成,但轉送延遲計時器尚未到期,則由南到北的資料路徑將如預期繼續推移,即使路由狀態報告為關閉亦然。您可安全地忽略此警告。

  • 問題 1601425:無法複製已向 NSX Manager 叢集登錄的 NSX Edge 虛擬機器
    不支援複製已向 NSX Manager 叢集登錄的 NSX Edge 虛擬機器。此時應部署全新映像。

    因應措施:無。

  • 問題 1585575:無法在連結至第 0 層路由器的第 1 層路由器上編輯 NSX Edge 叢集詳細資料
    如果您在第 1 層邏輯路由器上啟用了 NAT,則必須先指定 NSX Edge 節點或 NSX Edge 叢集,才能將第 1 層路由器連線至第 0 層路由器。NSX 不支援在已連結至第 0 層路由器的第 1 層路由器上編輯 NSX Edge 叢集詳細資料。

    因應措施:若要在已連結至第 0 層路由器的第 1 層路由器上編輯 NSX Edge 叢集詳細資料,請從第 0 層路由器中斷第 1 層路由器的連線、進行變更,然後重新連線。

  • 問題 1955830:當 NSX Edge 叢集名稱包含高位元或非 ASCII 字元時,從 NSX-T 1.1 升級至 NSX-T 2.0 會失敗

    在 NSX-T 1.1 設定中使用高位元或非 ASCII 字元為 NSX Edge 叢集命名時,從 NSX-T 1.1 升級至 NSX-T 2.0 會失敗,並顯示無限迴圈錯誤。
     

    因應措施:在升級之前,將 NSX Edge 叢集重新命名以移除 NSX-T 1.1 設定執行個體上的高位元或非 ASCII 字元。

邏輯網路已知問題
  • 問題 1769922:在 vSphere Client 上,NSX Controller 叢集平面可能會顯示內部 IP 位址 172.17.0.1,而不是實際 IP 位址
    在 vSphere Client 上,NSX Controller 的 IP 位址誤顯示為 172.17.0.1,而不是實際 IP 位址。NSX Manager 的 IP 位址則正確顯示。

    因應措施:不需要執行任何動作。這個表面性的問題並不會影響任何功能。

  • 問題 1771626:不支援變更 NSX Controller 節點的 IP 位址

    因應措施:重新部署 NSX Controller 叢集。

  • 問題 1940046:在多個第 1 層邏輯路由器中新增相同的靜態路由並通告時,東-西向流量失效

    在多個第 1 層邏輯路由器中新增相同的靜態路由並通告時,東-西向流量失效。

    因應措施:首碼位於第 1 層分散式路由器已連線網路的後方時,應僅從起始的第 1 層邏輯路由器通告靜態路由。

  • 問題 1753468:在橋接的 VLAN 上啟用跨距樹狀結構通訊協定 (STP) 會導致橋接器叢集狀態顯示為關閉
    在用來與 LACP 整併橋接的 VLAN 上啟用 STP 時,實體交換器連接埠通道會被封鎖,而導致 ESX 主機上的橋接器叢集顯示為關閉。

    因應措施:停用 STP,或啟用 BPDU 篩選器和 BPDU 保護。

  • 問題 1753468:第 0 層邏輯路由器未彙總路由,而是由邏輯路由器個別加以重新分配
    第 0 層邏輯路由器並未針對未涵蓋所有已連接之子首碼的首碼執行路由彙總,而是由邏輯路由器個別分配路由

    因應措施:無。

  • 問題 1536251:不支援將一個 ESX 主機中的虛擬機器複製到連結至相同邏輯交換器的另一個 ESX 主機
    從一個 ESX 主機複製虛擬機器時,如果該虛擬機器已登錄於另一個 ESX 主機上,則第 2 層網路會失敗

    因應措施:如果 ESX 主機是 Virtual Center 的一部分,則使用虛擬機器複製。
    如果您在 ESX 主機之間複製了虛擬機器,則外部識別碼在虛擬機器 .vmx 檔案中必須是唯一的,第 2 層網路才能運作。

  • 問題 1747485:從 LAG 介面中移除任何上行,將會使所有 BFD 通訊協定關閉,並翻動 BGP 路由
    從已設定的 LAG 介面中刪除任何介面時,將會使所有的 BFD 通訊協定關閉並翻動 BGP 路由,而對流量造成影響。

    因應措施:無。

  • 問題 1763576:即使 Hypervisor 在 NSX-T 網路上有虛擬機器,仍可將其視為傳輸節點而移除
    即使在屬於 NSX-T 網路的節點上有虛擬機器,NSX-T 也不會阻止您刪除傳輸節點。刪除傳輸節點後,虛擬機器會失去連線。

    因應措施:對於 ESXi 和 KVM 主機,以相同的主機交換器名稱重新建立傳輸節點。

  • 問題 1780798:在大規模環境中,部分主機可能會進入失敗狀態
    在主機節點數大於或等於 200 的大規模環境中,在執行一段時間之後,部分主機可能會失去與 NSX Manager 的連線,且記錄會包含如下的錯誤訊息:
    2016-12-09T00:57:58Z mpa: [nsx@6876 comp="nsx-esx" subcomp="mpa" level="WARN"] Unknown routing key: com.vmware.nsx.tz.*

    因應措施:在失敗的主機上重新啟動 MPA 程序。

  • 問題 1741929:在 KVM 環境中,如果設定了連接埠鏡像並啟用截斷,來自來源的 Jumbo 封包將會以片段傳送,但在鏡像目的地會重新組合

    因應措施:不需要因應措施,因為重新組合會由目的地虛擬機器 vNIC 驅動程式執行。

  • 問題 1619838:變更邏輯路由器對不同組邏輯交換器之傳輸區域連線的作業會因為不符錯誤而失敗
    邏輯路由器對於下行連接埠僅支援單一覆疊傳輸區域。因此,若未刪除現有的下行或路由器連結連接埠,即無法變更不同組邏輯交換器的傳輸區域連線。

    因應措施:完成下列步驟。

    1. 刪除所有現有的下行或路由器連結連接埠。
    2. 等待一段時間,讓系統進行更新。
    3. 重新嘗試變更不同組邏輯交換器的傳輸區域連線。

  • 問題 1620144:即使在傳輸節點遭刪除後,NSX-T CLI get logical-switches 仍會列出狀態為「啟動」的邏輯交換器
    NSX-T CLI 可能會讓使用者誤認為有可運作的邏輯交換器。即使有邏輯交換器顯示出來,實際上卻是無法運作的。傳輸節點被刪除後,會停用不透明交換器,因此不會有任何流量通過。

    因應措施:無。

  • 問題 1625360:在建立邏輯交換器後,NSX Controller 不一定會顯示新建立的邏輯交換器資訊

    因應措施:在建立邏輯交換器後等待 60 秒,再於 NSX Controller 上查看邏輯交換器資訊。

  • 問題 1581649:在建立和刪除邏輯交換器後,VNI 集區範圍無法縮小
    範圍縮小失敗,因為 VNI 並未在邏輯交換器刪除後立即釋放。VNI 會在 6 個小時後釋放。這是為了防止 VNI 在其他邏輯交換器建立時被重複使用。因此,在邏輯交換器刪除後,您必須在 6 個小時後才能縮小或修改範圍。

    因應措施:若要修改 VNI 為邏輯交換器配置的範圍,請在刪除邏輯交換器之後等待 6 小時。或者,請使用 VNI 集區中的其他範圍,或重複使用相同範圍而不要縮小或刪除範圍。

  • 問題 1516253:Intel 82599 NIC 具有「已接收的佇列位元組計數器 (QBRC)」方面的硬體限制,會在已接收的位元組總計超過 0xFFFFFFFFF 時導致溢位
    由於有此硬體限制,在溢位發生時,get dataplane physical-port stats 的 CLI 輸出將不符合實際數目。

    因應措施:執行 CLI 一次,讓計數器在較短的持續期間內重設及重新執行。

  • 問題 1954997:如果在刪除傳輸節點時,傳輸節點上的虛擬機器連線至邏輯交換器,傳輸節點刪除會失敗
    1. 建立網狀架構節點和傳輸節點。
    2. 將 VIF 連結至邏輯交換器。
    3. 如果不移除 VIF 與邏輯交換器的連結,則刪除傳輸節點會失敗。

    因應措施:刪除傳輸節點上對應之虛擬機器的所有 VIF 連結 (必須從 NSX 移除),然後再刪除傳輸節點。

  • 問題 1958041:當 ESX Hypervisor 具有多個上行時,BUM 流量對實體第 2 層區段的第 3 層流量可能無法正常運作

    如果符合下列所有條件,則來自邏輯路由器中來源 Hypervisor 的 BUM 流量可能不會到達目的地 Hypervisor。

    • ESX 具有多個上行
    • 來源和目的地虛擬機器透過邏輯路由器連線
    • 來源和目的地 Hypervisor 位於不同的實體區段
    • 目的地邏輯網路使用 MTEP 複寫

    發生此情況的原因是 BFD 模組可能尚未建立工作階段,這表示目的地邏輯網路的 MTEP 選取可能尚未發生。

    因應措施:

    1. 在目的地 Hypervisor 或位於相同目的地第 2 層實體區段中任何其他 Hypervisor 上的目的地邏輯網路中啟動虛擬機器。
    2. 將目的地邏輯網路的複寫模式變更為來源複寫。
    3. 在傳輸區域中停用 BFD。
  • 問題 1966641:新增主機並將其設定為傳輸節點後,如果該節點不屬於邏輯交換器,其狀態會顯示為 [關閉]

    新增主機並將其設定為傳輸節點後或設定至 NSX-T 2.1 的升級計劃時,如果傳輸節點不屬於邏輯交換器,在使用者介面上其狀態會顯示為 [關閉]。

    因應措施:針對傳輸節點建立邏輯交換器,以便通道在該邏輯交換器中建立與其他傳輸節點的連線。

  • 問題 2015445:作用中服務路由器上的防火牆狀態可能不會在新的作用中服務路由器上複製

    承租人邏輯路由器 (TLR) 可能有多個從 NSX Edge1 至 NSX Edge2 以及從 NSX Edge2 至 NSX Edge1 的容錯移轉。防火牆或 NAT 流程狀態會在作用中/待命 TLR 服務路由器之間同步。在非先佔式容錯移轉模式下設定 TLR 時,同步會在第一個容錯移轉之前發生,但不會在第一個容錯移轉與後續容錯移轉之間發生。因此,在第二個容錯移轉時,TCP 流量會逾時。在先佔式模式下設定的 TLR 不會發生此問題。


    因應措施:將邏輯路由器組態變更為先佔式模式。

  • 問題 2016629:移轉後,RSPAN_SRC 鏡像工作階段會失敗

    當連線到為 RSPAN_SRC 鏡像工作階段指派的連接埠的虛擬機器移轉至另一個 Hypervisor,並且目的地 Hypervisor 的目的地網路上沒有所需的 pNic 時,將無法在連接埠上設定 RSPAN_SRC 鏡像工作階段。此失敗會導致連接埠連線失敗,但 vMotion 移轉程序會成功完成。

    因應措施:若要還原連接埠連線失敗,請完成下列其中一項工作。

    • 移除失敗的連接埠,並新增連接埠。
    • 停用連接埠,然後再將其啟用。

    無法設定鏡像工作階段,但連接埠連線已還原。

安全服務已知問題
  • 問題 1680128:用戶端與伺服器之間的 DHCP 通訊未加密

    因應措施:使用 IPSEC 提高通訊的安全性。

  • 問題 1711221:IPFIX 資料會透過網路以純文字格式傳送
    依預設會關閉收集 IPFIX 流量的選項。

    因應措施:無。

  • 問題 1726081:Geneve 通道流量 (UDP) 在 KVM 中遭拒

    因應措施:執行下列步驟以允許 Geneve 通道流量
    如果 KVM 使用 firewalld,請使用下列命令在防火牆中建立一個開口:
    # firewall-cmd --zone=public --permanent --add-port=6081/udp
    如果 KVM 直接使用 IPtables,請使用下列命令建立開口:
    # iptables -A INPUT -p udp --dport 6081 -j ACCEPT
    如果 KVM 使用 UFW,請使用下列命令建立開口:
    # ufw allow 6081/udp

  • 問題 1520694:在 RHEL 7.1 核心 3.10.0-229 和較舊版本中,FTP ALG 無法在資料通道上開啟交涉的連接埠
    對於 FTP 工作階段 (用戶端和伺服器都位於相同 Hypervisor 上的虛擬機器中),FTP 應用程式層級閘道 (ALG) 不會開啟資料通道的交涉連接埠。這是 Red Hat 才會有的問題,出現在 RHEL 7.1 核心 3.10.0-229 中。較新的 RHEL 核心不受影響。

    因應措施:無。

  • 問題 1590888:需要有警告指出在 [乙太網路] 區段中選取的邏輯連接埠只會套用於相同的 L2 網路內
    對於 NSX-T 分散式防火牆,在 [乙太網路] 區段中,如果在來源/目的地區段中輸入了任何邏輯連接埠或 MAC 位址,則應有警告指出 MAC 位址或邏輯連接埠應屬於相同 L2 網路 (連結至相同邏輯交換器) 的虛擬機器連接埠。目前並沒有警告訊息。

    因應措施:無。

  • 當用戶端位於不同的網路且路由服務由客體虛擬機器提供時,DHCP 版本和更新封包不會到達 DHCP 伺服器

    NSX-T 無法區分虛擬機器是否用作路由器,因此使用路由器虛擬機器路由傳送的單點傳播 DHCP 封包可能會遭到捨棄,原因是封包中的 CHADDR 欄位不符合來源 MAC。CHADDR 具有 DHCP 用戶端虛擬機器的 MAC,而來源 MAC 則來自路由器介面。

    因應措施:如果虛擬機器的行為類似路由器,請在套用至路由器虛擬機器之所有 VIF 的交換器安全性設定檔中停用 DHCP 伺服器區塊
     

  • 問題 2008882:要使 Application Discovery 正常運作,不要建立跨多台主機的安全群組

    如果一個安全群組具有跨多台主機的虛擬機器,Application Discovery 工作階段可能會失效。

    因應措施:僅在一台主機上建立虛擬機器安全群組。您可以針對數台主機建立多個安全群組,並分別在其上執行 Application Discovery。

作業和監控服務已知問題
  • 問題 1749078:刪除 ESXi 主機和對應的主機傳輸節點上的承租人虛擬機器後,刪除 ESXi 主機的作業會失敗
    刪除主機節點的作業涉及重新設定不同的物件,而可能需要數分鐘或更久。

    因應措施:等待數分鐘,然後重試刪除作業。視需要重複執行。

  • 問題 1761955:在登錄虛擬機器後,無法將虛擬機器的 vNIC 連線至 NSX-T 邏輯交換器
    如果使用現有的 vmx 檔案來登錄 ESXi 主機上的虛擬機器,登錄作業會忽略下列 vNIC 特定錯誤:

    • 以無效的網路支援設定的 vNIC。
    • 連線至 NSX-T 邏輯交換器之 vNIC 的 VIF 連結失敗。

    因應措施:完成下列步驟。
    1. 在標準 vSwitch 上建立暫時連接埠群組。
    2. 將處於中斷連線狀態的 vNIC 連結至新的連接埠群組,並將其標示為已連線。
    3. 將 vNIC 連結至有效的 NSX-T 邏輯交換器。

  • 問題 1774858:在極少數情況下,NSX Controller 叢集在執行多日之後會變成非作用中狀態
    當 NSX Controller 叢集變成非作用中狀態時,所有的傳輸和 NSX Edge 節點都會失去 NSX Controller 的連線,而且無法進行組態的變更。但資料流量不受影響。

    因應措施:完成下列步驟。

    • 修正現有的磁碟延遲問題。
    • 在所有 NSX Controller 上重新啟動 cluster-mgmt 服務。

  • 問題 1576304:捨棄的位元組計數未納入為連接埠狀態和統計資料報告的一部分
    使用 /api/v1/logical-ports/<lport-id>/statistics 或 NSX Manager 來檢視邏輯連接埠狀態和統計資料時,捨棄的封包計數值會是 0。此值不正確。無論捨棄的封包數量為何,此處顯示的數字一律會空白。

    因應措施:無。

  • 問題 1955822:授權使用量報告 csv 檔案也應包含 CPU 和虛擬機器權利,以及實際使用量

    查詢授權使用量報告時 (透過 API/UI) 時,資料僅包含目前的使用量。

    因應措施:透過 UI 或 REST API 查詢目前授權允許的使用量限制:
    方法:GET; URI: /api/v1/licenses

  • 問題 1957092:由於在載入 Docker 映像時發生錯誤而無法初始化 NSX Controller 叢集

    initialize control-cluster 命令失敗,並顯示錯誤訊息:控制叢集啟用逾時。請再試一次。syslog 中還會顯示下列記錄資訊:
    <30>1 2017-08-03T22:52:41.258925+00:00 localhost load-zookeeper-image 1183 - - grpc: the connection is unavailable.

    因應措施:請再次執行 initialize control-cluster 命令。

KVM 網路已知問題
  • 問題 1775916:在 RHEL KVM 主機新增至網狀架構失敗之後,解析程式 API POST /api/v1/error-resolver?action=resolve_error 未解析錯誤
    在 RHEL KVM 主機無法新增至網狀架構,且 NSX Manager 使用者介面將安裝狀態顯示為失敗之後,系統將會執行解析程式 API POST /api/v1/error-resolver?action=resolve_error 以解析錯誤。不過,重新將該主機新增至網狀架構時,會產生下列錯誤訊息:
    無法在主機上安裝軟體。未處理的部署外掛程式執行動作。
    安裝命令失敗。


    因應措施:完成下列步驟。

    1. 手動移除下列套件。
      rpm -e glog-0.3.1-1nn5.x86_64
      rpm -e json_spirit-v4.06-1.el6.x86_64
      rpm -e kmod-openvswitch-2.6.0.4557686-1.el7.x86_64
      rpm -e nicira-ovs-hypervisor-node-2.6.0.4557686-1.x86_64
      rpm -e nsx-agent-1.1.0.0.0.4690847-1.el7.x86_64
      rpm -e nsx-aggservice-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-cli-1.1.0.0.0.4690892-1.el6.x86_64
      rpm -e nsx-da-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-host-1.1.0.0.0.4690932-1.x86_64 rpm -e nsx-host_node_status_reporter-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-lldp-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-logical_exporter-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-mpa-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-netcpa-1.1.0.0.0.4690924-1.el7.x86_64 rpm -e nsx-sfhc-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-support-bundle-client-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-transport_node_status-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsxa-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e openvswitch-2.6.0.4557686-1.x86_64
      rpm -e openvswitch-selinux-policy-2.6.0.4557686-1.noarch
      rpm -e python-simplejson-3.3.3-1.el7.x86_64
      如果在執行 rpm -e 命令時有任何錯誤,請在命令中加上 --noscripts 旗標。
    2. 執行解析程式 API POST /api/v1/error-resolver?action=resolve_error
    3. 重新將 KVM 主機新增至網狀架構。

  • 問題 1602470:在 KVM 上不支援負載平衡整併

  • 問題 1611154:一個 KVM 傳輸節點中的虛擬機器無法聯繫位於另一個傳輸節點中的虛擬機器
    有多個 IP 集區用於屬於不同網路的 VTEP 時,KVM 主機上的虛擬機器可能會無法聯繫在具有不同 IP 集區之 VTEP IP 位址的其他主機上部署的虛擬機器。

    因應措施:新增路由,使 KVM 傳輸節點可聯繫其他傳輸節點上的 VTEP 所使用的所有網路。
    例如,如果您有 25.10.10.0/24 和 35.10.10.0/24 這兩個網路,且本機 VTEP 的 IP 位址為 25.10.10.20,閘道為 25.10.10.1,則您可以使用下列命令為另一個網路新增路由:
    ip route add dev nsx-vtep0.0 35.10.10.0/24 via 25.10.10.1

  • 問題 1654999:底層流量的連線追蹤會減少可用的記憶體
    在虛擬機器間建立大量連線時,可能會出現下列症狀。
    在 /var/log/syslog 或 /var/log/messages 檔案中,您會看見如下的項目:
    Apr 26 11:45:44 prmh-nsx-perf-server149 kernel: [1625289.950872] net_ratelimit: 239 callbacks suppressed
    Apr 26 11:45:44 prmh-nsx-perf-server149 kernel: [1625289.950875] nf_conntrack: table full, dropping packet
    Apr 26 11:45:44 prmh-nsx-perf-server149 kernel: [1625289.958436] nf_conntrack: table full, dropping packet
    問題似乎會在設定了預設防火牆規則時顯現。如果未設定防火牆規則,則不會顯現此問題 (例如:將邏輯交換器放在防火牆排除清單中)。
    附註:上方的記錄摘要只是範例。日期、時間和環境變數可能隨著您的環境而不同。

    因應措施:新增防火牆規則,在底層裝置的連接埠 6081 上停用 UDP 的連線追蹤。
    以下是範例命令:
    # iptables -A PREROUTING -t raw -p udp --dport 6081 -j CT --notrack
    此命令應設定在開機期間執行。如果平台也啟用了防火牆管理員 (Ubuntu:UFW;RHEL:firewalld),則應透過防火牆管理員設定對等的規則。請參閱相關的知識庫 2145463

  • 問題 2002353:不支援使用 Linux 網路管理員來管理 KVM 主機上行

    NSX-T 管理 KVM 主機上用於 N-VDS 的所有 NIC。針對這些上行啟用網路管理員時,會發生組態錯誤。

    因應措施:對於 Ubuntu 主機,從網路管理員排除用於 NSX-T 的 NIC。

    在 Red Hat 主機上啟用 NSX-T 之前,先將 /etc/sysconfig/network-scripts 中的 NIC 組態指令碼修改為 NM_CONTROLLED ="no"。如果已針對主機啟用 NSX-T,請進行相同的指令碼修改,然後重新啟動主機的網路功能。
     

解決方案互通性已知問題
  • 問題 1588682:將 ESXi 主機置於鎖定模式,會停用使用者 nsx-user
    當 ESXi 主機置於鎖定模式時,使用者 vpxuser 將是唯一能夠驗證主機或執行任何命令的使用者。NSX-T 仰賴另一個使用者 nsx-user 在主機上執行所有 NSX-T 相關工作。

    因應措施:不要使用鎖定模式。請參閱 vSphere 說明文件中的鎖定模式

  • 問題:2025624:載入時 Splunk 儀表板停滯或儀表板上的圖表為空白

    由於 HTML 範本錯誤地指向查詢指令碼的先前路徑,因此 Splunk 會擷取舊版 nsx_splunk_app。這樣一來,儀表板會執行包含諸如 vmw_nsxt_compvmw_nsxt_subcompvmw_nsxt_errorcode 等欄位的舊查詢,這些欄位在更新版本的查詢指令碼中以不同方式命名。因此,查詢會傳回空結果,且儀表板會保留空白。

    因應措施:將檔案 nsx_splunk_app.spl 重新命名為 logger.spl、將重新命名的檔案上傳到 Splunk Enterprise 伺服器,然後重新啟動該伺服器。這會安裝 NSX Splunk App 1.0 版,並且其儀表板將正確處理舊查詢。

API 已知問題
  • 問題 1781225:API GET https://<NSX-Manager>/api/v1/fabric/nodes/<node-id>/modules 不適用於 Ubuntu
    API GET https://<NSX-Manager>/api/v1/fabric/nodes/<node-id>/modules 適用於 ESXi 和 RHEL,但不適用於 Ubuntu。

    因應措施:無

  • 問題 1605461:Syslog 中的 NSX-T API 記錄會顯示系統內部 API 呼叫。NSX-T 將使用者叫用的 API 呼叫和系統叫用的 API 呼叫都記錄至 Syslog
    Syslog 中的 API 呼叫事件記錄並未顯示使用者直接呼叫 NSX-T API。您可以在記錄中看到 NSX Controller 和 NSX Edge API 呼叫,即便這些 NSX-T 應用裝置並沒有公開的 API 服務。這些私人 API 服務由 NSX-T CLI 之類的其他 NSX-T 服務所使用。

    因應措施:無。

  • 問題 1619450:垂直測試經由輪詢頻率組態 API GET /api/v1/hpm/features 而傳回
    GET /api/v1/hpm/features 會傳回所有可設定輪詢頻率之功能的清單。此 API 會傳回一些內部的僅限測試功能。除了有雜訊外,使用者的功能不受影響。

    因應措施:忽略外來的 API 回應。

  • 問題 1641035:POST/hpm/features/<feature-stack-name?action=reset_collection_frequency> 的 Rest 呼叫不會還原覆寫統計資料的 collection_frequency
    如果您嘗試使用此 REST 呼叫將收集頻率重設為其預設值,則它不會進行重設。
    因應措施:使用 PUT /hpm/features/<feature-stack-name>,並將 collection_frequency 設為新值。

  • 問題 1648571:隨需狀態和統計資料要求出錯,此情況會斷斷續續發生。HTTP 失敗代碼不一致
    在特定情況下,隨需要求會失敗。有時候,這些要求會因為 HTTP 500 錯誤而失敗 (而不是因為 HTTP 503 錯誤),即便 API 呼叫在重試時成功了。
    就統計資料 API 而言,逾時情況可能會導致假性的訊息路由錯誤記錄。之所以發生此狀況,是因為在逾時期間到期後傳回了回應。
    例如,可能會發生如下的錯誤:java.lang.IllegalArgumentException: Unknown message handler for type com.vmware.nsx.management.agg.messaging.AggService$OnDemandStatsResponseMsg.
    就狀態 API 而言,逾時情況 (回應在逾時之後傳回) 可能會導致快取提前更新。

    因應措施:重試 API 要求。

  • 問題 1954990:傳回不準確的實現 API 狀態

    如果使用實現 API 檢查屏障前執行之所有 API 的實現狀態,實現 API 的傳回狀態會與實際狀態產生差異。由於在管理平面中執行 DFW 的程序極為複雜,DFW API 可能會在應該遵循的屏障後發生差錯,因而造成狀態不準確的情形。

    因應措施:請勿依賴解析 API 來評估實際的實現狀態。

文件勘誤與增補
  • 問題 1372211:兩個介面位於相同子網路上
    如果通道端點位於與管理介面相同的子網路上,通道流量即可能外流至管理介面。之所以發生此狀況,是因為通道封包可能經過管理介面。請確定管理介面位於與通道端點介面不同的子網路上。

  • 問題:API 要求會導致 403 禁止、錯誤的 XSRF Token 錯誤
    當您登入 NSX Manager Web 使用者介面時,NSX Manager Cookie 只有在 Web 使用者介面中才可供使用。如果您透過使用相同 Cookie 來源的應用程式 (例如瀏覽器延伸) 來傳送 API 要求,將會出現「403 禁止/錯誤的 XSRF Token」回應。
    {
    “module_name": “common-service",
    “error_message": “Bad XSRF token",
    “error_code": “98"
    }


    因應措施:您必須登出 NSX Manager Web 使用者介面,或改用使用不同 Cookie 來源的 REST 用戶端。
    例如,您可以將一個瀏覽器用於 Web 使用者介面存取,並使用不同瀏覽器的延伸來存取 API。您也可以取得不需要 XSRF 標頭的工作階段 Cookie。

    如需詳細資訊,請參閱《NSX-T API 指南》的〈工作階段型驗證〉一節。

升級問題
  • 問題 1930705:管理平面升級期間連線至邏輯交換器的虛擬機器 vMotion 失敗

    在管理平面升級期間,嘗試對連線至邏輯交換器的虛擬機器執行 vMotion 會失敗。
     

    因應措施:等候管理平面升級完成,然後重試 vMotion 處理程序。

  • 問題 1944731:升級第二個 NSX Edge 期間,如果第一個已升級的 NSX Edge 提供大量要求,則 DHCP 租用可能具有衝突的記錄

    升級第二個 NSX Edge 期間,如果第一個已升級的 NSX Edge 提供大量要求,則 DHCP 租用可能具有衝突的記錄。

    因應措施:升級期間請勿使用 DHCP 服務,或手動釋放升級期間擷取的 DHCP 供應項目。

  • 問題 1847884:請勿進行 NSX-T 相關的變更,除非管理平面的升級程序已完成

    在管理平面升級期間執行任何變更,例如,建立、更新或刪除傳輸區域、傳輸節點或邏輯交換器,可能會損毀管理平面,導致 NSX Edge、主機和資料路徑連線失效。

    因應措施:請等候升級完成。刪除升級期間所做的變更並重新設定先前所做的變更。

  • 問題 2005423:從舊版 NSX-T 升級的 KVM 節點不會自動變更為使用 balance-tcp

    NSX-T 不會自動將升級後的 KVM 主機上行的繫結模式從主動備份修改為 balance-tcp。

    因應措施:即使沒有任何組態變更,也請編輯傳輸節點,以更正模式設定。

  • 問題 2005709:當您使用 NSX Manager FQDN 時,升級協調器頁面變得無法存取

    當您使用 NSX Manager FQDN 開啟 NSX Manager 使用者介面時,升級協調器頁面中出現下列錯誤訊息:僅當升級協調器正在執行時,此頁面在 NSX Manager 上才可用。若要啟用服務,請在 NSX Manager 上執行命令「set service install-upgrade enabled」。如果安裝-升級服務已啟用,請先嘗試使用「clear service install-upgrade enabled」將其停用,然後再次將其啟用。

    因應措施:使用 NSX Manager IP 位址來存取使用者介面。

  • 問題 2022609:受管理的主機在升級協調器中被視為未受管理的主機

    如果環境中有超過 128 部受管理的主機,升級程序期間屬於叢集的主機會出現在未受管理的 ESXi 群組中。

    因應措施:

    • 手動升級超過 128 部未受管理的 ESXi 主機。
    • 導覽至 /opt/vmware/upgrade-coordinator-tc-server/webapps/upgrade-coordinator/WEB_INF/classes/config.properties 檔案,將 upgrade.host.service.hostNodeListPageSize 的值從 128 變更為 512,然後重新啟動升級協調器 /etc/init.d/upgrade-coordinator restart
負載平衡器已知問題
  • 問題 195228:組態變更和重新載入後,加權循環配置資源和加權最少連線演算法可能不會正確散佈流量

    加權循環配置資源或加權最少連線組態發生變更並重新載入時,伺服器會中斷連線。連線中斷後,不會保留歷史流量散佈資訊,這將導致無法正確散佈流量。

    因應措施:無。

  • 問題 2010428:負載平衡器規則建立與應用程式限制

    在使用者介面中,您可以僅從虛擬伺服器建立負載平衡器規則。使用 REST API 建立的負載平衡器規則無法在使用者介面中連結到虛擬伺服器。

    因應措施:如果您使用 REST API 建立了負載平衡器規則,請使用 REST API 將該負載平衡器規則連結至虛擬伺服器。使用 REST API 建立的規則現在會出現在使用者介面的虛擬伺服器中。

  • 問題 2016489:選取伺服器名稱指示時,LCP 無法設定預設憑證

    在伺服器名稱指示 (SNI) 中使用多個憑證識別碼以避免 LCP 略過預設憑證時,應先在憑證清單中設定預設憑證識別碼。

    因應措施:預設憑證應位於 SNI 憑證清單中的第一個。

  • 問題 2018629:健全狀況檢查資料表不顯示 NS 群組集區已更新的監控類型

    當您使用相同的成員和一種監控類型建立靜態和動態 NS 群組集區,並變更動態集區上的該監控類型時,動態集區健全狀況檢查不會出現在健全狀況檢查資料表中。

    因應措施:使用一種監控建立動態群組集區,然後使用相同的成員和一種監控建立靜態集區,以便健全狀況檢查資料表顯示這兩種集區監控。

  • 問題 2020372:達到失敗計數上限後,被動健全狀況檢查不會將集區成員考慮在內

    被動健全狀況檢查需要比設定計數更多的失敗計數值,才會將集區成員考慮在內。

NSX Container Plug-in (NCP) 已知問題
  • 問題 2051265:針對網路原則,NCP 僅支援基於等式的標籤選取器

    網路原則使用標籤選取器選取網繭/命名空間。目前,NCP 僅支援基於等式的標籤選取器。不支援基於不等式和基於集的標籤選取器。

    因應措施:使用基於等式的標籤選取器建立網路原則。

  • 問題 2011712:NCP 不會正確處理網路原則修改事件

    當 NCP 正在執行時,如果發生網路原則修改事件,NCP 可能不會正確處理此事件。例如,隔離規則可能不正確,或來源 IP 集規則可能遺失。

    因應措施:刪除並重新建立網路原則。

check-circle-line exclamation-circle-line close-line
Scroll to top icon