文中涉及的ISO介质:
en_windows_server_2019_x64_dvd_3c2cf1202.iso
en_windows_server_2016_x64_dvd_9718492.iso
WINDOWS.X64_193000_grid_home.zip
WINDOWS.X64_193000_db_home.zip
VMware-VMvisor-Installer-6.7.0.update03-14320388.x86_64.iso
VMware-VIM-all-6.7.0-14070457.iso
HomeLab升级到ESXi 6.7之后重新基于Guest OS Windows 2019部署RAC 19c环境时发现一直失败。安装任务停留在ACFS 14 of 19(该过程出现在执行gridConfig.bat脚本)的地方。做法与原来相同,轻车熟路、自检过程也都是passed,排查错误代码都是网上那些套话,根本找不到入手地方。


尝试了单节点的ASM + ORACLE也会报错,但是报错位置不同,skip后可以安装成功,Database也能安装成功。
仔细想想ESXi 6.7与6.5对于Windows Server 2019 vm的影响,无非是vmtools版本、虚拟机模板、虚拟机兼容性。
仔细查看错误日志(”C:\app\root\crsdata\rac21\crsconfig\rootcrs_rac21_2020-02-18_04-20-24PM.log”)中提到了os function一块儿出现错误,隐约感觉不支持2019系统。

那为什么ESXi 6.5上的Windows Server 2019没有问题呢?感觉和虚拟机模板有关,在esxi 6.5上并没有2019的原生模板,只能选择就近的ws 2016模板,而到了esxi 6.7上虚拟机模板变成了如下:

现在觉得原来esxi 6.5上的2019实际上一直被强制识别成2016在工作。

方法一:将虚拟机换成了真正的Windows 2016同时降低了虚拟机兼容性到6.5,效果如预期猜想一样,顺利通过了14 of 19的过程,完成了GI的安装:




方法二:
单独降低guest os的兼容性,注意该兼容性一旦确定后只能升级,不能降级。


总结一下,VMware上的花样还真多!现在回想一下Oracle的说法:
“Oracle has not certified any of its products on VMware virtualized environments. Oracle Support will assist customers running Oracle products on VMware in the following manner: Oracle will only provide support for issues that either are known to occur on the native OS, or can be demonstrated not to be as a result of running on VMware.”
就是这么任性!顺便说一下,Oracle支持自己家的VirtualBox部署RAC。