VMware NSX-T 2.2 | 2018 年 6 月 5 日 | 組建編號 8680772

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

版本說明的內容

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

新增功能

新增功能
NSX-T 2.2 是累加式升級版本,可增強針對雲端和容器提供的全新多 Hypervisor 平台。
 
NSX-T 2.2 版本中提供了下列新功能、增強功能和已過時的功能。
                                                           

                                                                                                                         新的 NSX-T 功能

自動化 NSX Controller 叢集部署

從 NSX Manager 自動部署 NSX Controller 叢集至從 vCenter Server 探索的 vSphere 叢集,來簡化 vSphere 環境中的 NSX-T 安裝。

Azure 中工作負載的 NSX 管理

  • NSX Datacenter 和 NSX Cloud 隨附內部部署和 Azure 工作負載的單一虛擬管理介面。
  • 跨混合雲的單一安全性原則提供各種屬性集,包括虛擬機器名稱、自訂標記。
  • 從安全性強制執行分離工作負載部署。

NIOC 第 3 版支援

根據 ESXi 主機上的實體介面卡容量,Network IO Control (NIOC) 允許針對系統產生和使用者定義的網路資源集區,在網路上可設定限制和共用率。

  • 提供一種機制,可根據主機上的實體介面卡容量為系統流量保留頻寬。
  • 可在虛擬機器網路介面卡層級啟用更為精細的資源控制,以用於配置 CPU 和記憶體資源。
  • 允許在整個分散式交換器 (N-VDS) 的層級設定虛擬機器的頻寬配置。

客體 VLAN 標記

vSwitch (在此案例中為 N-VDS) 連接埠會像主幹般運作,並檢查傳入 VLAN 標記,以確保其符合正確的目的地虛擬連接埠。但是,N-VDS 會將 VLAN 標記保持原樣。

功能適用於 VLAN 支援的和覆疊支援的流量,且僅針對根據客體 VLAN 標記轉送封包來支援橋接。不支援在 Hypervisor 中根據客體 VLAN 標記進行路由。

VPN 支援

以 IPsec 為基礎的第 2 層 VPN 和第 3 層 VPN 支援站台間連線,可以僅使用 NSX-T API 來設定。

客戶經驗改進計劃

VMware 客戶經驗改進計劃 (CEIP) 支援收集產品使用資訊以及向 VMware 報告,來改善 NSX-T 的品質。客戶可以選擇性地停用此功能。

Terraform 支援

Terraform 提供者支援可自動化 NSX-T 邏輯物件,例如交換器、路由器、防火牆規則,以及群組。

在 NSX Edge 的祼機上支援 Cisco VIC 1387

支援 Cisco UCS 系統中使用的 NIC。

NSX Container Plug-in (NCP) 功能

  • Kubernetes 入口的 TLS 支援
    在整合 Kubernetes 入口和密碼的 NSX-T 負載平衡器中支援 HTTPS 終止。所有含 TLS 區段的 Kubernetes 入口,都將主控於連接埠 443 上 HTTPS 終止所專用的 NSX-T 負載平衡器。
  • OpenShift 路由器支援
    NSX-T 負載平衡器可用作 OpenShift 路由器,以透過路由資源向外部第 7 層流量公開服務。支援具有 Edge 終止的 HTTP 流量和 HTTPS 流量。
  • 建立標籤時支援較長的名稱和值
    NSX-T 物件上的標籤現在允許標籤範圍最多 30 個字元,標籤值最多 65 個字元。
  • OpenShift 安裝改進功能
                                                                                                                                 NSX-T 增強功能
 

N-VDS 增強型資料路徑模式

與 vSphere 6.7 搭配使用時,支援稱為增強型資料路徑的高效能模式。此模式會實作一些主要 DPDK 功能,例如,輪詢模式驅動程式、流程快取、最佳化封包複製,並且針對網路功能虛擬化 (NFV) 樣式工作負載相關的小型和大型封包大小,提供更好的效能。電信業者現在可以擁有高效能的虛擬交換器,同時享有虛擬化的任何優勢,例如 vMotion 或 Predictive DRS。

附註:在增強型資料路徑模式下運作時,並非所有 N-VDS 功能均可使用。

監控和疑難排解增強功能

  • Traceflow API 增強功能,可使用 NSX-T DHCP 服務疑難排解 IP 位址指派。
  • 新增連接埠鏡像類型,即邏輯 SPAN,可在相同的邏輯覆疊交換器上監控來源連接埠至目的地連接埠。
  • 將套用至 NSGroup 的增強型 IPFIX 設定檔。

基於 VLAN 的邏輯交換器整併原則支援 ESXi 主機

