VMware Integrated OpenStack 4.1.2.1 | 2018 年 12 月 13 日 | 組建編號 11157248

查看這些版本說明的新增項目和更新。

版本說明的內容

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

關於 VMware Integrated OpenStack

VMware Integrated OpenStack 透過精簡整合程序,大幅簡化了 OpenStack 雲端基礎結構的部署。VMware Integrated OpenStack 透過直接在 vCenter Server 中執行的部署管理員 vApp,提供了立即可用的 OpenStack 功能和簡單的組態工作流程。

相容性

如需有關 VMware Integrated OpenStack 與其他 VMware 產品 (包括 vSphere 元件) 的相容性詳細資料,請參閱《VMware 產品互通性對照表》

升級至 4.1.2.1 版

升級至 VMware Integrated OpenStack 4.1.2.1 是一個修補程序。根據目前已安裝的 VMware Integrated OpenStack 版本,此程序會有所不同。

修補程序

如果您執行的是 VMware Integrated OpenStack 4.1、4.1.1 或 4.1.2,則可以將修補程式直接套用至您現有的部署。若要這麼做,請執行下列步驟:

  1. 確認 OpenStack 部署正在執行中或尚未部署。如果 VMware Integrated OpenStack 部署處於任何其他狀態,則升級會失敗。
    附註:如果您要從 4.1.0 版進行修補並且尚未部署 OpenStack,則必須執行 viopatch install 命令兩次。略過首次執行命令時顯示的錯誤,然後再次執行命令。
  2. 在 vSphere Web Client 中,建立 OpenStack 管理伺服器虛擬機器的快照。

  3. 在 OpenStack 管理伺服器虛擬機器上,透過執行下列命令建立快照:
    sudo viopatch snapshot take
    此命令會停止 OpenStack 服務。安裝修補程式時,將會重新啟動服務。
    附註:如果命令失敗,請參閱〈已知問題〉一節中的「針對使用遠端 vCenter Server 的部署,viopatch 命令無法建立快照」

  4. 將修補程式檔案下載到 OpenStack 管理伺服器虛擬機器。

  5. 透過執行下列命令新增修補程式檔案:
    sudo viopatch add -l path/vio-patch-4.1.2.1_4.1.2.11157248_all.deb

  6. 透過執行下列命令安裝修補程式檔案:
    sudo viopatch install -p vio-patch-4.1.2.1 -v 4.1.2.11157248
    附註:基礎結構服務將在修補程序期間重新啟動。
    修補程式安裝期間,會自動關閉 API 端點。因此,安裝期間的任何 API 呼叫均會傳回 503 錯誤。

  7. 登出 vSphere Web Client,然後重新登入。可略過登入期間遇到的任何錯誤訊息。

附註:viopatch uninstall 動作已被取代,並且無法用來還原為先前版本。因此,此修補程序中建立的快照對於還原是必要的。在完成所有驗證工作並確定您將不需要還原為先前版本之前,請不要移除這些快照。

確認已修補的版本正常運作後,您可以執行 sudo viopatch snapshot remove 以刪除快照。此動作具有破壞性,且無法回復。

如果在安裝修補程式後需要還原為先前版本,請執行下列步驟。

  1. 在 OpenStack 管理伺服器虛擬機器上,透過執行下列命令還原為先前的快照:
    sudo viopatch snapshot revert

  2. 在 vSphere Web Client 中,將 OpenStack 管理伺服器虛擬機器還原為先前的快照。

  3. 在 OpenStack 管理伺服器虛擬機器上,透過執行下列命令重新啟動 OpenStack 服務:
    sudo service oms restart

  4. 在 vCenter Server 虛擬機器上,停止 vSphere Client 服務,刪除剩餘檔案,然後重新啟動服務:
    • 針對 vSphere 6.5 或更新版本,請執行下列命令:
      service-control --stop vsphere-client
      cd /etc/vmware/vsphere-client/vc-packages/vsphere-client-serenity/
      rm -rf *
      cd /usr/lib/vmware-vsphere-client/server/work
      rm -rf *
      service-control --start vsphere-client

    • 針對 vSphere 6.0,請執行下列命令:
      service vsphere-client stop
      cd /etc/vmware/vsphere-client/vc-packages/vsphere-client-serenity/
      rm -rf *
      service vsphere-client start

    • 針對 vSphere 5.5,請執行下列命令:
      service vsphere-client stop
      cd /var/lib/vmware/vsphere-client/vc-packages/vsphere-client-serenity/
      rm -rf *
      service vsphere-client start

  5. 登出 vSphere Web Client,然後重新登入。

