- vCenter 升級/移轉預先檢查失敗，並顯示「未預期的錯誤 87」
如果 Security Token Service (STS) 憑證不包含主體別名 (SAN) 欄位，則 vCenter Server 升級/移轉預先檢查會失敗。當您已將 vCenter 5.5 Single Sign-On 憑證取代為不含 SAN 欄位的自訂憑證且嘗試升級至 vCenter Server 7.0 時，會發生此情況。升級會將 STS 憑證視為無效，並且預先檢查會阻止升級程序繼續進行。
因應措施：將 STS 憑證取代為包含 SAN 欄位的有效憑證，然後繼續執行 vCenter Server 7.0 升級/移轉。
- 透過預先存在的 CIM 提供者升級至 vSphere 7.0 時發生問題
升級後，先前安裝的 32 位元 CIM 提供者會停止運作，因為 ESXi 需要 64 位元 CIM 提供者。客戶可能會失去與 CIMPDK、NDDK (原生 DDK)、HEXDK、VAIODK (IO 篩選器) 相關的管理 API 功能，並看到與 uwglibc 相依性相關的錯誤。
Syslog 報告模組遺失「未載入 32 位元共用程式庫」。
因應措施：尚無因應措施。此修正的目的是從廠商下載新的 64 位元 CIM 提供者。
- 將您的 vCenter Server 系統修補至 vCenter Server 7.0.0a 後，該 TLS 版本的 VC 儲存區用戶端可能會還原為預設值
如果您的 VC 儲存區用戶端服務的 TLS 組態僅與預設 TLS 1.2 不同，則在將 vCenter Server 系統修補至 vCenter Server 7.0.0a 之後，TLS 版本可能會還原為預設值。
因應措施：更新後，使用 TLS 組態公用程式在 vCenter Server 系統上啟用或停用 TLS 版本。
- 升級至 vCenter Server 7.0 後，智慧卡和 RSA SecurID 驗證可能會停止運作
如果您已針對智慧卡或 RSA SecurID 驗證設定 vCenter Server，請參閱 VMware 知識庫文章 (網址為 https://kb.vmware.com/s/article/78057)，然後再開始 vSphere 7.0 升級程序。如果您未依照知識庫中所述執行因應措施，則可能會看到下列錯誤訊息，且智慧卡或 RSA SecurID 驗證無法運作。
「智慧卡驗證可能會停止運作。智慧卡設定可能無法保留，並且智慧卡驗證可能會停止運作。」
或
「RSA SecurID 驗證可能會停止運作。RSA SecurID 設定可能無法保留，並且 RSA SecurID 驗證可能會停止運作。」
因應措施：在升級至 vSphere 7.0 之前，請參閱 VMware 知識庫文章，網址為 https://kb.vmware.com/s/article/78057。
- 將含外部 Platform Services Controller 的 vCenter Server 從 6.7u3 升級至 7.0 失敗，並顯示 VMAFD 錯誤
當您升級使用外部 Platform Services Controller 的 vCenter Server 部署時，可將 Platform Services Controller 聚合至 vCenter Server Appliance。如果升級失敗並顯示錯誤 install.vmafd.vmdir_vdcpromo_error_21，則表示 VMAFD 首次開機程序失敗。VMAFD 首次開機程序會從來源 Platform Services Controller 和複寫合作夥伴 vCenter Server Appliance 複製 VMware Directory Service 資料庫 (data.mdb)。
因應措施：在升級含外部 Platform Services Controller 的 vCenter Server 之前，先在來源 Platform Services Controller 或複寫合作夥伴 vCenter Server Appliance 的乙太網路介面卡上停用 TCP 分割卸載 (TSO) 和一般分割卸載 (GSO)。請參閱知識庫文章：https://kb.vmware.com/s/article/74678。
- 使用 CLI 升級 vCenter Server 會錯誤地保留 vSphere Authentication Proxy 服務的傳輸安全層 (TLS) 組態
如果 vSphere Authentication Proxy 服務 (vmcam) 設定為使用除預設 TLS 1.2 通訊協定以外的特定 TLS 通訊協定，則會在 CLI 升級程序期間保留此組態。依預設，vSphere 支援 TLS 1.2 加密通訊協定。如果您必須使用 TLS 1.0 和 TLS 1.1 通訊協定來支援不支援 TLS 1.2 的產品或服務，請使用 TLS Configurator 公用程式啟用或停用不同的 TLS 通訊協定版本。
因應措施：使用 TLS Configurator 公用程式設定 vmcam 連接埠。若要瞭解如何管理 TLS 通訊協定組態以及使用 TLS Configurator 公用程式，請參閱《VMware 安全性》說明文件。
- 在 vCenter Server 升級期間，可能不會保留智慧卡和 RSA SecurID 設定
升級至 vCenter Server 7.0 後，使用 RSA SecurID 的驗證將無法運作。嘗試使用 RSA SecurID 登入資訊進行登入時，會顯示一則錯誤訊息，提示您解決此問題。
因應措施：重新設定智慧卡或 RSA SecureID。
- 將 vCenter Server for Windows 移轉至 vCenter Server Appliance 7.0 失敗，並顯示網路錯誤訊息
將 vCenter Server for Windows 移轉至 vCenter Server Appliance 7.0 失敗，並顯示錯誤訊息 IP 已存在於網路中。這會阻止移轉程序在新的 vCenter Server Appliance 上設定網路參數。如需詳細資訊，請檢查記錄檔：/var/log/vmware/upgrade/UpgradeRunner.log
因應措施：
- 確認已在來源 vCenter Server for Windows 執行個體上完成所有 Windows 更新，或停用自動 Windows 更新直到移轉完成為止。
- 重試將 vCenter Server for Windows 移轉至 vCenter Server Appliance 7.0。
- 當您使用 max_vfs 模組參數設定 SR-IOV 裝置的虛擬功能數目時，變更可能不會生效
在 vSphere 7.0 中，您可以使用虛擬基礎結構管理 (VIM) API (例如，透過 vSphere Client) 設定 SR-IOV 裝置的虛擬功能數目。此工作不需要將 ESXi 主機重新開機。使用 VIM API 組態後，如果您嘗試使用 max_vfs 模組參數設定 SR-IOV 虛擬功能的數目，則變更可能不會生效，因為這些變更已被 VIM API 組態覆寫。
因應措施：無。若要設定 SR-IOV 裝置的虛擬功能數目，請每次都使用相同的方法。使用 VIM API 或使用 max_vfs 模組參數，然後將 ESXi 主機重新開機。
- 升級後的 vCenter Server Appliance 執行個體不會保留來源執行個體中的所有次要網路 (NIC)
在主要升級期間，如果 vCenter Server Appliance 的來源執行個體設定了除 VCHA NIC 以外的多個次要網路，則目標 vCenter Server 執行個體將不會保留 VCHA NIC 以外的次要網路。如果來源執行個體設定了屬於 DVS 連接埠群組的多個 NIC，則在升級期間將不會保留 NIC 組態。將會保留屬於標準連接埠群組的 vCenter Server Appliance 執行個體的組態。
因應措施：無。在目標 vCenter Server Appliance 執行個體中手動設定次要網路。
- 在升級或移轉含外部 Platform Services Controller 的 vCenter Server 後，使用 Active Directory 進行驗證的使用者將失去對新升級的 vCenter Server 執行個體的存取權
在升級或移轉含外部 Platform Services Controller 的 vCenter Server 後，如果新升級的 vCenter Server 未加入至 Active Directory 網域，則使用 Active Directory 進行驗證的使用者將失去對 vCenter Server 執行個體的存取權。
因應措施：確認新的 vCenter Server 執行個體已加入至 Active Directory 網域。請參閱知識庫文章：https://kb.vmware.com/s/article/2118543
- 使用 Oracle 資料庫移轉含外部 Platform Services Controller 的 vCenter Server for Windows 失敗
匯出事件和工作資料時，如果 Oracle 事件和工作資料表中含有非 ASCII 字串，則移轉可能會失敗。將會提供下列錯誤訊息：UnicodeDecodeError
因應措施：無。
- 在 ESXi 主機升級後，主機設定檔符合性檢查會顯示不符合標準狀態，並且主機修復工作失敗
不符合標準狀態指出設定檔與主機之間發生不一致。
發生此不一致情況，可能是因為 ESXi 7.0 不允許重複的宣告規則，但您使用的設定檔包含重複的規則。例如，如果您先嘗試使用從主機擷取的主機設定檔，然後再將 ESXi 6.5 或 ESXi 6.7 升級至 7.0 版，並且主機設定檔包含系統預設規則的任何重複宣告規則，則您可能會遇到這些問題。
因應措施：
- 從主機設定檔文件中移除系統預設規則的任何重複宣告規則。
- 檢查符合性狀態。
- 修復主機。
- 如果先前的步驟沒有幫助，請將主機重新開機。
- vCenter Server 管理介面中顯示錯誤訊息
安裝或升級至 vCenter Server 7.0 後，當您導覽至 vCenter Server 管理介面內的 [更新] 面板時，會顯示錯誤訊息「檢查 URL，然後再試一次」。錯誤訊息不會阻止您使用 [更新] 面板內的功能，您可以查看、暫存和安裝任何可用的更新。
因應措施：無。
- Intel 82599/X540/X550 NIC 上網路效能的輸送量降低
與 vSphere 6.7 相比，在 vSphere 7.0 中為改善 Intel 82599EB/X540/X550 系列 NIC 上的網路效能而新增至 ixgben 驅動程式的新佇列配對功能，可能會降低某些工作負載下的輸送量。
因應措施：若要實現與 vSphere 6.7 相同的網路效能，您可以使用模組參數停用佇列配對。若要停用佇列配對，請執行下列命令：
# esxcli system module parameters set -p "QPair=0,0,0,0..."-m ixgben
執行命令後，請重新開機。
- 當 Network I/O Control (NetIOC) 啟用時，高輸送量虛擬機器可能會遇到網路效能降級的情況
從 vSphere 6.7 升級到已啟用 NetIOC 的 vSphere 7.0 時，需要高網路輸送量的虛擬機器可能會遇到輸送量降級的情況。
因應措施：調整 ethernetx.ctxPerDev 設定以啟用多個環境。
- IPv6 流量無法通過使用 IPsec 的 VMkernel 連接埠
當您將 VMkernel 連接埠從一個連接埠群組移轉到另一個連接埠群組時，IPv6 流量無法通過使用 IPsec 的 VMkernel 連接埠。
因應措施：從受影響的伺服器移除 IPsec 安全性關聯 (SA)，然後重新套用 SA。若要瞭解如何設定和移除 IPsec SA，請參閱《vSphere 安全性》說明文件。
- CPU 使用率增加時 ESX 網路效能提升
ESX 網路效能可能會隨著 CPU 使用率的增加而提升。
因應措施：移除並新增僅具有 1 個 rx 分派佇列的網路介面。例如：
esxcli network ip interface remove --interface-name=vmk1
esxcli network ip interface add --interface-name=vmk1 --num-rxqueue=1
- 熱新增、熱移除或執行 Storage vMotion 後，虛擬機器可能會中斷乙太網路流量
熱新增、熱移除或執行 Storage vMotion 後，虛擬機器可能會停止接收乙太網路流量。此問題會影響 VNIC 的上行已啟用 SR-IOV 的虛擬機器。如果虛擬網路的上行是 Mellanox 之具備 RDMA 功能的 NIC 並且已設定 RDMA 命名空間，PVRDMA 虛擬 NIC 便會出現此問題。
因應措施：您可以熱移除和熱新增虛擬機器之受影響的乙太網路 NIC，以還原流量。在 Linux 客體作業系統上，重新啟動網路也可能解決此問題。如果這些因應措施不起作用，您可以將虛擬機器重新開機以還原網路連線。
- 變更使用靜態 IP 位址部署之 VCSA 的 IP 位址，需要您預先建立 DNS 記錄
採用 DDNS 後，DNS 記錄更新僅適用於使用 DHCP 設定之網路部署的 VCSA。透過 VAMI 變更 vCenter Server 的 IP 位址時，會顯示下列錯誤：
指定的 IP 位址未解析為指定的主機名稱。
因應措施：有兩種可行的因應措施。
- 使用相同的 FQDN 和所需的 IP 位址建立其他 DNS 項目。登入 VAMI，並遵循下列步驟來變更 IP 位址。
- 使用 ssh 登入 VCSA。執行下列指令碼：
./opt/vmware/share/vami/vami_config_net
使用選項 6 變更 eth0 的 IP 位址。變更後，請執行下列指令碼：
./opt/likewise/bin/lw-update-dns
重新啟動 VCSA 上的所有服務，以更新 DNS 伺服器上的 IP 資訊。
- 在 NSX Manager 中刪除對應的邏輯交換器後，可能需要幾秒的時間才能移除 NSX 分散式虛擬連接埠群組 (NSX DVPG)。
隨著邏輯交換器數目的增加，在刪除 NSX Manager 中對應的邏輯交換器後，可能需要更多的時間才能移除 vCenter Server 中的 NSX DVPG。在具有 12000 個邏輯交換器的環境中，需要大約 10 秒的時間才能從 vCenter Server 中刪除 NSX DVPG。
因應措施：無。
- 如果建立了大量 NSX 分散式虛擬連接埠群組，則 Hostd 會耗盡記憶體，並且失敗。
在 vSphere 7.0 中，NSX 分散式虛擬連接埠群組耗用的記憶體數量明顯大於不透明網路。基於此原因，NSX 分散式虛擬連接埠群組無法支援與提供給不透明網路相同數量記憶體的相同規模。
因應措施：若要支援使用 NSX 分散式虛擬連接埠群組，請增加 ESXi 主機中的記憶體數量。如果您確認系統有足夠的記憶體可支援您的虛擬機器，您可以使用下列命令，直接增加 hostd 的記憶體。
localcli --plugin-dir /usr/lib/vmware/esxcli/int/ sched group setmemconfig --group-path host/vim/vmvisor/hostd --units mb --min 2048 --max 2048
請注意，這將導致 hostd 使用一般為環境的虛擬機器保留的記憶體。這可能會導致減少 ESXi 主機可支援的虛擬機器數目。
- 如果在虛擬機器上設定了網路保留區，則 DRS 可能會不正確地啟動 vMotion
如果在虛擬機器上設定了網路保留區，則預期 DRS 僅會將該虛擬機器移轉至符合指定需求的主機。在具有 NSX 傳輸節點的叢集中，如果某些傳輸節點透過 NSX-T 虛擬分散式交換器 (N-VDS) 而其他傳輸節點透過 vSphere Distributed Switch (VDS) 7.0 加入傳輸區域，則 DRS 可能會不正確地啟動 vMotion。在下列情況下，您可能會遇到此問題：
- 虛擬機器連線至設定了網路保留區的 NSX 邏輯交換器。
- 某些傳輸節點使用 N-VDS 而其他傳輸節點使用 VDS 7.0 加入傳輸區域，或者，傳輸節點透過不同的 VDS 7.0 執行個體加入傳輸區域。
因應措施：使所有傳輸節點透過 N-VDS 或相同的 VDS 7.0 執行個體加入傳輸區域。
- 將 VMkernel NIC (vmknic) 新增至 NSX 連接埠群組時，vCenter Server 會報告此錯誤：「不支援將 VMKernel 介面卡連線到乏態主機上的 NSX 連接埠群組。請改用分散式連接埠群組。」
- 對於分散式虛擬交換器 (DVS) 上的乏態 ESXi，會封鎖 NSX 連接埠群組上的 vmknic。您必須改為使用分散式連接埠群組。
- 對於 DVS 上可設定狀態的 ESXi，支援 NSX 連接埠群組上的 vmknic，但如果在 NSX 連接埠群組上使用 vmknic，則 vSAN 可能會發生問題。
因應措施：在相同 DVS 上使用分散式連接埠群組。
- 從 vCenter for QLogic 4x10GE QL41164HFCU CNA 啟用 SRIOV 可能會失敗
如果您導覽至實體網路介面卡的編輯設定對話方塊，並嘗試啟用 SR-IOV，則在使用 QLogic 4x10GE QL41164HFCU CNA 時，該作業可能會失敗。嘗試啟用 SR-IOV 可能會導致 ESXi 主機的網路中斷。
因應措施：在 ESXi 主機上使用下列命令來啟用 SRIOV：
esxcfg-module
- 新增 如果使用 Distributed Resource Scheduler (DRS) 的叢集中的主機透過不同的虛擬分散式交換器 (VDS) 或 NSX-T 虛擬分散式交換器 (NVDS) 和 VDS 的組合加入 NSX-T 網路，則 vCenter Server 會失敗
在 vSphere 7.0 中，在具有 DRS 叢集的 vSphere VDS 上使用 NSX-T 網路時，如果主機未透過相同的 VDS 或 NVDS 加入 NSX 傳輸區域，則可能會導致 vCenter Server 失敗。
因應措施：讓 DRS 叢集中的主機使用相同的 VDS 或 NVDS 加入 NSX 傳輸區域。
- 在具有 SmartPQI 控制器的 HPE Gen10 伺服器上進行磁碟熱移除和熱插入後，不會自動掛接 VMFS 資料存放區
如果將 HPE Gen10 伺服器 (具有不含延伸展開器的 SmartPQI 控制器) 上的 SATA 磁碟熱移除並重新熱插入同一機器的不同磁碟槽，或將多個磁碟熱移除並以不同的順序重新熱插入，有時會向該磁碟指派新的本機名稱。該磁碟上的 VMFS 資料存放區會顯示為快照，並且不會自動重新掛接，因為裝置名稱已變更。
因應措施：無。SmartPQI 控制器不支援未排序的熱移除和熱插入作業。
- 設定 nvme_pcie 驅動程式的記錄層級失敗並顯示錯誤
當您使用命令 esxcli nvme driver loglevel set -l <log level> 設定 nvme_pcie 驅動程式的記錄層級時，該動作會失敗並顯示錯誤訊息：
無法設定記錄層級 0x2。
由於 NVMe 驅動程式的相容性考量，此命令已保留，但 nvme_pcie 驅動程式不支援此命令。
因應措施：無。此情況將在 nvme_pcie 功能啟用時存在。
- 由於所有作用中路徑上的錯誤，ESXi 可能會終止 NVMeOF 裝置的 I/O
有時，由於連結問題或控制器狀態，NVMeOF 裝置的所有作用中路徑會登錄 I/O 錯誤。如果其中一個路徑的狀態變更為 [無作用]，則高效能外掛程式 (HPP) 可能不會在顯示大量錯誤時選取其他路徑。因此，I/O 失敗。
因應措施：停用組態選項 /Misc/HppManageDegradedPaths，以取消封鎖 I/O。
- 針對以 NVMe 為基礎的 VMFS 資料存放區執行 VOMA 檢查失敗，並顯示錯誤
以 NVMe 為基礎的 VMFS 資料存放區不支援 VOMA 檢查，將會失敗並顯示錯誤：
ERROR: 無法保留裝置。功能未實作
範例：
# voma -m vmfs -f check -d /vmfs/devices/disks/: <partition#>
正在檢查模式下執行 VMFS 檢查程式版本 2.1
正在初始化 LVM 中繼資料，基本檢查將會完成
正在檢查檔案系統活動
正在執行檔案系統運作情況檢查..|正在掃描 VMFS-6 主機活動 (4096 位元組/HB，1024 HBs)。
ERROR: 無法保留裝置。功能未實作
正在中止 VMFS 磁碟區檢查
VOMA 無法檢查裝置: 一般錯誤
因應措施：無。如果需要分析 VMFS 中繼資料，請使用 -l 選項進行收集，然後傳遞至 VMware 客戶支援部門。用於收集傾印的命令為：
voma -l -f dump -d /vmfs/devices/disks/:<partition#>
- 使用虛擬機器重新設定 API 將已加密的第一級磁碟連結至加密的虛擬機器可能會失敗，並顯示錯誤
如果使用不同的密碼編譯金鑰加密 FCD 和虛擬機器，則嘗試使用虛擬機器重新設定 API 將已加密的 FCD 連結至加密的虛擬機器可能會失敗，並顯示錯誤訊息：
由於金鑰或密碼錯誤，無法對磁碟進行解密。
因應措施：使用 attachDisk API 而非虛擬機器重新設定 API，將已加密的 FCD 連結至加密的虛擬機器。
- 如果 ESXi 主機的合併 VMFS 資料存放區的非主要範圍進入永久裝置遺失 (PDL) 狀態，則 ESXi 主機可能會處於無回應狀態
當合併 VMFS 資料存放區的非主要範圍與主要範圍一起出現故障時，不會發生此問題。在此情況下，整個資料存放區將變得無法存取，且不再允許 I/O。
反之，如果只有非主要範圍出現故障，而主要範圍仍然可供存取，則資料存放區活動訊號顯示為正常。主機與資料存放區之間的 I/O 會繼續。但是，任何依賴出現故障的非主要範圍的 I/O 也會啟動失敗。其他 I/O 交易可能會在等待解決故障 I/O 時累積，並導致主機進入無回應狀態。
因應措施：修正非主要範圍的 PDL 狀況以解決此問題。
- 從 APD 或 PDL 狀況復原後，已啟用叢集虛擬磁碟支援的 VMFS 資料存放區可能仍無法存取
只有在啟用了叢集虛擬磁碟支援的資料存放區上，才會發生此問題。當資料存放區從所有路徑失效 (APD) 或永久裝置遺失 (PDL) 狀況復原後，它仍然無法存取。VMkernel 記錄可能會顯示類似下列內容的多個 SCSI3 保留衝突訊息：
2020-02-18T07:41:10.273Z cpu22:1001391219)ScsiDeviceIO: vm 1001391219: SCSIDeviceCmdCompleteCB:2972: Reservation conflict retries 544 for command 0x45ba814b8340 (op: 0x89) to device "naa.624a9370b97601e346f64ba900024d53"
發生此問題的原因是，參與叢集的 ESXi 主機遺失了資料存放區的 SCSI 保留，且在資料存放區復原後無法始終自動重新取得。
因應措施：使用下列命令手動登錄保留：
vmkfstools -L registerkey /vmfs/devices/disks/<device name>
其中 <device name> 是在其上建立資料存放區的裝置的名稱。
- 虛擬 NVMe 控制器是適用於 Windows 10 客體作業系統的預設磁碟控制器
使用硬體版本 15 或更新版本時，虛擬 NVMe 控制器是下列客體作業系統的預設磁碟控制器：
Windows 10
Windows Server 2016
Windows Server 2019
使用虛擬 NVMe 控制器時，某些功能可能無法使用。如需詳細資訊，請參閱 https://kb.vmware.com/s/article/2147714
附註：某些用戶端使用先前預設的 LSI Logic SAS。這包括 ESXi Host Client 和 PowerCLI。
因應措施：如果您需要使用虛擬 NVMe 上未提供的功能，請切換至 VMware Paravirtual SCSI (PVSCSI) 或 LSI Logic SAS。如需使用 VMware Paravirtual SCSI (PVSCSI) 的相關資訊，請參閱 https://kb.vmware.com/s/article/1010398
- 將 ESXi 主機升級至 vSphere 7.0 後，存在重複的核心宣告規則，可能會導致非預期的行為
宣告規則會決定哪個多重路徑外掛程式 (例如 NMP、HPP 等) 擁有特定儲存裝置的路徑。ESXi 7.0 不支援重複的宣告規則。但是，如果您將重複規則新增至透過從舊版升級而繼承的現有宣告規則，則 ESXi 7.0 主機不會對您發出警示。由於使用重複的規則，儲存裝置可能會由非預期的外掛程式宣告，這可能會導致非預期的結果。
因應措施：請勿使用重複的核心宣告規則。在新增宣告規則前，刪除任何現有的相符宣告規則。
- 設有符合性狀態篩選器的 CNS 查詢可能需要很長時間才能完成
透過 CNS QueryVolume API，可以取得有關 CNS 磁碟區的資訊，例如磁碟區健全狀況和符合性狀態。檢查個別磁碟區的符合性狀態時，可以快速取得結果。但是，如果叫用 CNS QueryVolume API 以檢查多個磁碟區 (數十個或幾百個) 的符合性狀態，查詢的執行速度可能比較緩慢。
因應措施：避免使用大量查詢。當您需要取得符合性狀態時，請一次查詢一個磁碟區，或將查詢 API 中的磁碟區數目限制為 20 個或更少。使用查詢時，請避免執行其他 CNS 作業以取得最佳效能。
- 新增 已刪除的 CNS 磁碟區可能會在 CNS 使用者介面中暫時顯示為存在
刪除支援 CNS 磁碟區的 FCD 磁碟後，該磁碟區可能仍會在 CNS UI 中顯示為存在。不過，嘗試刪除磁碟區會失敗。您可能會看到類似下列內容的錯誤訊息：
找不到參照的物件或項目。
因應措施：下一次完整同步將可解決不一致的情況，並正確更新 CNS UI。
- 新增 嘗試將多個 CNS 磁碟區連結到相同的網繭可能偶爾會失敗，並顯示錯誤
當您同時將多個磁碟區連結到相同的網繭時，附加作業可能偶爾會選擇相同的控制器插槽。因此，只有其中一個作業會成功，而其他磁碟區掛接會失敗。
因應措施：在 Kubernetes 重試失敗的作業後，如果節點虛擬機器上有可用的控制器插槽，則作業會成功。
- 新增 在某些情況下，當 CNS 作業失敗時，vSphere Client 中的工作狀態會顯示為成功
比方說，當您使用不相容的儲存區原則來建立 CNS 磁碟區時，可能會發生此情況。作業會失敗，但 vSphere Client 會將工作狀態顯示為成功。
因應措施：vSphere Client 中的工作狀態為成功，並不保證 CNS 作業已成功。若要確定作業已成功，請確認其結果。
- 新增 對 CNS 持續性磁碟區執行刪除作業失敗，可能會使磁碟區無法在 vSphere 資料存放區上取消刪除
當 CNS 刪除 API 嘗試刪除仍連結至網繭的持續性磁碟區時，可能會發生此問題。例如，當您刪除網繭執行所在的 Kubernetes 命名空間時。因此，該磁碟區會從 CNS 中清除，CNS 查詢作業不會傳回該磁碟區。但是，磁碟區會繼續存放在資料存放區上，且無法透過重複的 CNS 刪除 API 作業來刪除。
因應措施：無。
- 廠商提供者在 PNID 變更後離線
當您變更 vCenter IP 位址 (PNID 變更) 時，已登錄的廠商提供者會離線。
因應措施：重新登錄廠商提供者。
- [硬體健全狀況] 索引標籤中的 [儲存區感應器] 資訊在 vCenter 使用者介面、主機使用者介面和 MOB 上顯示不正確的值
當您導覽至 vCenter 使用者介面上的主機 > 監控 > 硬體健全狀況 > 儲存區感應器時，儲存區資訊會顯示不正確或未知的值。主機使用者介面上以及 MOB 路徑 "runtime.hardwareStatusInfo.storageStatusInfo" 中也會出現相同的問題。
因應措施：無。
- vSphere 使用者介面主機進階設定會將目前的產品鎖定器位置顯示為空白，且預設為空白
vSphere 使用者介面主機進階設定會將目前的產品鎖定器位置顯示為空白，且預設為空白。這並不一致，因為實際的產品位置符號連結已建立且有效。這會導致使用者造成混淆。無法從使用者介面更正預設值。
因應措施：使用者可以在主機上使用 esxcli 命令，以如下方式更正目前的產品鎖定器位置預設值。
1.移除具有以下內容的現有產品鎖定器位置設定："esxcli system settings advanced remove -o ProductLockerLocation"
2.重新新增具有適當預設值的產品鎖定器位置設定：
2.a. 如果 ESXi 是完整安裝，則預設值為 "/locker/packages/vmtoolsRepo" export PRODUCT_LOCKER_DEFAULT="/locker/packages/vmtoolsRepo"
2.b.如果 ESXi 是 PXEboot 組態，例如 autodeploy，則預設值為："/vmtoolsRepo" export PRODUCT_LOCKER_DEFAULT="/vmtoolsRepo"
執行下列命令以自動確定位置：export PRODUCT_LOCKER_DEFAULT=`readlink /productLocker`
新增設定：esxcli system settings advanced add -d "Path to VMware Tools repository" -o ProductLockerLocation -t string -s $PRODUCT_LOCKER_DEFAULT
您可以透過發出單一命令在步驟 2 中合併上述所有步驟：
esxcli system settings advanced add -d "Path to VMware Tools repository" -o ProductLockerLocation -t string -s `readlink /productLocker`
- 如果 vCenter Cloud Gateway 連結至 SDDC，則連結的軟體定義資料中心 (SDDC) vCenter Server 執行個體會顯示在內部部署 vSphere Client 中。
當 vCenter Cloud Gateway 部署在與內部部署 vCenter Server 相同的環境中，並連結至 SDDC，則 SDDC vCenter Server 會顯示在內部部署 vSphere Client 中。這是非預期的行為，因此應忽略連結的 SDDC vCenter Server。涉及連結的 SDDC vCenter Server 的所有作業應在 vCenter Cloud Gateway 內執行的 vSphere Client 上執行。
因應措施：無。
- 無法在已啟用用於共同管理所有主機上的映像設定和更新的叢集上啟用 NSX-T
NSX-T 與用於映像管理的 vSphere Lifecycle Manager 功能不相容。當您啟用叢集以在該叢集中的所有主機上共同進行映像設定和更新時，無法在該叢集上啟用 NSX-T。但是，您可以將 NSX Edge 部署到此叢集。
因應措施：將主機移到可使用基準進行管理的新叢集，並在該新叢集上啟用 NSX-T。
- vSphere Lifecycle Manager 和 vSAN 檔案服務不能同時在 vSphere 7.0 版本中的 vSAN 叢集上啟用
如果在叢集上啟用了 vSphere Lifecycle Manager，則不能在相同叢集中啟用 vSAN 檔案服務，反之亦然。若要在已啟用 VSAN 檔案服務的叢集上啟用 vSphere Lifecycle Manager，請先停用 vSAN 檔案服務，然後重試該作業。請注意，如果您轉換為由單一映像管理的叢集，則無法在該叢集上停用 vSphere Lifecycle Manager。
因應措施：無。
- 無法使用 vSphere Auto Deploy 將 ESXi 7.0 主機新增至透過單一映像管理的叢集
嘗試使用 vSphere Auto Deploy 中的「新增至詳細目錄」工作流程將 ESXi 主機新增至透過單一映像管理的叢集失敗。發生失敗的原因是現有 Auto Deploy 規則集中沒有相符的模式。此工作以無訊息方式失敗，且主機仍保留在 [探索到的主機] 索引標籤中。
因應措施：
- 從 [探索到的主機] 索引標籤中移除與規則集不相符的 ESXi 主機。
- 建立規則或編輯現有 Auto Deploy 規則，其中主機目標位置是由映像管理的叢集。
- 將主機重新開機。
主機將新增到由 vSphere Lifecycle Manager 中的映像所管理的叢集。
- 當硬體支援管理程式無法使用時，vSphere High Availability (HA) 功能會受到影響
如果在透過單一映像管理的叢集上無法使用硬體支援管理程式，其中已選取韌體和驅動程式附加元件並已啟用 vSphere HA，則 vSphere HA 功能會受到影響。您可能會遇到下列錯誤。
- 在叢集上設定 vSphere HA 失敗。
- 無法在主機上完成 vSphere HA 代理程式設定。
在叢集上套用 HA VIB 時發生故障。
- 修復 vSphere HA 失敗：
發生一般系統錯誤: 無法取得有效元件對應。
- 停用 vSphere HA 失敗：刪除解決方案工作失敗。
發生一般系統錯誤: 從存放庫或硬體支援管理程式中找不到硬體支援套件。
因應措施：
- 如果硬體支援管理程式暫時無法使用，請執行下列步驟。
- 將硬體支援管理程式重新連線至 vCenter Server。
- 從 [主機和叢集] 功能表中選取叢集。
- 選取 [設定] 索引標籤。
- 在 [服務] 下，按一下 [vSphere 可用性]。
- 重新啟用 vSphere HA。
- 如果硬體支援管理程式永久無法使用，請執行下列步驟。
- 從映像規格中移除硬體支援管理程式和硬體支援套件
- 重新啟用 vSphere HA。
- 從 [主機和叢集] 功能表中選取叢集。
- 選取 [更新] 索引標籤。
- 按一下 [編輯]。
- 移除韌體和驅動程式附加元件，然後按一下 [儲存]。
- 選取 [設定] 索引標籤。
- 在 [服務] 下，按一下 [vSphere 可用性]。
- 重新啟用 vSphere HA。
- 在 vSphere Lifecycle Manager 中執行修復程序後，未從叢集中移除 I/OFilter
透過在 vSphere Lifecycle Manager 中修復叢集以從叢集中移除 I/OFilter 失敗，並顯示下列錯誤訊息：iofilter XXX 已存在。該 iofilter 仍會列示為已安裝。
因應措施：
- 從 vCenter Server 受管理物件 (IoFilterManager) 呼叫 IOFilter API
UninstallIoFilter_Task。
- 在 vSphere Lifecycle Manager 中修復叢集。
- 從 vCenter Server 受管理物件 (IoFilterManager) 呼叫 IOFilter API
ResolveInstallationErrorsOnCluster_Task，以更新資料庫。
- 在 vSphere Lifecycle Manager 中修復已啟用 vSphere HA 的叢集的同時，新增主機會導致 vSphere HA 錯誤狀態
在已啟用 vSphere HA 之叢集的修復程序期間新增一或多個 ESXi 主機，會導致下列錯誤訊息：在叢集上套用 HA VIB 時發生故障。
因應措施：在叢集修復作業完成後，執行下列其中一項工作。
- 在出現故障的 ESXi 主機上按一下滑鼠右鍵，然後選取針對 vSphere HA 重新設定。
- 針對叢集停用並重新啟用 vSphere HA。
- 在 vSphere Lifecycle Manager 中修復已啟用 vSphere HA 的叢集的同時，停用並重新啟用 vSphere HA 會導致 vSphere HA 錯誤狀態
由於 vSphere HA 健全狀況檢查報告主機尚未安裝 vSphere HA VIB，在叢集的修復程序期間停用並重新啟用 vSphere HA 可能會導致修復程序失敗。您可能會看到以下錯誤訊息：為叢集設定所需的映像規格失敗。
因應措施：在叢集修復作業完成後，針對叢集停用並重新啟用 vSphere HA。
- 在 vSphere Lifecycle Manager 中檢查大型叢集中的建議映像時效能低下
在具有超過 16 個主機的大型叢集中，建議產生工作可能需要超過一小時的時間才能完成，或者可能會顯示為當機。建議工作的完成時間取決於在每個主機上設定的裝置數目，以及 vSphere Lifecycle Manager 在取得有效的建議映像之前需要處理的存放庫中的映像候選數目。
因應措施：無。
- 在 vSphere Lifecycle Manager 中檢查大型叢集中的硬體相容性時效能低下
在具有超過 16 個主機的大型叢集中，驗證報告產生工作可能最多需要 30 分鐘的時間才能完成，或者可能會顯示為當機。完成時間取決於在每個主機上設定的裝置數目，以及叢集中設定的主機數目。
因應措施：無
- 在 vSphere Lifecycle Manager 中修復叢集時，會以非英文顯示不完整的錯誤訊息
在 vCenter Server 使用者介面中，可能會出現當地語系化語言的不完整錯誤訊息。vSphere Lifecycle Manager 中的叢集修復程序失敗後，會顯示這些訊息。例如，您可能會看到下列錯誤訊息。
以英文顯示的錯誤訊息：Virtual machine 'VMC on DELL EMC -FileServer' that runs on cluster 'Cluster-1' reported an issue which prevents entering maintenance mode: Unable to access the virtual machine configuration: Unable to access file[local-0] VMC on Dell EMC - FileServer/VMC on Dell EMC - FileServer.vmx
以法文顯示的錯誤訊息：La VM « VMC on DELL EMC -FileServer », située sur le cluster « {Cluster-1} », a signalé un problème empêchant le passage en mode de maintenance : Unable to access the virtual machine configuration: Unable to access file[local-0] VMC on Dell EMC - FileServer/VMC on Dell EMC - FileServer.vmx
因應措施：無。
- 將不含廠商附加元件、元件或韌體和驅動程式附加元件的映像匯入到其映像包含此類元素的叢集，不會移除現有映像的映像元素
僅會將 ESXi 基礎映像取代為已匯入映像中的映像。
因應措施：匯入程序完成後，編輯映像，並視需要移除廠商附加元件、元件以及韌體和驅動程式附加元件。
- 將使用基準的叢集轉換為使用單一映像的叢集時，會顯示一個警告，指出 vSphere HA VIB 將被移除
將使用基準的已啟用 vSphere HA 的叢集轉換為使用單一映像的叢集可能會導致出現警告訊息，指出 vmware-fdm 元件將被移除。
因應措施：可忽略此訊息。轉換程序會安裝 vmware-fdm 元件。
- 如果 vSphere Update Manager 設定為透過 Proxy 伺服器從網際網路下載修補程式更新，則在升級至 vSphere 7.0 (將 Update Manager 轉換為 vSphere Lifecycle Manager) 後，從 VMware 修補程式存放庫下載修補程式可能會失敗
在舊版 vCenter Server 中，您可以針對 vCenter Server 和 vSphere Update Manager 設定獨立 Proxy 設定。升級至 vSphere 7.0 後，vSphere Update Manager 服務會成為 vSphere Lifecycle Manager 服務的一部分。對於 vSphere Lifecycle Manager 服務，將從 vCenter Server Appliance 設定中進行 Proxy 設定。如果您已將 Update Manager 設定為透過 Proxy 伺服器從網際網路下載修補程式更新，但 vCenter Server Appliance 沒有 Proxy 設定組態，則在 vCenter Server 升級至 7.0 版後，vSphere Lifecycle Manager 無法連線至 VMware 存放庫且無法下載修補程式或更新。
因應措施：登入 vCenter Server Appliance 管理介面 (https://vcenter-server-appliance-FQDN-or-IP-address:5480)，以設定 vCenter Server Appliance 的 Proxy 設定，並啟用 vSphere Lifecycle Manager 以使用 Proxy。
- 將版本 6.5 的主機設定檔套用到版本 7.0 的 ESXi 主機時，符合性檢查會失敗
將版本 6.5 的主機設定檔套用到版本 7.0 的 ESXi 主機時，會導致核心傾印檔設定檔報告為與主機不相符。
因應措施：有兩種可行的因應措施。
- 當您建立版本 6.5 的主機設定檔時，請在 ESXi 主機上將進階組態選項 VMkernel.Boot.autoCreateDumpFile 設定為 false。
- 當您套用版本 6.5 的現有主機設定檔時，請在主機設定檔中新增進階組態選項 VMkernel.Boot.autoCreateDumpFile，將選項設定為固定原則，並將值設定為 false。
- 當您的瀏覽器設定為非英文版本時，[動作] 下拉式功能表不包含任何項目
當您的瀏覽器設定為非英文版本，並且按一下 vSphere Client 詳細目錄之虛擬機器摘要索引標籤中的切換到新視圖按鈕時，客體作業系統面板中的動作下拉式功能表不會包含任何項目。
因應措施：選取虛擬機器頁面頂端的動作下拉式功能表。
- 當動態接收端調整 (DYN_RSS) 或一般 RSS (GEN_RSS) 功能已開啟時，Mellanox ConnectX-4 或 ConnectX-5 原生 ESXi 驅動程式可能會出現輕微輸送量降低的情況
當 DYN_RSS 和 GEN_RSS 功能開啟時，Mellanox ConnectX-4 或 ConnectX-5 原生 ESXi 驅動程式的輸送量下降可能不到 5%，這可能會影響正常工作負載。
因應措施：您可以使用下列命令停用 DYN_RSS 和 GEN_RSS 功能：
# esxcli system module parameters set -m nmlx5_core -p "DYN_RSS=0 GEN_RSS=0"
# reboot
- 在 PVRDMA 環境中，同一主機上的兩個虛擬機器之間的 RDMA 流量可能會出現故障
在 PVRDMA 環境的 vSphere 7.0 實作中，如果存在 HCA，虛擬機器會透過 HCA 傳遞流量以進行本機通訊。但是，RDMA 流量的回送無法在 qedrntv 驅動程式上運作。 例如，在同一個上行連接埠下設定之虛擬機器上執行的 RDMA 佇列配對無法相互通訊。
在 vSphere 6.7 及更早版本中，如果 SRQ 已啟用，則 HCA 用於本機 RDMA 流量。對於使用已啟用 SRQ 的 PVRDMA 版本以及使用 RoCE v2 的最低硬體版本 14 的虛擬機器，vSphere 7.0 將會使用 HCA 回送。
目前版本的 Marvell FastLinQ 介面卡韌體不支援相同 PF 或連接埠的 QP 之間的回送流量。
因應措施：將在已通過 vSphere 7.0 認證的立即可用的驅動程式中新增必要支援。如果您使用的是收件匣 qedrntv 驅動程式，則必須使用包含 3 個主機的組態，並將虛擬機器移到第三個主機。
- qedrntv 驅動程式中不可靠的資料包流量 QP 存在限制
Marvell FastLinQ qedrntv RoCE 驅動程式與不可靠的資料包 (UD) 流量有限制。在 qedrntv 驅動程式中，涉及大量流量的 UD 應用程式可能會失敗。此外，UD QP 僅適用於 DMA 記憶體區域 (MR)。不支援實體 MR 或 FRMR。嘗試使用實體 MR 或 FRMR 以及 UD QP 的應用程式在與 qedrntv 驅動程式搭配使用時無法傳遞流量。此類測試應用程式的已知範例為 ibv_ud_pingpong 和 ib_send_bw。
VMware ESXi 環境中的標準 RoCE 和 RoCEv2 使用案例，例如 iSER、NVMe-oF (RoCE) 和 PVRDMA，不受此問題影響。用於 UD 流量的使用案例會受到限制，此問題會影響需要大量 UD 流量的一小部分應用程式。
Marvell FastLinQ 硬體不支援 RDMA UD 流量卸載。為了滿足支援 GSI QP 的 VMware PVRDMA 需求，qedrntv 驅動程式中新增了 UD QP 支援的僅受限軟體實作。實作的目標是為控制路徑 GSI 通訊提供支援，而不是完整實作 UD QP (支援大量流量和進階功能)。
由於在軟體中實作了 UD 支援，因此，實作可能不會維持大量流量，且封包可能會遭到捨棄。這可能會導致大量 UD 流量出現故障。
因應措施：qedrntv 驅動程式不支援大量 UD QP 流量，並且目前沒有因應措施。諸如 iSER、NVMe、RDMA 和 PVRDMA 等 VMware ESXi RDMA (RoCE) 使用案例不受此問題影響。
- 在頻繁連線或中斷連線 iSCSI LUN 時，配備 QLogic 578xx NIC 的伺服器可能會失敗
如果您在短時間內頻繁觸發 QLogic 578xx NIC iSCSI 連線或中斷連線，則伺服器可能會因為 qfle3 驅動程式的問題而失敗。這是由於裝置韌體中的已知缺陷所致。
因應措施：無。
- 在 Broadcom NVMe over FC 環境中，ESXi 可能會在驅動程式解除載入或控制器中斷連線作業期間失敗
在 Broadcom NVMe over FC 環境中，ESXi 可能會在驅動程式解除載入或控制器中斷連線作業期間失敗，並顯示類似下列內容的錯誤訊息：@BlueScreen: #PF Exception 14 in world 2098707:vmknvmeGener IP 0x4200225021cc addr 0x19
因應措施：無。
- 在某些 Dell 伺服器上，ESXi 不會顯示 i350/X550 NIC 的 OEM 韌體版本號碼
收件匣 ixgben 驅動程式僅可識別 i350/X550 NIC 的韌體資料版本或簽章。在某些 Dell 伺服器上，OEM 韌體版本號碼將按照 OEM 套件版本區域進行程式設計，而收件匣 ixgben 驅動程式無法讀取此資訊。僅會顯示 8 位數的韌體簽章。
因應措施：若要顯示 OEM 韌體版本號碼，請安裝非同步 ixgben 驅動程式版本 1.7.15 或更新版本。
- 在 ESXi 中，X710 或 XL710 NIC 可能會失敗
當您對 X710 或 XL710 NIC 起始某些破壞性作業 (例如，重設 NIC 或操縱 VMKernel 的內部裝置樹狀結構) 時，NIC 硬體可能會從非封包記憶體讀取資料。
因應措施：請勿重設 NIC 或操縱 vmkernel 內部裝置狀態。
- 在系統重新開機後，NVMe-oF 無法保證持續性 VMHBA 名稱
NVMe-oF 是 vSphere 7.0 中的一項新功能。如果您的伺服器具有使用 vmhba30+ 的 USB 儲存區安裝並且還具有 NVMe over RDMA 組態，則在系統重新開機後，VMHBA 名稱可能會變更。這是因為針對 NVMe over RDMA 的 VMHBA 名稱指派與 PCIe 裝置不同。ESXi 無法保證持續性。
因應措施：無。
- 針對 300 GB 或以上的 vCenter 資料庫大小備份失敗
如果 vCenter 資料庫大小為 300 GB 或以上，則以檔案為基礎的備份將會失敗並出現逾時。且會顯示下列錯誤訊息：逾時! 無法在 72000 秒內完成。
因應措施：無。
- 對照版本 6.5 或 6.7 的主機設定檔檢查 ESXi 7.0 主機的符合性狀態，導致 vmhba 和 vmrdma 裝置發生錯誤
對照版本 6.5 或 6.7 的主機設定檔檢查使用 nmlx5_core 或 nvme_pcie 驅動程式的 ESXi 7.0 主機的符合性時，您可能會看到下列錯誤，其中 address1 和 address2 特定於受影響的系統。
- 匯流排類型為邏輯且位址為
address1 的 vmhba 裝置不存在於您的主機上。
-
匯流排類型為邏輯且位址為
address2 的 vmrdma 裝置不存在於您的主機上。
發生此錯誤的原因是，在 ESXi 7.0 版及更早版本中，
nmlx5_core 或
nvme_pcie 驅動程式所產生的裝置位址不相符。
因應措施：可忽略此錯誤。ESXi 主機功能不受影響。若要解決符合性狀態錯誤，請從 ESXi 主機 7.0 版重新擷取主機設定檔，然後將新的主機設定檔套用到主機。
- 還原從含外部 Platform Services Controller 的 vCenter Server 6.x 升級至 vCenter Server 7.0 的 vCenter Server 7.0 可能會失敗
當您還原從含外部 Platform Services Controller 的 6.x 升級至 vCenter Server 7.0 的 vCenter Server 7.0 時，還原可能會失敗，並顯示下列錯誤：無法擷取應用裝置儲存清單
因應措施：在還原程序的第一個階段期間，請增加 vCenter Server 7.0 的儲存區層級。例如，如果 vCenter Server 6.7 外部 Platform Services Controller 設定的儲存區類型較小，請針對還原程序選取較大儲存區類型。
- 在主機設定檔修復程序期間未設定已啟用的 SSL 通訊協定組態參數
在主機設定檔修復期間未設定已啟用的 SSL 通訊協定組態參數，並且僅啟用系統預設通訊協定 tlsv1.2。在 vCenter Server 7.0 環境中，版本 7.0 及更早版本的主機設定檔會出現此行為。
因應措施：若要為 SFCB 啟用 TLSV 1.0 或 TLSV 1.1 SSL 通訊協定，請使用 SSH 登入 ESXi 主機，然後執行下列 ESXCLI 命令：esxcli system wbem -P <protocol_name>
- 無法使用主機設定檔設定鎖定模式設定
鎖定模式無法透過安全性主機設定檔進行設定，且無法一次套用到多個 ESXi 主機。您必須手動設定每個主機。
因應措施：在 vCenter Server 7.0 中，您可以使用安全性主機設定檔來設定鎖定模式並管理鎖定模式例外使用者清單。
- 將主機設定檔套用到叢集時，ESXi 主機中遺失增強型 vMotion 相容性 (EVC) 設定
當 VMware 組態檔 /etc/vmware/config 修改後，該組態檔中的某些設定不會由主機設定檔管理並且被加入了封鎖清單。因此，當主機設定檔套用到叢集時，EVC 設定會遺失，從而導致 EVC 功能缺失。例如，取消遮罩的 CPU 會向工作負載公開。
因應措施：重新設定叢集中的相關 EVC 基準以復原 EVC 設定。
- 在 vCenter Server 7.0 中使用定義核心傾印磁碟分割的主機設定檔會導致錯誤
在 vCenter Server 7.0 中，無法在主機設定檔中設定和管理核心傾印磁碟分割。嘗試套用定義核心傾印磁碟分割的主機設定檔時，會產生下列錯誤：找不到任何有效的核心傾印磁碟分割。
因應措施：無。在 vCenter Server 7.0 中，主機設定檔僅支援以檔案為基礎的核心傾印。
- 從 ESXi 主機複製主機設定檔或編輯主機設定檔時，使用者輸入值將會遺失
即使提供金鑰產生的明確規則，部分主機設定檔金鑰也會透過雜湊計算產生。因此，當您從主機複製設定或編輯主機設定檔時，回應檔案中的使用者輸入值將會遺失。
因應措施：在 vCenter Server 7.0 中，從 ESXi 主機複製主機設定檔或修改主機設定檔時，保留使用者輸入設定。
- 可能會拒絕由特定程式庫向 vSphere 發出的 HTTP 要求
vSphere 7.0 中的 HTTP 反向 Proxy 會強制執行比先前版本更嚴格的標準符合性。這可能會在應用程式用於對 vSphere 之 SOAP 呼叫的某些第三方程式庫中暴露預先存在的問題。
如果開發使用此類程式庫的 vSphere 應用程式或包括依賴 vSphere 堆疊中這類程式庫的應用程式，則當這些程式庫向 VMOMI 傳送 HTTP 要求時，您可能會遇到連線問題。例如，從 vijava 程式庫發出的 HTTP 要求會採用下列格式：
POST /sdk HTTP/1.1 SOAPAction Content-Type: text/xml; charset=utf-8 User-Agent: Java/1.8.0_221
此範例中的語法違反了必須在 SOAPAction 後使用冒號的 HTTP 通訊協定標頭欄位要求。因此，要求會在執行過程中遭到拒絕。
因應措施：在應用程式中使用不符合標準的程式庫的開發人員，可以考慮改用遵循 HTTP 標準的程式庫。例如，使用 vijava 程式庫的開發人員可以改為使用最新版本的 yavijava 程式庫。
- 在主機設定檔中編輯進階選項參數，並將值設定為 false 時，會導致將值設定為 true
在主機設定檔中嘗試將進階選項參數的值設定為 false 時，使用者介面會建立一個非空白字串值。非空白的值會轉譯為 true，而進階選項參數則會在主機設定檔中收到 true 值。
因應措施：有兩種可行的因應措施。
- 在參考 ESXi 主機上將進階選項參數設定為
false，並從此主機的主機設定檔中複製設定。
附註：主機必須符合主機設定檔，才能在主機上修改進階選項參數。
- 在參考 ESXi 主機上將進階選項參數設定為
false，並從此主機建立主機設定檔。然後將主機設定檔設定從新的主機設定檔複製到現有的主機設定檔。
- 在修復程序期間，主機設定檔會修改 SNMP 動態防火牆規則集
SNMP 防火牆規則集是動態狀態，在執行階段期間處理。套用主機設定檔時，規則集的組態會同時由主機設定檔和 SNMP 管理，這會導致非預期地修改防火牆設定。
因應措施：有兩種可行的因應措施。
- 若要允許規則集以動態方式管理本身，請在主機設定檔的組態中排除 SNMP 防火牆規則集選項。
- 若要繼續對規則集進行雙重管理，請在需要時更正防火牆規則集狀態。
- 使用 Broadcom 驅動程式 lsi_msgpt3、lsi_msgpt35 和 lsi_mr3 時，可能會看到傾印檔案
使用 lsi_msgpt3、lsi_msgpt35 和 lsi_mr3 控制器時，看到傾印檔案 lsuv2-lsi-drivers-plugin-util-zdump 會有潛在的風險。結束此外掛程式公用程式中使用的 storelib 時，會發生問題。不會對 ESXi 作業產生任何影響，您可以忽略此傾印檔案。
因應措施：您可以放心地忽略此訊息。您可以使用下列命令移除 lsuv2-lsi-drivers-plugin：
esxcli software vib remove -n lsuv2-lsiv2-drivers-plugin
- 在 vCenter 中配置 PCI 裝置的 SR-IOV 之後，您可能會看到不需要重新開機，但第三方延伸所進行的裝置組態可能會遺失，且需要重新開機才能重新套用。
在 ESXi 7.0 中，會套用 SR-IOV 組態而無需重新開機，且會重新載入裝置磁碟機。ESXi 主機可能具有第三方延伸執行在開機期間載入裝置磁碟機後需要執行的裝置組態。需要重新開機，這些第三方延伸才能重新套用裝置組態。
因應措施：您必須在設定 SR-IOV 後重新開機，才能套用第三方裝置組態。