啟用邏輯交換器流量到特定上行的關聯或釘選。可以根據原始虛擬連接埠,使用路由整併原則進行設定。

NSX Edge 防火牆介面

在第 1 層或第 0 層邏輯路由器上,以每個上行為基準的第 4 層可設定狀態的防火牆,可選擇性地篩選來自各個上行的流量。

分散式和 NSX Edge 防火牆增強功能

可檢視防火牆狀態的集中位置。使用 API 來查詢防火牆狀態發佈作業或擷取特定虛擬機器上是否已部署規則的相關資訊。

主體身分識別角色支援

使用其中一個預設 NSX-T 角色設定主體身分識別。

搜尋增強功能

支援搜尋自動完成。

備份增強功能

提供選項,用於遠端備份或還原封存檔儲存所在系統顯示的信任憑證指紋。

支援 VLAN 支援的下行

將 VLAN 支援的下行連線至第 0 層或第 1 層邏輯路由器,會利用僅在 NSX Edge 節點上可用的集中式路由器連接埠。

負載平衡增強功能

  • 負載平衡器 HTTPS 支援
    • 支援在負載平衡器上終止使用 SSL 的 HTTPS 流量。
    • SSL 卸載負載平衡支援從用戶端到負載平衡器解密的 HTTPS 以及從負載平衡器到伺服器的 HTTP。
    • SSL 端對端支援在從負載平衡器到伺服器的新 HTTPS 中重新加密從用戶端到負載平衡器的 HTTPS。
  • 負載平衡器虛擬伺服器 IP 會顯示並行連線、新連線速率、輸送量、以及 HTTP 要求率的即時圖形。
  • 存取記錄細微度允許特定虛擬伺服器 (而不是負載平衡器) 的記錄設定。
  • 用來下載整個負載平衡器組態的單一 API。
  • 含增強型 HTTP 通訊協定的 WebSocket 應用程式支援。
  • 在第一個伺服器集區的所有成員均關閉的情況下,Sorry 伺服器可依照虛擬伺服器定義要使用的 Sorry 伺服器的第二個伺服器集區。
  • 新負載平衡器規則、相符 Cookie 值和相符值不區分大小寫。
  • 第 4 層多個連接埠範圍支援。 
  • 新負載平衡器規則演算法具有加權最少連線。
  • 為負載平衡器演算法最少連線和加權最少連線自動啟用緩慢啟動,以防止新連線使得新增至現有生產伺服器集區的伺服器應接不暇。
  • POST API 要求 request_body_size 的大小現在可能受限制。

NSX Edge 第 2 層橋接器增強功能

NSX Edge 節點上主控的覆疊服務的 VLAN,使效能優於以 ESXi 為基礎的第 2 層橋接器和第 3 層防火牆。

API 速率限制

針對 NSX-T REST API 限制每秒交易數和並行交易數。這可保護系統在一或多個 API 用戶端以 API 無法處理的速率進行 API 要求時免受影響。

                                                                                                                           已過時的 NSX-T 功能

分散式網路加密功能已過時。

相容性和系統需求

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

NCP 相容性需求:

產品 版本
NCP/用於 PAS 的 NSX-T 圖標 2.2.0
NSX-T 2.1、2.2
Kubernetes 1.9、1.10
OpenShift 3.7、3.9
Kubernetes/OpenShift 主機虛擬機器作業系統     Ubuntu Xenial、RHEL 7.4、RHEL 7.5
PAS (PCF) OpsManager 2.1.x + PAS 2.1.x (PAS 2.1.0 除外)
OpsManager 2.2.0 + PAS 2.2.0

一般行為變更

從傳輸節點到 NSX Controller 的通訊變更

由於從傳輸節點到 NSX Controller 的通訊發生變更,您現在必須針對 NSX-T 2.2 及更高版本開啟 TCP 連接埠 1235。請參閱《NSX-T 安裝指南》

從 NSX-T 2.1 升級時,必須開啟 TCP 連接埠 1234 和 1235。升級完成後,TCP 1235 連接埠處於使用中。

API 參考資訊

請參閱〈NSX-T 和 NSX 原則已過時的 API 呼叫和內容〉

最新的 API 參考位於〈NSX-T 產品資訊〉內。

已解決的問題

已解決的問題分類如下。

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

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

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

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

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

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

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

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

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

    1. 建立 Widget。
    2. 找到您想要修改的多個 Widget。
    3. 新增對多個 Widget 中新建立的 Widget 的參考。
  • 問題 1959647:使用資料庫伺服器別名名稱建立 DSN 時,可能會造成 vCenter Server 安裝失敗

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

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

  • 問題 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

     

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

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

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

  • 問題 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

  • 問題 1944678:NSX-T 整合式應用裝置需要有效的角色類型

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

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

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

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

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

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

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

    因應措施:無。

  • 問題 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 而言,這對虛擬機器的詳細目錄不會造成任何影響。

    因應措施:無。

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

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

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

  • 問題 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 來產生支援服務包。

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

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

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

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

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

