VMware NSX-T Data Center 2.4.2 | 2019 年 8 月 8 日 | 組建編號 14269501

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

版本說明的內容

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

相容性和系統需求

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

API 和 CLI 資源

請參閱 code.vmware.com 以使用 NSX-T Data Center API 或 CLI 進行自動化。

API 說明文件可從 API 參考索引標籤取得。CLI 說明文件可從說明文件索引標籤取得。

文件修訂歷程記錄

2019 年 8 月 8 日。第一版。
2019 年 8 月 23 日。第二版。已新增已知問題 2362688 和 2395334。
2019 年 11 月 12 日。第三版。已移除問題 2295470 (在 2.4.1 中已修正)。

已解決的問題

  • 已修正的問題 2387470 - 擷取 ALG 資訊時,主機上可能會觸發核心傾印 (PSOD)。

    為 NSX-T 準備的 ESXi 主機在為 ALG 流量提供服務時,於執行 CLI 命令「vsipioctl getalginfo -f」時,可能會遇到核心傾印 (PSOD)。

  • 已修正的問題 2391093 - 在將所有 pNIC 移轉至 N-VDS 時,NSX-T 主機可能會失去管理網路連線。

    此問題是因為主機移轉重試移除已設定 vmk0 之 N-VDS 中的所有 pNIC。第一個主機移轉已將所有 pNIC 和 vmk0 移轉至 N-VDS,但之後便失敗。重試移轉時,會將所有 pNIC 從 N-VDS 移除。因此,使用者無法透過網路存取主機;主機中的所有虛擬機器也會失去網路連線,使得其服務呈現為無法連線。

  • 已修正的問題 2392093 - 在 T0 上設定 SNAT 和 DNAT 時,由於 RPF 檢查導致流量遭捨棄。

    已設定 SNAT 和 DNAT 時,如果流量透過 T0 下行 Hairpin,而第 0 層和第 1 層路由器位於相同的 Edge 節點上,則 RPF 檢查可能會導致流量遭捨棄。

  • 已修正的問題 2392201 - 由於 CBM 程序記憶體膨脹,CBM 程序重複損毀。

    Cloud Service Manager 應用裝置上的 CSM 和 CBM 程序在資料庫壓縮時失敗。因此,CBM 程序記憶體膨脹導致 CBM 程序重複損毀。

  • 已修正的問題 2382619 - VMware Identity Manager 使用者無法存取 NSX Manager 儀表板中的原則頁面。

    角色獲指派 VMware Identity Manager 中群組權限的使用者無法存取 NSX Manager 儀表板中的原則頁面。會忽略來自群組指派的權限。

  • 已修正的問題 2382620 - NSX Edge 應用裝置遇到記憶體損毀,導致程序損毀/重新啟動。

    在大規模組態期間,嘗試擷取路由器組態會導致出現錯誤訊息,包括:「發生未預期的錯誤:數據平面服務已失敗或已停用」。在很長的一段時間,Edge 資料層程序當機 - 重新啟動/核心傾印。每次執行規則查閱時,都會偵測到記憶體流失。  清除流程快取時,不會移除 VIF 介面,導致記憶體堆積。

  • 已修正的問題 2382628 - 為 ALG 流量提供服務時,ESXi 主機可能會 PSOD。

    在執行流量數天之後,ESXi 損毀 (PSOD)。在發生毀損之前,未觀察到其他症狀。此問題最終在 ALG 流量 (FTP、Sunrpc、Oracle、Dcerpc、TFTP) 中發現,其中 nonatomic 化的增量計數器會導致競爭條件,損毀 ALG 樹狀結構。

  • 已修正的問題 2387486 - NSX-T Edge 上的 BGPD 程序 (當它有數個 VTYSH 工作階段時) 可能會耗用 100% 的 CPU。

    NSX-T Edge 上的 BGPD 程序 (當它有使用 VTYSH 開啟的數個工作階段時) 可能會耗用 100% 的 CPU。除非 BGP 重新啟動,否則將繼續耗用 100% 的 CPU,並且可能導致大規模的問題。

  • 已修正的問題 2392089 - 已略過透過「連結」連接埠流量的 NAT 規則。

    在連接第 0 層和第 1 層邏輯路由器的「連結」路由器連接埠類型上不會啟用 NAT 服務。

  • 已修正的問題 2382625 - 重新組態後負載平衡器記憶體流失。

    NSX 負載平衡器可能會在連續/重複的組態事件時流失記憶體,導致 nginx 程序核心傾印。