舊版

若要從 VMware Integrated OpenStack 4.0 升級到 VMware Integrated OpenStack 4.1.2.1,請執行下列步驟:

  1. 〈修補 VMware Integrated OpenStack〉中所述,升級到 VMware Integrated OpenStack 4.1。
  2. 如上所述,套用 VMware Integrated OpenStack 4.1.2.1 修補程式。

附註:不支援直接從 VMware Integrated OpenStack 3.1 升級到 4.1.2.1 或更新版本。您必須先移轉到 4.1.2 版,然後安裝所需版本的修補程式。

從 VMware Integrated OpenStack 3.1 升級到 VMware Integrated OpenStack 4.1.2.1,有兩個升級路徑:

  1. 〈安裝新版本〉中所述,部署 VMware Integrated OpenStack 4.1 OVA。
  2. 在新的 4.1 部署中,如《VMware Integrated OpenStack 4.1.2 版本說明》中所述,套用 VMware Integrated OpenStack 4.1.2 修補程式。
  3. 〈移轉至新 VMware Integrated OpenStack 部署〉中所述,移轉至修補的部署。
  4. 如上所述,套用 VMware Integrated OpenStack 4.1.2.2 修補程式。

附註:如果您已在停用來源 NAT 的路由器上設定浮動 IP 位址,請啟用來源 NAT 或移除浮動 IP 位址,然後再升級至 4.1.2.1 版。已停用來源 NAT 的路由器不再支援浮動 IP 位址。

國際化

VMware Integrated OpenStack 4.1.2.1 提供英文及其他 7 種語言版本:簡體中文、繁體中文、日文、韓文、法文、德文及西班牙文。

下列項目必須僅包含 ASCII 字元:

  • OpenStack 資源 (例如專案、使用者和映像) 的名稱
  • 基礎結構元件 (例如 ESXi 主機、連接埠群組、資料中心和資料存放區) 的名稱
  • LDAP 和 Active Directory 屬性

VMware Integrated OpenStack 的開放原始碼元件

產品下載頁面的 [開放原始碼] 索引標籤中提供了適用於 VMware Integrated OpenStack 4.1.2.1 中散佈的開放原始碼軟體元件的版權聲明與授權。您也可以針對 VMware Integrated OpenStack 的元件下載公開套件,這些套件由 GPL、LGPL 或者需要原始碼或需要修改原始碼的其他相似授權進行管理,以使其可供使用。

已解決的問題

  • 長時間執行的作業可能會由於 token 到期而失敗。

    在處理長時間執行的作業 (例如即時移轉) 期間,Nova 可能無法存取其他專案,因為其 token 在作業結束前已過期。

    已透過實作目前支援且預設為啟用的 Keystone 服務 token 來解決此問題。使用服務 token 時,會忽略使用者 token 過期。

  • Ceilometer 和 OSProfiler 無法共同運作。

    如果已在 Ceilometer 執行時啟用 OSProfiler,Ceilometer 節點上會發生錯誤。

    已在此版本中解決此問題。

  • 建立分散式路由器期間所產生的 PLR 項目可能會錯誤地顯示為孤立。

    在提供者網路上建立分散式路由器後,nsxadmin 公用程式將相關聯的邏輯路由器和內部網路列示為孤立。

    已在此版本中解決此問題。