邏輯網路已解決的問題
  • 問題 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 移轉程序會成功完成。

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

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

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

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

    因應措施:無。

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

    因應措施:無。

  • 問題 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 程序。

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

    因應措施:無。

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

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

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

負載平衡器已解決的問題
  • 問題 195228:組態變更和重新載入後,加權循環配置資源和加權最少連線演算法可能不會正確散佈流量

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

    因應措施:無。

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

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

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

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

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

解決方案互通性已解決的問題
  • 問題: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 版,並且其儀表板將正確處理舊查詢。

作業和監控服務已解決的問題
  • 問題 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 命令。

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

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

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

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

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

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

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

    因應措施:忽略外來的 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。

    因應措施:無

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

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

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

NSX Container Plug-in (NCP) 已解決的問題 (附註:NCP 2.2 支援 NSX-T 2.1。只有在您執行 NSX-T 2.2 時,才會解決下列問題。)
  • 問題 2083074:NSX Manager 顯示容器邏輯連接埠不正確的自動探索位址繫結。

    如果為容器邏輯連接埠和容器主機上虛擬機器的邏輯連接埠 (透過 IP 探索交換設定檔) 啟用 ARP 窺探,NSX Manager 的 GUI 可能會顯示容器邏輯連接埠的不正確自動探索位址繫結。這是外觀錯誤,可予以略過。實際位址繫結會顯示在 [手動繫結] 下。

    因應措施:不需要執行任何動作。

  • 問題 2091962:虛擬機器的 Pivotal BOSH 佈建在 NSX-T 上隨機失敗

    當 Pivotal BOSH 在 vSphere 上部署新虛擬機器時,佈建可能會隨機失敗。

    因應措施:請參閱 https://kb.vmware.com/s/article/54139

  • 問題 2094336:新建立的虛擬機器在 NSX-T 詳細目錄中不可見

    當 Pivotal BOSH 在 vSphere 上部署新虛擬機器時,虛擬機器可能不會顯示在 NSX-T 的詳細目錄中。

    因應措施:請參閱 https://kb.vmware.com/s/article/54138

  • 問題 2022750:BOSH 虛擬機器冷移轉問題

    在 PKS、PAS、Openshift 或其他 Kubernetes 解決方案中,容器主機虛擬機器中新佈建的網繭或容器,在下列情況下將不會有網路連線:

    • 容器主機虛擬機器電源關閉且必須冷移轉時。
    • 在某些情況下,當容器主機虛擬機器正在開啟電源,且在開啟電源完成之前受限於 DRS (Distributed Resource Scheduler) 時。
    • 如果容器主機的 vNIC 中斷連結後再重新連結。

    因應措施:刪除容器主機。在 PKS 和 PAS 情況下,BOSH 將重新建立容器主機。

  • 問題 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

     

已知問題

已知問題分類如下。

一般已知問題
  • 問題 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。

  • 問題 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 使用者無法覆寫物件保護,且無法建立或刪除主體身分識別。

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

  • 問題 2030784:無法使用包含非 ASCII 字元的遠端使用者名稱登入 NSX Manager 。

    您無法以具有包含非 ASCII 字元之使用者名稱的遠端使用者身分登入 NSX Manager 應用裝置。

    因應措施:當您登入 NSX Manager 應用裝置時,遠端使用者名稱應具有 ASCII 字元。
    如果在 Active Directory 伺服器中已設定包含非 ASCII 字元的遠端使用者名稱,則可以使用非 ASCII 字元。

  • 問題 2111047:NSX-T 2.2 版中的 VMware vSphere 6.7 主機上不支援 Application Discovery

    在安全群組 (擁有 vSphere 6.7 主機上執行的虛擬機器) 上執行 Application Discovery 會導致探索工作階段失敗。

    因應措施:無