已知問題

已知問題分類如下。

一般已知問題
  • 問題 2389109 - 如果 Edge 主機名稱以數字開頭,則 BGP/路由無法在 T0-SR 上運作。

    如果 Edge 主機名稱以數字開頭,並且未將組態推送至路由堆疊,則 BGP/路由無法在 T0-SR 上運作。此為已知限制。

    因應措施:使用 CLI 來變更主機名稱,使得數字不再是主機名稱中的第一位數。在 Edge 節點上啟用並停用維護模式,以讓變更生效。

  • 問題 2239365:擲回「未經授權」錯誤

    由於使用者嘗試在同一瀏覽器類型上開啟多個驗證工作階段,可能會導致此錯誤。如此一來,登入將會失敗並顯示上述錯誤,且無法進行驗證。記錄位置:/var/log/proxy/reverse-proxy.log /var/log/syslog

    因應措施:關閉所有開啟的驗證視窗/索引標籤,然後重試驗證。

  • 問題 2252487:同時新增多個 TN 時,不會針對 BM Edge 傳輸節點儲存傳輸節點狀態

    傳輸節點狀態在 MP 使用者介面中未正確顯示。

    因應措施:

    1. 將 proton 重新開機,可以正確更新所有傳輸節點狀態。
    2. 或者,使用 API https://<nsx-manager>/api/v1/transport-nodes/<node-id>/status?source=realtime 查詢傳輸節點狀態。
  • 問題 2256709:在執行 vMotion 期間,即時複製虛擬機器或從快照還原的虛擬機器會暫時失去 AV 保護

    還原虛擬機器的快照,並將虛擬機器移轉到另一台主機。合作夥伴主控台沒有針對已移轉的即時複製虛擬機器顯示 AV 保護。已暫時失去 AV 保護。

    因應措施:無。

  • 問題 2261431:根據其他部署參數,需要篩選過的資料存放區清單

    如果選取了不正確的選項,使用者介面上會顯示相應的錯誤。客戶可以刪除此部署並建立新部署,以從錯誤中復原。

    因應措施:如果您要建立叢集部署,請選取共用資料存放區。

  • 問題 2274988:服務鏈結不支援來自同一服務的連續服務設定檔

    流量不會周遊服務鏈結,只要鏈結具有屬於同一服務的兩個連續服務設定檔,它就會遭到捨棄。

    因應措施:從不同的服務中新增服務設定檔,以確保沒有兩個連續服務設定檔屬於同一服務。或者,定義第三個服務設定檔,此設定檔將針對兩個串連的原始設定檔執行相同的作業,然後在服務鏈結中單獨使用第三個設定檔。

  • 問題 2275285:在第一個要求完成且叢集穩定之前,節點提出加入同一叢集的第二個要求

     叢集無法正常運作,並且 CLI 命令 get cluster status、get cluster config 可能會傳回錯誤。

    因應措施:在第一個加入要求後,請勿在 10 分鐘內發出任何新的加入命令以加入同一叢集。

  • 問題 2275388:在新增篩選器以拒絕路由之前,回送介面/已連線介面路由會進行重新分配

    不必要的路由更新可能會導致流量轉移持續幾秒到幾分鐘的時間。

    因應措施:無。

  • 問題 2275708:如果憑證的私密金鑰具有複雜密碼,無法使用此私密金鑰匯入憑證

    傳回的訊息為「針對憑證收到無效的 PEM 資料。(錯誤碼: 2002)」。無法使用私密金鑰匯入新憑證。

    因應措施: 

    1. 使用私密金鑰建立憑證。當系統提示時,請勿輸入新的複雜密碼;而是按 Enter。
    2. 選取 [匯入憑證],然後選取憑證檔案和私密金鑰檔案。

    透過開啟金鑰檔案進行驗證。如果在產生金鑰時輸入了複雜密碼,檔案中的第二行會顯示類似「Proc-Type: 4,ENCRYPTED」的內容。

    如果在產生金鑰檔案時沒有使用複雜密碼,則這一行會遺失。

  • 問題 2277742:如果 NSX-T Manager 應用裝置已設定完整網域名稱 (FQDN) 而不僅僅是主機名稱,則使用將 publish_fqdns 設定為 true 的要求本文叫用 PUT https://<MGR_IP>/api/v1/configs/management 可能會失敗

    如果已設定 FQDN,則無法叫用 PUT https://<MGR_IP>/api/v1/configs/management。

    因應措施:使用主機名稱而非 FQDN 來部署 NSX Manager。

  • 問題 2279249:在執行 vMotion 期間,即時複製虛擬機器失去 AV 保護

    即時複製虛擬機器已從一台主機移轉到另一台主機。在移轉之後,eicar 檔案隨即遺留在虛擬機器上。暫時失去 AV 保護。

    因應措施:無。

  • 問題 2292116:透過 IPFIX L2 頁面建立群組時,套用至以 CIDR 為基礎的 IP 位址群組的 IPFIX L2 未在使用者介面上列出

    如果嘗試從 [套用至] 對話方塊建立一組 IP 位址,並且在 [設定成員] 對話方塊中輸入錯誤的 IP 位址或 CIDR,則這些成員不會列在群組下。您必須再次編輯該群組以輸入有效的 IP 位址。

    因應措施:移至群組清單頁面,並在該群組中新增 IP 位址。接著,該群組會開始填入 [套用至] 對話方塊中。

  • 問題 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) 的效果。

    因應措施:無。

  • 問題 2268406 - 在新增的標籤達到數目上限時,[標籤錨點] 對話方塊不會顯示所有標籤。

    在新增的標籤達到數目上限時,[標籤錨點] 對話方塊不會顯示所有標籤,且無法調整大小或捲動。不過,使用者仍可在 [摘要] 頁面中檢視所有標籤。不會遺失任何資料。

    因應措施:改在 [摘要] 頁面中檢視標籤。

  • 問題 2310650 - 介面會顯示「要求逾時」錯誤訊息。

    介面上有多個頁面會顯示下列訊息:「要求逾時。系統處於高負載或資源不足時,就可能會發生此狀況」

    因應措施:使用 SSH 登入 NSX Manager 虛擬機器,並執行「開始搜尋重新同步管理員」CLI 命令。

  • 問題 2320529 - 為新增的資料存放區新增第三方虛擬機器後,擲回「用於服務部署的儲存區無法存取」錯誤。

    為新增的資料存放區新增第三方虛擬機器後,會擲回「用於服務部署的儲存區無法存取」錯誤,即使可從叢集中的所有主機存取儲存區,仍是如此。此錯誤狀態最多會持續 30 分鐘。

    因應措施:在 30 分鐘後重試。或者,進行下列 API 呼叫以更新資料存放區的快取項目:
    https://{{NsxMgrIP}}/api/v1/fabric/compute-collections/<CC Ext ID>/storage-resources?uniform_cluster_access=true&source=realtime
    其中,NsxMgrIP 是服務部署 API 失敗之 NSX Manager 的 IP 位址,而 CC Ext ID 是嘗試部署的叢集在 NSX 中的識別碼。

  • 問題 2320855 - 如果使用者未按一下 [新增/檢查] 按鈕,則不會建立新的虛擬機器安全性標籤。

    介面問題。如果使用者將新的安全性標籤新增至原則物件或詳細目錄,沒有先按一下標籤/範圍配對欄位旁的新增/檢查按鈕即直接按儲存,則不會建立新的標籤配對。

    因應措施:請務必先按一下新增/檢查按鈕,再按儲存

  • 問題 2328126 - 祼機問題:Linux 作業系統繫結介面使用於 NSX 上行設定檔中時會傳回錯誤。

    如果您在 Linux 作業系統中建立繫結介面,並在 NSX 上行設定檔中使用此介面,您會看到下列錯誤訊息:「傳輸節點建立可能失敗。」之所以發生此問題,是因為 VMware 不支援 Linux 作業系統繫結。不過,VMware 支援祼機伺服器傳輸節點的 Open vSwitch (OVS) 繫結。

    因應措施:如果您遇到此問題,請參閱知識庫文章 67835:Bare Metal Server supports OVS bonding for Transport Node configuration in NSX-T (祼機伺服器在 NSX-T 中支援傳輸節點組態的 OVS 繫結)

  • 問題 2334442:在管理員使用者重新命名之後,使用者沒有編輯或刪除所建立物件的權限。

    在管理員使用者重新命名之後,使用者沒有編輯或刪除所建立物件的權限。無法重新命名管理員/稽核員使用者。

    因應措施:在重新命名之後發出命令「服務 nsx-policy-manager 重新啟動」來重新啟動原則

  • 問題 2261818:從 eBGP 芳鄰學習的路由會通告回到相同的芳鄰

    啟用 BGP 偵錯記錄會指出正在重新接收的封包以及遭到捨棄的封包,並且顯示錯誤訊息。BGP 程序在捨棄傳送給對等的更新訊息時會耗用額外的 CPU 資源。如果存在大量的路由和對等,這會影響路由聚合。

    因應措施:無。

  • 問題 2390624 - 當主機處於維護模式時,反相似性規則會防止服務虛擬機器利用 vMotion。

    如果服務虛擬機器部署在具有正好兩個主機的叢集中,則具有反相似性規則的 HA 配對將會在任何維護模式工作期間防止虛擬機器利用 vMotion 移至其他主機。這可能導致主機無法自動進入維護模式。

    因應措施:先將主機上的服務虛擬機器關閉電源,再於 vCenter 上開始維護模式工作。

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

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

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

