Gabes Virtual World 06月11日 22:55
Same EVC level, still no VMotion
index_new5.html
../../../zaker_core/zaker_tpl_static/wap/tpl_guoji1.html

 

本文分享了解决VMware跨vCenter VMotion失败的经验。由于需要节省Microsoft SQL许可证,作者决定将两个不同vCenter的VMware集群合并。尽管集群处于相同的Westmere EVC级别,但VMotion仍然失败。通过升级ESXi版本、测试和与VMware支持团队合作,作者最终发现了问题所在:在集群中存在ESXi 6.5u1主机时,Westmere EVC级别会屏蔽“cpuid.SSBD”功能。最终,将所有主机升级到6.5u2解决了问题,VMotion成功运行。

💡问题背景:为了节省Microsoft SQL许可证,作者计划合并两个不同vCenter的VMware集群。尽管集群处于相同的Westmere EVC级别,但跨vCenter VMotion操作失败。

🔍问题诊断:作者最初尝试将目标主机升级到与源主机相同的ESXi 6.5u2版本,但VMotion仍然失败。经过与VMware支持团队的合作,发现问题与集群中ESXi 6.5u1主机的存在有关。

💡根本原因:当集群中存在ESXi 6.5u1主机时,Westmere EVC级别会屏蔽“cpuid.SSBD”功能,导致VMotion失败。通过测试,作者验证了这一发现。

✅解决方案:最终的解决方案是将集群中的所有主机升级到ESXi 6.5u2版本。升级后,跨vCenter VMotion操作成功运行,问题得以解决。

To save on Microsoft SQL licenses, we decided to merge two VMware Clusters into one. The clusters were in different vCenters and the source Cluster was running ESXi 6.5u2 and the target cluster was ESXi 6.5u1. Both clusters were at the same Westmere EVC Level but a Cross vCenter VMotion failed with “The target host does not support the virtual machine’s current hardware requirements.”. . . To resolve CPU incompatibilities, use a cluster with Enhanced vMotion Compatibility (EVC) enabled. See KB article 1003212.”.

Reading the release notes on 6.5u2 and with some input from this blogpost: “VMotion fails to migrate VMs between ESXi hosts which have the same configuration” I concluded that I should bring the target host to the same 6.5u2 build as the source host. So I upgrade on host in the target cluster to 6.5u2.

Testing in a new cluster

Unfortunately, the Cross vCenter VMotion still failed. Together with VMware Support we discovered that as long as there is one 6.5u1 host in the cluster, the Westmere EVC level masks the “cpuid.SSBD” feature. I performed the following test: Create new cluster, put in a 6.5u2 host and set the EVC to Westmere. Setup a SSH session into the host and run the following command:

vim-cmd hostsvc/hostconfig | grep -E -A1 “SSBD|IBPB|STIBP|IBRS”

Snippet of the output:

     key = "cpuid.SSBD",     featureName = "cpuid.SSBD",     value = "1"

You can now see that the CPUID.SSBD feature is enabled (1). The Cross vCenter VMotion now worked.

Next I added an older 6.5u1 host to the cluster and on the newer (6.5u2) host I again ran the vim-cmd and saw that it had changed the CPUID.SSBD value to disabled (0). The Cross vCenter VMotion didn’t work.

When removing the older 6.5u1 host from the cluster the CPUID.SSBD feature didn’t change on the 6.5u2 host, but when I set the EVC to NONE and then changed it back to Westmere, the host had the CPUID.SSBD feature enabled again.

Solved

So the solution to my issue was to just upgrade all the host in the cluster to 6.5u2 and Cross vCenter VMotion worked without issues. Looking back at this issue it is of course logical what happened, but I would have expected somehow that there may have been a better indication that the 6.5u2 EVC differs a little from the same EVC level in 6.5u1.

See full post at: Same EVC level, still no VMotion

Fish AI Reader

Fish AI Reader

AI辅助创作,多种专业模板,深度分析,高质量内容生成。从观点提取到深度思考,FishAI为您提供全方位的创作支持。新版本引入自定义参数,让您的创作更加个性化和精准。

FishAI

FishAI

鱼阅,AI 时代的下一个智能信息助手,助你摆脱信息焦虑

联系邮箱 441953276@qq.com

相关标签

VMware VMotion EVC ESXi 虚拟化
相关文章