安裝已知問題
  • 問題 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 已完全移除,並重新啟動主機。

  • 問題 2106956:將屬於相同叢集的兩個 NSX Controller 加入兩個不同的 NSX Manager 會導致未定義的資料路徑問題

    將屬於相同 NSX Controller 叢集的兩個 NSX Controller 加入兩個不同的 NSX Manager 會導致未定義的資料路徑問題。

    因應措施:在 NSX Manager 上使用中斷連結 CLI 命令,以從 NSX Controller 叢集移除 NSX Controller。重新設定 NSX Controller 叢集,以便叢集中的所有 NSX Controller 均向同一個 NSX Manager 登錄。

    請參閱《NSX-T 安裝指南》中的〈NSX Controller 安裝和叢集〉一節。

  • 問題 2106973:初始化所有 NSX Controller 上的 NSX Controller 叢集會導致每個 NSX Controller 成為一個節點 NSX Controller 叢集,進而導致發生未定義的資料路徑連線問題

    避免初始化所有 NSX Controller 上的 NSX Controller 叢集,其會導致每個 NSX Controller 成為一個節點 NSX Controller 叢集,進而導致發生未定義的資料路徑連線問題。僅初始化第一個 NSX Controller 上的 NSX Controller 叢集,然後在第一個 NSX Controller 上透過執行 join control-cluster CLI 命令將其他 NSX Controller 加入叢集。

    因應措施:如《NSX-T 安裝指南》中的〈NSX Controller 安裝和叢集〉一節所述,重新設定 NSX Controller 叢集。

  • 問題 2114756:在某些情況下,從 NSX-T 備妥的叢集中移除主機時不會移除 VIB

    從 NSX-T 備妥的叢集中移除主機時,部分 VIB 可能會保留在主機上。

    因應措施:從主機手動解除安裝 VIB。

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。

  • 問題 2128476:具有超過 500 個主機、1000 個虛擬機器和 10000 個 VIF 之詳細目錄的規模設定,可能會在強制重新開機後花費大約 30 分鐘進行完整同步

    NSX Manager 重新開機後,每個主機將與 NSX Manager 同步,以便 NSX Manager 接收主機上最新的資料,其中包括主機上存在的虛擬機器和虛擬機器上存在的 VIF 的相關資訊。對於具有包含超過 500 個主機、1000 個虛擬機器和 10000 個 VIF 之詳細目錄的規模設定,完整同步需要大約 30 分鐘。

    因應措施:強制重新開機後,等待最新資訊顯示在 NSX Manager 中。

    使用 API api/v1/fabric/nodes/<nodeid>/status 檢查指示特定節點的最新同步時間的 last_sync_time 內容。

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

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

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

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

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

    因應措施:無。

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

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

    因應措施:  無。

  • 問題 2125725:還原大型拓撲部署後,搜尋資料變得不同步,且數個 NSX Manager 頁面無回應

    還原具有大型拓撲部署的 NSX Manager 後,搜尋資料變得不同步,且數個 NSX Manager 頁面會顯示錯誤訊息:發生無法復原的錯誤。

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

    1. 以管理員身分登入 NSX Manager CLI。
    2. 重新啟動搜尋服務。
      重新啟動服務搜尋
      當搜尋服務在背景中完成修正資料差異時,請等待至少 15 分鐘。
  • 問題 2128361:用於將 NSX Manager 的記錄層級設定為偵錯模式的 CLI 命令未正常運作

    使用 CLI 命令 set service manager logging-level debug 將 NSX Manager 的記錄層級設定為偵錯模式不會收集偵錯記錄資訊。

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

    1. 以管理員身分登入 NSX Manager CLI。
    2. 執行命令 st e 以切換為根使用者。
    3. 複製 log4j2.xml.default 和 log4j2.xml 檔案。
      cp /opt/vmware/proton-tomcat/conf/log4j2.xml.default /opt/vmware/proton-tomcat/conf/log4j2.xml
    4. 變更 log4j2.xml 檔案的擁有權。
      chown uproton:uproton /opt/vmware/proton-tomcat/conf/log4j2.xml
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 路由,而對流量流向造成影響。

    因應措施:無。

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

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

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

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

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

  • 問題 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 一次,讓計數器在較短的持續期間內重設及重新執行。

  • 問題 2075246:不支援將第 1 層邏輯路由器從一個第 0 層邏輯路由器移到另一個。

    將第 1 層邏輯路由器從一個第 0 層邏輯路由器移到另一個邏輯路由器會導致第 1 層邏輯路由器的下行連接埠路由連線中斷。

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

    1. 從第 0 層邏輯路由器中斷連結第 1 層邏輯路由器。
    2. 等待大約 20 分鐘,以便第 1 層邏輯路由器從第 0 層邏輯路由器完全中斷連結。
    3. 將第 1 層邏輯路由器連結至另一個第 0 層邏輯路由器。
      已還原下行連接埠路由連線。
  • 問題 2077145:在某些情況下,嘗試強制刪除傳輸節點可能會導致孤立傳輸節點

    使用 API 呼叫嘗試強制刪除傳輸節點造成問題,例如發生硬體故障且主機變得無法擷取、將傳輸節點狀態變更為孤立。

    因應措施:刪除具有孤立傳輸節點的網狀架構節點。

  • 問題 2099530:變更橋接器節點 VTEP IP 位址導致流量中斷

    當橋接器節點 VTEP IP 位址變更時,在遠端 Hypervisor 上未更新從 VLAN 至覆疊的 MAC 資料表,導致流量中斷長達 10 分鐘。

    因應措施:從 VLAN 起始流量變更,以便重新整理 Hypervisor 上的覆疊 MAC 資料表。
     

  • 問題 2106176:在安裝的「正在等待登錄」步驟期間,NSX Controller 自動安裝會停止

    使用 NSX Manager API 或 UI 執行 NSX Controller 自動安裝期間,其中一個進行中的 NSX Controller 的狀態會停止,且無限期顯示為正在等待登錄

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

    1. 傳送 API 要求以找出與停止的 NSX Controller 相關聯的虛擬機器識別碼。
      https://<nsx-mgr>/api/v1/cluster/nodes/deployments
    2. 傳送 API 要求以刪除停止的 NSX Controller。
      https://<nsx-mgr>/api/v1/cluster/nodes/deployments/<Controller id>?action=delete
  • 問題 2112459:取代橋接器叢集中的單一節點會造成流量捨棄

    當您取代橋接器叢集中的單一節點時,橋接的流量流向導致流量捨棄的舊節點,直到遠端 Hypervisor 中的轉送項目更新或過時為止。

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

    1. 將取代節點置於橋接器叢集中。
    2. 允許建立 HA。
    3. 移除舊節點。
  • 問題 216992:使用自訂邏輯連接埠 MTU 設定可能會導致封包捨棄

    使用邏輯連接埠上的自訂 MTU 設定時,例如邏輯路由器上行連接埠不合格值或第 0 層和第 1 層邏輯路由器的特定組態,可能會導致封包捨棄。預設 MTU 設定為 1500。

    因應措施:使用預設 MTU 設定。

    否則,不同邏輯連接埠上套用的 MTU 必須符合以下關聯性:

    1. 將第 0 層邏輯路由器上行 MTU 設定為 8900。
    2. 將 NSX Edge VTEP MTU 設定為 9000。
    3. 將虛擬機器 MTU 設定為 8900。 

    第 0 層邏輯路由器和連線至第 0 層邏輯路由器的所有第 1 層邏輯路由器必須共置於相同的 NSX Edge 節點上。

  • 問題 2125514:第 2 層橋接器容錯移轉後,某些 NSX Edge 虛擬機器上的邏輯交換器可能會對每個單一封包執行 BUM 複寫,直到重新學習 MAC

    第 2 層橋接器容錯移轉後,某些 NSX Edge 虛擬機器上的邏輯交換器可能會對每個單一封包執行 BUM 複寫將近 10 分鐘,直到為端點重新學習 MAC。端點產生下一個 ARP 後,系統復原本身。

    因應措施:無

  • 問題 2113769:在 NSX Edge VLAN 第 2 層橋接上不支援 DHCP 轉送

    透過 NSX Edge 上的第 2 層橋接連接埠將 VLAN 主機連線至邏輯交換器 VNI,導致邏輯路由器連接埠上的 DHCP 轉送代理程式不提供 IP 位址給 VLAN 主機。

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

    1. 手動設定 VLAN 主機。
    2. 將第 2 層橋接連接埠移至 ESXi 主機。