NSX Manager 已知問題
  • 問題 2282798 - 在同一時間有數量過多的要求/主機嘗試登錄至 NSX Manager 時,主機登錄可能會失敗。

    此問題會導致網狀架構節點處於「失敗」狀態。網狀架構節點狀態 API 呼叫會顯示「用戶端尚未回應活動訊號」。主機上的 /etc/vmware/nsx-mpa/mpaconfig.json 檔案也是空的。

    因應措施:使用下列程序來修正此問題。

    1. 使用 [解析程式] 選項。
    2. 從 NSX 中刪除 FN。
    3. 透過 CLI 命令「加入管理平面」以手動方式重新新增 FN。
NSX Edge 已知問題
  • 問題 2283559:如果 Edge 具有 RIB 的 65k+ 個路由以及 FIB 的 100k+ 個路由,/routing-table 和 /forwarding-table MP API 會傳回錯誤

    如果 Edge 具有 65k+ 個路由用於 RIB 以及 100k+ 個路由用於 FIB,則從 MP 到 Edge 的申請需要超過 10 秒並導致逾時。這是一個唯讀 API,只有當他們需要使用 API/使用者介面下載 RIB 的 65k+ 個路由以及 FIB 的 100k+ 個路由時才會產生影響。

    因應措施:有兩個選項可供擷取 RIB/FIB。

    • 這些 API 支援根據網路首碼或路由類型篩選選項。請使用這些選項來下載所需路由。
    • CLI 支援,以防需要整個 RIB/FIB 資料表並且沒有逾時。
  • 問題 2204932 - 設定 BGP 對等可能會延遲 HA 容錯移轉復原。

    如果與 T0 Edge 對等的路由器上設定了「動態 BGP 對等」時,當 Edge 上發生容錯移轉事件 (主動備用模式) 時,BGP 芳鄰設定可能需要 120 秒。

    因應措施:設定特定的 BGP 對等以防止延遲。

  • 問題 2285650 - BGP 路由表填入不必要的路由。

    如果在 BGP 組態中啟用了 Allowas-in 選項,則會重新接收 Edge 節點所通告的路由,並安裝在 BGP 路由表中。這會導致過多的記憶體耗用和路由計算處理。如果為過多的路由設定了較高的本機喜好設定,此轉送迴圈可能會導致部分路由器的路由表中填入冗餘的路由。

    例如,假設路由 X 來自路由器 D,而會通告至路由器 A 和路由器 B。已啟用 Allowas-in 的路由器 C 與 B 對等,因此會學習路由 X,並將其安裝在路由表中。如此一來,此時路由 X 會有兩個通告至路由器 C 的路徑,因而產生問題。

    因應措施:您可以將有問題的路由器 (或其對等) 設定為封鎖通告回來的路由,以防止轉送迴圈。