已知問題

已知問題分類如下。

VMware Integrated OpenStack
  • 變更 NSX-T 密碼後,VMware Integrated OpenStack 無法連線至 NSX-T。

    如果您在 Neutron 伺服器正在執行時變更 NSX-T 密碼,VMware Integrated OpenStack 可能無法連線至 NSX-T。

    因應措施:變更 NSX-T 密碼之前,登入作用中控制器節點並執行 systemctl stop neutron-server 命令,以停止 Neutron 伺服器服務。在 VMware Integrated OpenStack 中更新 NSX-T 密碼後,服務將重新啟動。

  • 針對使用遠端 vCenter Server 的部署,viopatch 命令無法建立快照

    如果在部署環境中,所有控制虛擬機器部署在管理 vCenter Server 執行個體中,並使用遠端 vCenter Server 執行個體中部署的 Nova 運算節點,則 viopatch snapshot take 命令無法取得管理 vCenter Server 執行個體的相關資訊。命令失敗並顯示錯誤「AttributeError: 『NoneType』物件沒有屬性『snapshot』」。

    因應措施:在 OpenStack 管理伺服器虛擬機器中,透過執行下列命令手動設定管理 vCenter Server 的 IP 位址、使用者名稱和密碼:

    export VCENTER_HOSTNAME = mgmt-vc-ip-address export VCENTER_USERNAME = mgmt-vc-username export VCENTER_PASSWORD = mgmt-vc-password
  • OpenStack GUI 僅匯出公用虛擬 IP 位址的原始值。

    如果公用虛擬 IP 位址發生變更,並且 VMware Integrated OpenStack 或 OpenStack 組態已匯出並在設定時重新載入,則匯出的組態將包含原始組態的公用虛擬 IP 位址,而不是已更新的值。

    因應措施:在重新載入 OpenStack 組態前,更新已匯出並儲存之組態檔中的公用虛擬 IP 位址。或者,在確認重新部署時在 GUI 中更新公用虛擬 IP 位址。

  • 公用負載平衡器 IP 位址與 OpenStack API 存取網路發生衝突。

    如果在 GUI 外部進行設定,公用負載平衡器的 IP 位址可能會與 OpenStack API 存取網路重疊。當組態已匯出並重新套用到 OpenStack 或 VMware Integrated OpenStack 設定時,將不允許 IP 位址重疊。

    因應措施:提供或設定 IP 位址時,請確保負載平衡器公用 IP 位址不會與 OpenStack API 存取網路重疊。

  • 負載平衡器進入 [錯誤] 狀態。

    如果使用未連線至第 1 層網路路由器的子網路建立負載平衡器,則負載平衡器無法成功建立並會進入 [錯誤] 狀態。

    因應措施:在建立負載平衡器之前,將第 1 層網路路由器連結至子網路。

  • 可能無法在 OpenStack 管理伺服器上執行憑證驗證。

    您使用 viocli 命令列公用程式時,可能會發生下列錯誤:

    ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)

    因應措施:在 OpenStack 管理伺服器上,透過執行下列命令停用 vCenter Server 憑證驗證:

    sudo su - export VCENTER_INSECURE=True
  • 當您移除已啟用 BGP 的共用路由器的閘道時,其他已啟用 BGP 的共用路由器上可能會發生短暫的網路中斷。

    在具有共用路由器的環境中,多個路由器可能主控於相同的 Edge。如果 BGP 已啟用,其中一個路由器的閘道 IP 位址將用作 router id。清除路由器的閘道時,外掛程式會選取另一個已啟用 BGP 之路由器的閘道做為 router id 的新值。此程序會導致對等暫時中斷,因為主控於該 Edge 之其他已啟用 BGP 的路由器的通告路由會遺失。

    因應措施:使用獨佔路由器。

  • 重新整理 Nova 或 Neutron 服務期間,服務中斷。

    如果 VMware Integrated OpenStack 偵測到不符合授權需求的 OpenStack 設定,它會嘗試透過重新啟動 Nova 或 Neutron 服務來修正設定。

    因應措施:無。指派授權,然後部署 OpenStack,以確保 OpenStack 設定符合授權需求。

  • 對於 NSX-T 部署,新的第 0 層路由器不會在執行 router-gateway-set 期間連線到第 1 層路由器。

    如果您在已設定一個第 0 層路由器的情況下建立第 0 層路由器,新路由器的 UUID 不會自動寫入 nsxv3.ini 檔案。您建立的第 1 層路由器隨後不會連線到新的第 0 層路由器。

    因應措施:手動更新 nsxv3.ini 檔案,然後重新建立外部網路。

    1. 找到新的第 0 層路由器的 UUID。
    2. 開啟 /etc/neutron/plugin/vmware/nsxv3.ini 檔案並更新新的第 0 層路由器的 UUID。
    3. 重新啟動 Neutron 伺服器。
    4. 刪除外部網路並建立新的外部網路。
  • 刪除路由器介面逾時。

    使用共用 NSX 路由器部署並行 Heat 堆疊時,路由器介面刪除可能逾時。可能會顯示下列內容:Neutron_client_socket_timeouthaproxy_neutron_client_timeouthaproxy_neutron_server_timeout

    因應措施:請勿在網路資源經常變更的環境中使用共用路由器。如果需要 NAT/FIP,請使用獨佔路由器。否則,請使用分散式路由器。

  • 對於 NSX-V 部署,將閘道連結至中繼資料 Proxy 路由器後,OpenStack 部署無法存取中繼資料伺服器。

    如果您將閘道連結至中繼資料 Proxy 路由器,NSX Edge vnic0 索引會從虛擬機器網路變更為閘道網路連接埠群組。這可能會使 OpenStack 部署無法存取中繼資料伺服器。

    因應措施:請勿將閘道連結至中繼資料 Proxy 路由器。

  • 對於 NSX-T 部署,如果將防火牆連結到沒有閘道的路由器,防火牆規則會新增至 NSX 路由器。

    防火牆即服務規則會新增至沒有閘道的路由器,即使沒有符合這些規則的相關流量亦是如此。

    因應措施:若要啟用規則,請為路由器設定閘道。

  • Nova 執行個體無法開機,並顯示錯誤「找不到有效的主機」。

    在壓力條件下,使用 tenant_vdc 內容將執行個體開機可能會失敗。

    因應措施:在系統負載較低時,將執行個體開機。

  • 在服務閘道 Edge 上,BGP 承租人網路中斷。

    在 BGP 發言人與服務閘道之間建立 BGP 對等互連之後,執行 neutron bgp-speaker-network-remove 命令以從外部或提供者網路解除關聯 BGP 發言人可能會導致服務閘道上的承租人路由遺失。使用 neutron bgp-speaker-network-add 將外部或提供者網路還原至 BGP 發言人將不會重新建立路由。

    因應措施:nsxv.ini 檔案中,將 ecmp_wait_time 的值變更為 5 秒。

  • DLR 承租人 Edge (PLR) 和提供者閘道 Edge 之間的 iBGP 對等互連無法正確通告承租人網路,並且會中斷外部通訊。

    使用 iBGP 對等互連時,通告的路由會安裝在對等項上,且無需修改下一個躍點。因此,提供者閘道 Edge 會在下一個躍點 IP 位址位於傳送網路範圍內 (而不是承租人的 PLR Edge 上行) 的承租人網路之間安裝路由。由於閘道 Edge 無法將路由解析為傳送網路,因此通訊會中斷。

    因應措施:使用分散式路由器時請使用 eBGP 對等互連。

  • 對於 NSX-V 部署,admin_state 參數不起作用。

    針對 Nova 連接埠,將 admin_state 參數變更為 False 不會生效。NSX-V 不支援此參數。

    因應措施:無。

  • 雲端服務路由器包含 IP 位址,而不包含 FQDN。

    在 VMware Integrated OpenStack 部署期間,負載平衡器組態中的公用主機名稱未指定或不符合公用存取的要求。公用主機名稱用於 VMware Integrated OpenStack 儀表板和 API 的外部存取。

    因應措施:若要在部署後變更或編輯公用主機名稱,請參閱知識庫 2147624

  • 將防火牆連結到沒有閘道的路由器時,防火牆規則不會新增到 NSX 路由器。

    防火牆即服務規則只會新增至具有閘道的路由器。這些規則不會影響沒有閘道的路由器,因為沒有任何相關的流量。

    因應措施:連結防火牆之前,為路由器設定閘道。

  • 中繼資料代理程式與 Nova 伺服器的 HTTP 通訊存在安全性風險。

    Edge 應用裝置上的中繼資料代理程式用作反向 Proxy 並與上游 Nova 伺服器進行通訊,以收集有關 OpenStack 上 NSX 環境的中繼資料資訊。nginx 反向 Proxy 組態也支援純文字式通訊。缺少 TLS 加密會使機密資料洩漏,網路上的攻擊者也可以從站台修改傳輸中的資料。

    因應措施:為確保中繼資料 Proxy 伺服器與 Nova 伺服器之間的通訊安全,請使用具有 CA 支援的 HTTPS,而不是 HTTP。

    1. 透過新增下列參數至 nova.conf,啟用 Nova 中繼資料 HTTPS 支援:
      [DEFAULT] enabled_ssl_apis = metadata [wsgi] ssl_cert_file = nova-md-https-server-cert-file ssl_key_file = nova-md-https-server-private-key-file
    2. 在 NSX Manager 中,選取系統 > 信任 > 憑證,然後匯入 CA 憑證或憑證鏈結。記錄已匯入憑證的 UUID。
    3. 採用下列格式準備 https_mdproxy.json 檔案: 
      { "display_name" : "https_md_proxy", "resource_type" : "MetadataProxy", "metadata_server_url" : "https://md-server-url", "metadata_server_ca_ids": ["ca-id"], "secret": "secret", "edge_cluster_id" : "edge-cluster-id" }
    4. 使用 REST API 部署 HTTPS 中繼資料 Proxy 伺服器。
      curl -i -k -u nsx-mgr-admin:nsx-mgr-passwd -H "content-type: application/json" -H "Accept: application/json" -X POST https://nsx-mgr-ip/api/v1/md-proxies -d "`cat ./https_mdproxy.json`"
    5. 為 VMware Integrated OpenStack 設定已建立中繼資料 Proxy 伺服器的 UUID。現已透過 HTTPS 與憑證驗證確保中繼資料 Proxy 伺服器與 Nova 伺服器之間的通訊安全。
  • 原則檔案自訂不會同步至 VMware Integrated OpenStack 儀表板。

    GUI 不會接受對自訂指導手冊中指定之原則的變更。

    因應措施:如果使用自訂指導手冊編輯原則檔案,請在 VMware Integrated OpenStack 儀表板原則檔案中進行相同的變更以確保一致性。

  • 在 Neutron 中啟用 NSX 原則後,可能會封鎖承租人流量。

    在 Neutron 外掛程式中啟用 security-group-policy 後,NSX 防火牆區段可能會以錯誤的順序列出。正確的順序如下所示:

    1. NSX 原則
    2. 承租人安全群組
    3. 預設區段

    因應措施:在 vSphere Web Client 中,開啟 [NSX 防火牆] 頁面,並將區段移至正確的位置。若要避免發生此問題,請建立第一個 NSX 原則,然後設定 VMware Integrated OpenStack。

  • 路由器大小下拉式功能表未顯示在 VMware Integrated OpenStack 儀表板上。

    當您在 VMware Integrated OpenStack 儀表板上建立獨佔路由器時,您可以指定其大小。不過,當您將路由器從共用變更為獨佔時,路由器大小下拉式功能表不會出現,因此您無法指定路由器大小。

    因應措施:還原路由器的預設值,然後再將類型修改為獨佔。下拉式功能表即會出現。

  • 無法在 VMware Integrated OpenStack 儀表板上修改設定了 SQL 的使用者。
    如果 VMware Integrated OpenStack 部署設定為使用 LDAP 進行使用者驗證,則無法在 VMware Integrated OpenStack 儀表板中修改任何使用者定義,即使是源自 SQL 資料庫也是如此。

    因應措施:無。

  • 在 vSphere HA 事件顯示同步化且程序啟動失敗後復原。

    vSphere HA 事件可能會影響您的 VMware Integrated OpenStack 部署。vSphere 復原後,在 OpenStack 管理伺服器上執行 viocli deployment status 命令。如果產生的報告顯示任何同步化或程序啟動失敗,則使用以下因應措施。

    因應措施:透過依序執行 viocli services stop 命令和 viocli services start 命令,手動重新啟動所有 OpenStack 服務。重新啟動 OpenStack 服務後,再次執行 viocli deployment status 命令,並確認沒有任何錯誤。

  • 映像必須是 VMX 10 版或更新版本。

    此問題會影響資料流最佳化的映像及 OVA。如果映像的硬體版本低於 VMX 10,從映像建立的 OpenStack 執行個體將無法正常運作。通常,在 OpenStack 運算節點部署於舊版 ESXi (如 5.5) 上時會發生此問題。您無法透過修改映像中繼資料 (vmware_hw_version) 或類型模板中繼資料 (vmware:hw_version) 來修正此類映像。

    因應措施:使用較新的映像。

  • 在使用無閘道選項建立的子網路上無法存取中繼資料服務。

    使用無閘道選項建立子網路時,不存在擷取中繼資料流量的路由器 Edge。

    因應措施對於使用無閘道選項的網路,設定 169.254.169.254/32 的路由,將流量轉送到 DHCP Edge IP 位址。

  • 如果控制器虛擬機器重新開機,高可用性可能會受到影響。

    當控制器在高可用性設定中失敗時,第二個控制器會繼續提供服務。但是,當初始控制器重新開機時,它可能不會開始提供服務。如果第二個控制器失敗,部署則無法切換回初始控制器。

    因應措施:失敗的控制器在高可用性設定中重新開機後,檢閱您的部署以確保兩個控制器均會提供服務。如需有關如何啟動和停止VMware Integrated OpenStack 部署的詳細資訊,請參閱知識庫 2148892

  • Glance 不支援資料存放區名稱中的特殊字元。
    如果資料存放區名稱包含某些非英數字元,該資料存放區無法新增至 Glance 服務。下列字元已保留用於其他目的,不允許用於 Glance 資料存放區名稱:冒號 (:)、逗號 (,)、斜線 (/) 和貨幣符號 ($)。

    因應措施:請勿在資料存放區名稱中使用這些符號。

  • 映像上傳時間過長導致 NotAuthenticated 失敗。
    這是已知的 OpenStack 問題,最初報告於 Icehouse 版本。請參閱 https://bugs.launchpad.net/glance/+bug/1371121

  • 即使連結失敗,磁碟區仍可能會在儀表板上顯示為已連結。
    這是已知的 OpenStack 問題,最初報告於 Icehouse 版本。

  • 透過 VMware Integrated OpenStack vApp 進行部署後,無法修改 Syslog 設定。

    部署後,無法在 VMware Integrated OpenStack > 管理伺服器 > 編輯設定 > vApp 選項中修改 Syslog 伺服器組態。

    因應措施:VMware Integrated OpenStack > OpenStack 叢集 > 管理 > Syslog 伺服器中修改組態。