安全服務已知問題
  • 問題 1680128:用戶端與伺服器之間的 DHCP 通訊未加密

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

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

    因應措施:無。

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

    因應措施:完成下列步驟:
    如果 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

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

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

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

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,請進行相同的指令碼修改,然後重新啟動主機的網路功能。
     

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

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

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

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

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

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

  • 問題 2115545:啟用負載平衡器健全狀況檢查後,直接連線至後端伺服器集區成員可能會失敗

    當負載平衡器已連結至邏輯路由器時,若集區成員使用邏輯路由器的上行進行連線,則連線至邏輯路由器下行的用戶端無法使用與健全狀況檢查相同的通訊協定存取集區成員。

    例如,如果負載平衡器已連結至邏輯路由器 LR1 且已針對透過 LR1 上行連線的集區成員啟用 ICMP 健全狀況檢查,則 LR1 下行上的用戶端無法直接對這些集區成員執行 Ping 動作。但是,同一用戶端可以使用其他通訊協定 (例如 SSH 或 HTTP) 與伺服器進行通訊。
     

    因應措施:在負載平衡器上使用不同的健全狀況檢查類型。例如,為了能夠對後端伺服器執行 Ping 動作,可以使用 TCP 或 UDP 健全狀況檢查,而不是 ICMP 健全狀況檢查。

  • 問題 2128560:設定負載平衡器 SNAT 自動對應和健全狀況檢查可能會偶爾導致健全狀況檢查或連線失敗

    為同一個伺服器集區設定負載平衡器 SNAT 自動對應和健全狀況檢查 (例如 TCP、HTTP、HTTPS 或 UDP),可能會偶爾導致健全狀況檢查或連線至該伺服器集區失敗。

    因應措施:使用 SNAT IP 清單,而不是 SNAT 自動對應。

    附註:在 SNAT IP 清單模式下指定的 SNAT IP 位址不應包括邏輯路由器上行 IP 位址。

    例如,如果負載平衡器連結至第 1 層邏輯路由器 LR1,則設定的 SNAT IP 範圍不應包括 LR1 上行 IP 位址。

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

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