邏輯網路已知問題
  • 問題 2243415:客戶無法使用邏輯交換器 (做為管理網路) 來部署 EPP 服務

    在 EPP 部署畫面上,使用者無法在網路選擇控制項中查看邏輯交換器。如果 API 直接與提及做為管理網路的邏輯交換器搭配使用,則使用者會看到下列錯誤:「用於服務部署的指定網路無法存取」。

    因應措施:使用本機交換器或分散式交換器等其他類型的交換器進行部署。

  • 問題 2288774:由於標籤數超過 30 個 (錯誤地),區段連接埠出現實現錯誤

    使用者輸入錯誤地嘗試套用 30 個以上的標籤。但是,原則工作流程未正確驗證/拒絕使用者輸入並允許設定。然後,此原則會顯示警示以及相應的錯誤訊息,指示使用者不應使用 30 個以上的標籤。此時,使用者可以更正此問題。

    因應措施:出現錯誤之後,更正組態。

  • 問題 2275412:連接埠連線無法在多個 TZ 中運作

    連接埠連線只能用於單一 TZ。

    因應措施:無。

  • 問題 2320147 - 受影響的主機上遺失 VTEP。

    如果在移除 LogSwitchStateMsg 後將其新增於相同的交易中,且在管理平面傳送邏輯交換器之前,中央控制平面即處理這項作業,則邏輯交換器狀態將不會更新。因此,遺失的 VTEP 將無法輸入或輸出流量。

    因應措施:如果您遇到此問題,請重新啟動中央控制平面。

  • 問題 2327904 - 使用預先建立的 Linux 繫結介面作為上行後,流量變得不穩定或失敗。

    NSX-T 不支援以預先建立的 Linux 繫結介面作為上行。

    因應措施:對於上行,請使用上行設定檔中的 OVS 原生繫結組態。

  • 問題 2295819 - 即使 Edge 虛擬機器處於作用中狀態且 PNIC 已啟動,L2 橋接器仍停滯於「已停止」狀態。

    即使 Edge 虛擬機器處於作用中狀態,且支援 L2 橋接器連接埠的 PNIC 已啟動,L2 橋接器仍可能停滯於「已停止」狀態。這是因為 Edge LCP 無法在其本機快取中更新 PNIC 狀態,因而假設 PNIC 已關閉。
     
     *對客戶的影響*:
    Edge l2bridge 連接埠可連線的虛擬機器會出現流量中斷的狀況

    因應措施:在受影響的 Edge 虛擬機器上重新啟動本機控制代理程式。

  • 問題 2389993 - 使用原則頁面或 API 修改重新分配規則後移除了路由對應。

    從管理平面介面或 API 新增至重新分配規則的路由對應,如果後續透過原則頁面或 API 修改相同的重新分配規則,則可能會移除該路由對應。這是由於原則頁面或 API 不支援新增路由對應。這可能會導致向 BGP 對等通告不需要的首碼。

    因應措施:您可以透過回到管理平面介面或 API 來還原路由對應,以將其重新新增至相同的規則。如果您想要在重新分配規則中包含路由對應,建議您一律使用管理平面介面或 API 來建立和修改該路由對應。