VMware Integrated OpenStack with Kubernetes
  • 針對具有 SDDC 提供者的 VDS 部署,叢集可能會在復原後顯示為 [作用中],但沒有外部路由。

    如果 Nginx 入口控制器網繭在復原後處於錯誤狀態,可能會沒有外部路由。

    因應措施:執行下列步驟以清除錯誤狀態:

    1. 刪除預設服務帳戶和受影響的 Nginx 入口控制器網繭。
      kubectl delete serviceaccount default -n kube-system kubectl delete pod nginx-ingress-controller-id -n kube-system
    2. 在 VMware Integrated OpenStack with Kubernetes 虛擬機器上,執行 vkube cluster update 命令。
  • 無法還原已刪除的叢集。

    執行「刪除叢集」和「刪除提供者」命令後,遭到刪除的網路、路由器和負載平衡器將無法復原。

    因應措施:無。

  • 重新啟動 Kubernetes 叢集節點的客體作業系統後,Flannel 網繭未正確啟動。

    重新啟動 Kubernetes 叢集節點的客體作業系統會清理所有 IP 資料表規則。因此,Flannel 網繭不會正確啟動。

    因應措施:重新啟動 Kubernetes 網路 Proxy。您可以結束 kube-proxy 程序,hyperkube 將會自動啟動新的 kube-proxy 程序。

  • 執行叢集作業時,會顯示「未指派原則」錯誤。

    屬於指派給獨佔或共用叢集之群組的使用者在執行叢集作業 (例如執行 kubectl 公用程式) 時會看到「未指派原則」。發生此問題的原因是,在使用者工作階段期間未正確儲存已驗證使用者的群組資訊。

    因應措施:指派個別使用者 (而非群組) 至叢集。

  • SDDC 雲端提供者建立失敗,並顯示「dpkg: 無法復原的嚴重錯誤,正在中止:」訊息。

    建立 SDDC 雲端提供者失敗,且虛擬應用裝置上的 column-api 容器的記錄包含類似下列內容的訊息:

    - docker logs column-api -fTASK [bootstrap-os : Bootstrap | Install python 2.x and pip] *******************172.18.0.2 - - [06/Sep/2017 05:47:32] "GET /runs/46a74449-7123-4574-90c2-3404dfac6641 HTTP/1.1" 200 -fatal: [k8s-node-1-2393e79d-ec6a-4e63-8f63-c6308d72496e]: FAILED! => {"changed": true, "failed": true, "rc": 100, "stderr": "Shared connection to 192.168.0.3 closed.", "stdout": "........"dpkg: unrecoverable fatal error, aborting:", " files list file for package 'python-libxml2' is missing final newline", "E: Sub-process /usr/bin/dpkg returned an error code (2)"]}"

    因應措施:請刪除 SDDC 雲端提供者,然後重新建立。

  • 重新開啟包含 SDDC 提供者之 VMware Integrated OpenStack with Kubernetes 虛擬機器的電源後,OpenStack 服務容器停止運作,並且不會自動重新啟動。

    如果包含一個 SDDC 提供者之 VMware Integrated OpenStack with Kubernetes 虛擬機器的電源已關閉並重新開啟,虛擬機器將會移轉至另一台主機。針對提供者的後續作業 (例如 Kubernetes 叢集建立和擴充) 將失敗。

    因應措施:若要重新整理提供者,請執行下列步驟:

    1. 在 VMware Integrated OpenStack with Kubernetes 虛擬機器上,以根使用者身分登入。
      vkube login --insecure
    2. 重新整理 SDDC 提供者。
      vkube provider refresh sddc provider-id --insecure 

      您可以透過執行 vkube provider list --insecure 命令取得 SDDC 提供者識別碼。

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