作業和監控服務已知問題
  • 問題 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

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

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

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

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

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

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

  • 問題 2101728:有時,NSX Edge 升級程序會在成功升級 NSX Edge 群組後暫停

    NSX Edge 群組升級成功,但是,在第二個 NSX Edge 群組升級期間程序暫停。

    因應措施:按一下繼續以繼續進行 NSX Edge 群組升級。

  • 問題 2106257:從 NSX-T 2.1 升級至 NSX-T 2.2 的使用者授權合約 API 接受工作流程變更

    更新升級協調器後和升級現有主機之前,應呼叫接受使用者授權合約 API。

    因應措施:無

  • 問題 2108649:如果在將要執行升級的磁碟分割中有檔案或目錄開啟,升級會失敗

    避免將要升級之磁碟分割中的檔案或目錄保持開啟,例如 NSX Manager 或 NSX Controller,這會導致升級程序失敗。

    因應措施:重新開機發生失敗的應用裝置並重新啟動升級程序。

  • 問題 2116020:從 NSX-T 2.1 升級至 NSX-T 2.2 後,不會移除某些 Ubuntu KVM 已過時的套件

    從 NSX-T 2.1 升級至 NSX-T 2.2 後,不會移除下列 Ubuntu KVM 已過時的套件。

    • nsx-host-node-status-reporter
    • nsx-lldp
    • nsx-logical-exporter
    • nsx-netcpa
    • nsx-support-bundle-client
    • nsx-transport-node-status-reporter
    • nsxa

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

    1. 在 /etc/vmware/nsxa/ 目錄中建立暫存檔。
      cd /etc/vmware/nsxa
      touch temp.txt
    2. 列出所有 nsxa 套件目錄和檔案。
      dpkg -L nsxa
      /etc/vmware/nsxa# ls
    3. 移除下列套件。
      a) dpkg --purge nsx-lldp
      b) dpkg --purge nsx-support-bundle-client
      c) dpkg --purge nsx-transport-node-status-reporter
      d) dpkg --purge nsx-logical-exporter
      e) dpkg --purge nsx-netcpa
      f) dpkg --purge nsxa
      g) dpkg --purge nsx-host-node-status-reporter
    4. 確認下列目錄可用。
      /etc/vmware/nsxa/
    5. 從 /etc/vmware/nsxa/ 目錄移除 temp.txt 檔案。
      rm -f temp.txt
API 已知問題
  • 問題 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 服務所使用。

    因應措施:無。

  • 問題 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 要求。

NSX Policy Manager
  • 問題 2057616:將 NSX Policy Manager 從 NSX-T 2.1 升級至 NSX-T 2.2 期間,不支援的 NSService 和 NSGroup 不會傳輸

    將 NSX Policy Manager 從 NSX-T 2.1 升級至 NSX-T 2.2 期間,不支援的具有乙太類型的 NSService 與具有 MAC 集合和邏輯連接埠成員資格準則的 NSGroup 不會進行傳輸。

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

    1. 在 NSX-T 2.1 中,移除並修改任何通訊項目中使用的具有乙太類型的 NSService。
    2. 移除並修改任何通訊項目中使用的具有 MAC 集合和邏輯連接埠成員資格準則的 NSGroup。
    3. 將 NSX Manager 從 NSX-T 2.1 升級至 NSX-T 2.2。
    4. 使用 CLI 升級 NSX Policy Manager。
  • 問題 2116117:UI 中的 NSX Policy Manager 拓撲索引標籤會顯示資料連線失敗

    UI 中的 NSX Policy Manager 拓撲索引標籤會顯示資料連線失敗,因為原則網域中的群組包含不支援的 ESXi 6.7 版本上主控的虛擬機器。

    因應措施:無

  • 問題 2126647:並行更新至 NSX Policy Manager 分散式防火牆導致覆寫

    當兩個使用者同時編輯 NSX Policy Manager 分散式防火牆區段時,最後一個使用者所做的變更會覆寫之前其他使用者所做的編輯。
     

    因應措施:恢復第一個使用者所做的分散式防火牆變更。儲存變更後,第二個使用者可以進行變更。