安全服務已知問題
  • 問題 2395334 - (Windows) 封包因無狀態防火牆規則 conntrack 項目而誤遭捨棄。

    Windows 虛擬機器上的無狀態防火牆規則未受到妥善支援。

    因應措施:改為新增可設定狀態的防火牆規則。

  • 問題 2296430 - 憑證產生期間,NSX-T Manager API 不提供主體替代名稱。

    NSX-T Manager API 不會提供主體替代名稱以核發憑證,特別是 CSR 產生期間。

    因應措施:使用支援延伸的外部工具建立 CSR。收到憑證授權機構的已簽署憑證後,使用 CSR 的金鑰將其匯入 NSX-T Manager。

  • 問題 2294410 - L7 防火牆會偵測某些應用程式識別碼。

    系統會根據連接埠 (而非應用程式) 偵測下列 L7 應用程式識別碼:SAP、SUNRPC 和 SVN。下列 L7 應用程式識別碼不受支援:AD_BKUP、SKIP 和 AD_NSP。

    因應措施:無。客戶不受任何影響。

  • 問題 2314537 - vCenter 憑證和指紋更新後,連線狀態為關閉。

    不會再透過 NSX 與 vCenter 的同步進行任何更新,且從 vCenter 擷取資料的所有隨選查詢都將失敗。使用者無法部署新的 Edge/服務虛擬機器。使用者無法準備在 vCenter 中新增的新叢集或主機。記錄位置:NSX Manager 節點上的 /var/log/cm-inventory/cm-inventory.log 和 /var/log/proton/nsxapi.log。

    因應措施:登入每個 NSX Manager 虛擬機器,並切換為根使用者。在每個 Manager 節點上執行「/etc/init.d/cm-inventory restart」命令。