NSX Cloud
  • 問題 2112947:在 Cloud Service Manager (CSM) 中升級 NSX 代理程式時,部分執行個體可能會顯示為失敗

    在 CSM 中升級 NSX 代理程式時,部分執行個體可能因使用者介面無回應而顯示為失敗。

    因應措施:重新整理使用者介面。

  • 問題 2111262:部署 PCG 時,您可能會看到錯誤:「閘道部署失敗: [錯誤碼: 60609] 非同步作業失敗,且佈建狀態為: 失敗。」或者「無法建立名為 nsx-gw 的閘道虛擬機器,閘道部署失敗。」

    這是罕見事件,該事件由 Microsoft Azure 基礎結構導致。 

    因應措施:  重新部署失敗的公用雲端閘道 (PCG)。

  • 問題 2110728:如果客戶透過使用 --gateway 選項僅指定單一 PCG 的 DNS 名稱以在虛擬機器上安裝代理程式,容錯移轉至次要 PCG 不會生效。

    容錯移轉後工作負載虛擬機器無法連線至 PCG,因此 PCG 無法強制執行/實現虛擬機器上的任何邏輯狀態。

    建議:在工作負載虛擬機器上安裝代理程式時,從不使用 --gateway 選項。

  • 問題 2071374:在具有特定 Linux 散發 (例如 Ubuntu 14.04、Ubuntu 16.04) 的虛擬機器上安裝 NSX 代理程式時,出現錯誤訊息字串

    在正在執行「nscd」的虛擬機器上安裝 NSX 代理程式時,您會看到類似以下內容的錯誤訊息:「sent invalidate(passwd) request, exiting」。

    因應措施:由於 Linux 散發的已知錯誤,導致這些訊息出現。這些訊息是無害的,且不會影響 NSX 代理程式安裝。

  • 問題 2010739:兩個公用雲端閘道 (PCG) 均顯示為待命

    如果主要 PCG 無法在閘道上線期間連線至控制器,則這兩個閘道 (主要和次要) 將處於待命模式,直到控制器與閘道之間的連線還原。  

  • 問題 2121686:CSM 顯示例外狀況「伺服器無法驗證要求」。

    您可能會在 CSM 中看到這個錯誤,原因是 CSM 應用裝置時間與 Microsoft Azure 儲存伺服器或 NTP 不同步。在此情況下,Microsoft Azure 擲回例外狀況「伺服器無法驗證要求」,它是不明確的,但 CSM 中會顯示相同的錯誤。 

    因應措施:同步 CSM 應用裝置時間與 NTP 或 Microsoft Azure 儲存伺服器時間。

  • 問題 2092378:在 HA 模式下部署 PCG 時會顯示處於待命模式的兩個 PCG,雲端同步會顯示主要 PCG 處於作用中狀態

    在私人網路中透過 CSM 在 HA 模式下部署 PCG 之後,會在已部署的 PCG 上看到待命/待命或主動/主動狀態達 1 小時。在此間隔期間,似乎使用者有一些 PCG 部署問題,並且可能處於不明狀態而無法繼續。

    因應措施:執行下列操作: 

    1. 部署 PCG 後從 UI 重新同步帳戶,透過此作業,CSM 可擷取最新的資料,並顯示在 CSM 中。
    2. 如果重新同步後,CSM 仍顯示 PCG 處於錯誤狀態,請檢查 NSX Manager 中 PCG 的連線狀態。 
    3. 如果連線顯示為「啟動」,而狀態仍不正確,請繼續偵錯 PCG。
  • 問題 2119726:  在 Microsoft Azure VNet 中部署 PCG 時,先前與虛擬機器相關聯的公用 IP 可能會錯誤地列為隨意使用。

    如果先前指派了公用 IP 的虛擬機器現在已關閉電源,這些公用 IP 將不再與其相關聯。這是因為虛擬機器關閉電源一段時間後,Microsoft Azure 會將與其相關聯的公用 IP 解除關聯。Microsoft Azure 未明確定義這段時間。 

    因應措施:請勿在您的 VNet 中關閉 PCG 的電源。這會阻止公用 IP 與主要 PCG 的上行介面解除關聯。如果您必須關閉 PCG 的電源,請確保不會重複使用與 PCG 相關聯的公用 IP,且在 PCG 重新開啟電源後,它們會立即取得相同的公用 IP。 

  • NSX 支援含 kmod.x86_64 0:20 15.el7_4.6 的 Red Hat Enterprise Linux 7.4

    NSX 不支援執行含 kmod.x86_64 0:20-15.el7_4.6 之 Red Hat Enterprise Linux 7.4 的虛擬機器執行個體。此問題由 Red Hat 報告的錯誤所致:https://bugzilla.redhat.com/show_bug.cgi?id=1522994。 

    因應措施:更新至已修正此錯誤的 kmod 版本,以便成功安裝 NSX 代理程式。

  • 不支援在 NSX Cloud 中取得防火牆規則的已實現狀態

    使用 NSX-T Manager API 取得虛擬機器執行個體上 DFW 防火牆規則的已實現狀態

    /api/v1/firewall/rules/<rule-id>/state

    在此版本中不完全受支援

    目前沒有因應措施

  • 問題 2066636:從已啟用隔離原則的 VNET 取消部署 PCG 時,上次 PCG 取消部署將停滯。

    上次 PCG 部署停滯。如果輪詢 CSM API 來檢查閘道狀態,它會顯示停滯在刪除資源群組階段的 PCG。在 Microsoft Azure 入口網站中,您會看到存在的 PCG 資源群組中的一些安全群組,而資源群組本身標示為待刪除。

    因應措施: 

    • 停用將離線之 VNet 的隔離模式。
    • 將虛擬機器移到使用者建立的安全群組。
    • 觸發取消部署上次 PCG。
NSX Container Plug-in (NCP) 已知問題
  • PAS 2.1.0 CNI 變更

    由於 PAS 2.1.0 中的 CNI 外掛程式發生變更,NSX-T 動態磚 2.1.x 和 2.2.x 均無法與 PAS 2.1.0 搭配使用。在 PAS 2.1.1 中已修正此問題。

  • 問題 2118515:在大規模設定中,NCP 需要花很長時間,在 NSX-T 中建立防火牆

    在大規模設定 (例如,250 個 Kubernetes 節點、5000 個網繭、2500 個網路原則) 中,NCP 可能需要花幾分鐘時間,在 NSX-T 中建立防火牆區段和規則。

    因應措施:無。建立防火牆區段和規則後,效能應會恢復正常。

  • 問題 2127607:從 Kubernetes 入口移除 TLS 規格後,預設集區不會移至 HTTP 虛擬伺服器

    Kubernetes 入口已設定 TLS 和預設後端。移除 TLS 規格後,規則會從 HTTPS 虛擬伺服器傳輸到 HTTP 虛擬伺服器,但後端服務的預設集區會保留在 HTTPS 虛擬伺服器中。

    因應措施:刪除 Kubernetes 入口,重新啟動 NCP,並重新建立 Kubernetes 入口。

  • 問題 2125755:執行 Canary 更新和階段式輪流更新時,StatefullSet 可能會中斷網路連線

    如果在 NCP 升級至目前版本之前已建立 StatefulSet,StatefullSet 可能會在執行 Canary 更新和階段式輪流更新時中斷網路連線。

    因應措施:在 NCP 升級至目前版本後建立 StatefulSet。

  • 問題 2131494:將入口類別從 nginx 變更為 nsx 之後,NGINX Kubernetes 入口仍然正常運作

    當您建立 NGINX Kubernetes 入口時,NGINX 會建立流量轉送規則。如果將入口類別變更為任何其他值,即使您在變更類別後刪除 Kubernetes 入口,NGINX 也不會刪除規則,並且會繼續套用這些規則。這是 NGINX 的限制。

    因應措施:若要刪除 NGINX 所建立的規則,請在類別值為 nginx 時刪除 Kubernetes 入口。然後,重新建立 Kubernetes 入口。

  • 問題 2193714:說明文件中有關重新寫入註解的錯誤

    在《適用於 Kubernetes 和 Cloud Foundry 的 NSX-T Container Plug-in - 安裝和管理指南》中,說明如何指定重新寫入註解的範例 (https://docs.vmware.com/tw/VMware-NSX-T/2.2/com.vmware.nsxt.ncp_kubernetes.doc/GUID-FF86F9C2-E70D-418B-AFDB-B3CF8DE106C2.html) 包含以下行:

       ncp/rewrite_target: "/"

    此行不正確。正確的註解應是:

       ingress.kubernetes.io/rewrite-target: /

  • 對於類型為 ClusterIP 的 Kubernetes 服務,不支援以用戶端 IP 為基礎的工作階段相似性

    對於類型為 ClusterIP 的 Kubernetes 服務,NCP 不支援以用戶端 IP 為基礎的工作階段相似性。

    因應措施:無

  • 對於類型為 ClusterIP 的 Kubernetes 服務,不支援 hairpin-mode 旗標

    對於類型為 ClusterIP 的 Kubernetes 服務,NCP 不支援 hairpin-mode 旗標。

    因應措施:無

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

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