負載平衡器已知問題
  • 問題 2290899:IPSec VPN 無法運作,IPSec 的控制平面實現失敗

    如果在同一 Edge 節點上的 Tier-0 上啟用了超過 62 個 LbServer 以及 IPSec 服務,則 IPSec VPN (或 L2VPN) 無法啟動。

    因應措施:將 LbServer 數目減少至少於 62 個。

  • 問題 2318525 - IPv6 路由若以 eBGP 對等的 IP 位址作為下一個躍點,將會變更其本身的 IP。

    在 eBGP IP4 工作階段的案例中,通告的 IPv4 路由若以其 eBGP 對等作為下一個躍點,則路由的下一個躍點在傳送端將「不」會變更為其本身的 IP 位址。這適用於 IPv4,但在 IPv6 工作階段中,路由的下一個躍點在傳送端會變更為其本身的 IP 位址。此行為可能會導致路由迴圈。

    因應措施:無。

  • 問題 2362688:當負載平衡器服務中的某些集區成員「關閉」時,UI 會將整併狀態顯示為「啟動」

    當集區成員關閉時,原則 UI 上不會指出集區處於綠色的「啟動」狀態。

    因應措施:因應措施:無。

解決方案互通性已知問題
  • 問題 2289150:PCM 呼叫 AWS 無法啟動

    如果您將 CSM 上的 AWS 帳戶的 PCG 角色從 old-pcg-role 更新為 new-pcg-role,CSM 會將 AWS 上 PCG 執行個體的角色更新為 new-pcg-role。但是,PCM 不知道 PCG 角色已更新,因此,會繼續使用已使用 old-pcg-role 建立的舊 AWS 用戶端。這會導致 PCM AWS 雲端詳細目錄掃描及其他 AWS 雲端呼叫失敗。

    因應措施:如果您遇到此問題,請至少在變更為新角色 6.5 小時後再修改/刪除舊 PCG 角色。重新啟動 PCG 將使用新角色認證重新初始化所有 AWS 用戶端。

作業和監控服務已知問題
  • 問題 2316943 - 工作負載在 vMotion 執行期間有一小段時間未受保護。

    執行 vMotion 之後,VMware Tools 需要幾秒鐘的時間才會為虛擬機器報告正確的電腦名稱。因此,使用電腦名稱新增至 NSGroup 的虛擬機器在 vMotion 執行後會有幾秒鐘的時間不受保護。

    因應措施:若要在 DFW 規則中使用群組,請使用以虛擬機器名稱為基礎的準則,而非以電腦名稱為基礎的準則。

  • 問題 2331683 - 進階 UI 上的新增負載平衡器表單不會顯示 2.4 版的更新容量。

    新增負載平衡器表單開啟時,進階 UI 上顯示的機器尺寸容量不會根據 2.4 版進行更新。顯示的是舊版的容量。

    因應措施:無。

升級已知問題
  • 問題 2288549:RepoSync 失敗,並顯示資訊清單檔案上的總和檢查碼失敗

    在最近升級至 2.4 的部署中觀察到。在全新部署的管理程式上備份和還原升級後的設定時,資料庫中存在的存放庫資訊清單總和檢查碼與實際資訊清單檔案的總和檢查碼不相符。這會導致 RepoSync 在備份還原後被標記為失敗。

    因應措施:若要從此失敗復原,請執行下列步驟:

    1. 執行 CLI 命令 get service install-upgrade
      記下結果中「Enabled on」的 IP。
    2. 登入上述命令的「Enabled on」傳回項中所示的 NSX Manager IP。
    3. 導覽至系統 > 概觀,並找到與「Enabled on」傳回項具有相同 IP 的節點。
    4. 在該節點上按一下解決
    5. 當上述解決作業成功後,在同一介面中的所有節點上按一下解決
      所有三個節點會立即顯示 RepoSync 狀態為完成
  • 問題 2277543 - 在就地升級期間主機 VIB 更新失敗,並顯示錯誤「在主機上安裝離線服務包失敗」。

    使用執行 ESXi-6.5P03 (組建編號 10884925) 的主機從 NSX-T 2.3.x 進行就地升級至 2.4 之前,在主機上執行 Storage vMotion 時,可能會發生此錯誤。如果在主機升級之前執行 Storage vMotion,系統不會移除 2.3.x 交換器安全性模組。Storage vMotion 會觸發記憶體流失,導致交換器安全性模組解除載入失敗。

    因應措施:請參閱知識庫文章 67444:Host VIB update may fail when upgrading from NSX-T 2.3.x to NSX-T 2.4.0 if VMs are storage vMotioned before host upgrade (如果在主機升級前虛擬機器已執行 Storage vMotion,則從 NSX-T 2.3.x 升級至 NSX-T 2.4.0 時,主機 VIB 更新可能會失敗)

  • 問題 2276398 - AV 合作夥伴服務虛擬機器使用 NSX 升級時,可能會有最多二十分鐘失去保護。

    當合作夥伴 SVM 升級時,系統會部署新的 SVM 並刪除舊的 SVM。主機 Syslog 可能會顯示 SolutionHandler 連線錯誤。

    因應措施:升級後刪除主機上的 ARP 快取項目,然後在主機上對合作夥伴控制 IP 執行 Ping 動作來解決此問題。

  • 問題 2330417 - 無法繼續對未升級的傳輸節點進行升級。

    在升級時,即使某些傳輸節點並未升級,升級仍標示為成功。記錄位置:/var/log/upgrade-coordinator/upgrade-coordinator.log。

    因應措施:重新啟動升級協調器服務。

API 已知問題
  • 問題 2260435 - API 依預設會建立無狀態重新導向原則/規則,但這不支援東西向連線。

    API 依預設會建立無狀態重新導向原則/規則,但這不支援東西向連線。因此,流量無法重新導向至合作夥伴。

    因應措施:使用原則 API 建立重新導向原則時,請建立可設定狀態的區段。

  • 問題 2332397 - API 允許在不存在網域中建立 DFW 原則。

    在不存在的網域上建立此類原則後,當使用者開啟 DFW 安全性索引標籤時,介面可能會沒有回應。相關的記錄為 /var/log/policy/policy.log。

    因應措施:使用相同的識別碼,建立先前已建立原則的網域。這可讓驗證成功執行。

NSX Cloud 已知問題
  • 問題 2275232:如果 DFW 的 Connectivity_statregy 已從黑名單變更為白名單,DHCP 將不適用於雲端上的虛擬機器

    申請新 DHCP 租用的所有虛擬機器都將遺失 IP。需要在 DFW 中明確允許 DHCP 用於雲端虛擬機器。

    因應措施:在 DFW 中明確允許 DHCP 用於雲端虛擬機器。

  • 問題 2277814:具有無效 nsx.network 標籤值的虛擬機器被移至 vm-overlay-sg

    標記有無效 nsx.network 標籤的虛擬機器將被移至 vm-overlay-sg。

    因應措施:移除無效的標籤。

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