OVF 部署失败: SHA1 digest of file SLM7-87-disk2.vmdk does not match manifest
问题描述：
在服务器上部署OVF模版，在进度达到100%之后报错，自动从服务器存储中删除已经部署的虚拟机相关信息，报错内容如下：
OVF 部署失败: SHA1 digest
of file 20151006.SLM7-87-disk2.vmdk does not match manifest
分析思路：
首先使用一些工具(如fciv或OVFTool)获得报错vmdk的sha1值 http://pan.baidu.com/s/1c1awtR6
操作步骤：
1、获得vmdk的sha1值
C:\Users\Dayonger\Desktop>fciv.exe -sha1 "H:\EonBackup\Pool-1_UserHome_vmware_S4
HANA_SolutionManager_20151006.SLM7-87\20151021_204012\20151006.SLM7-87-disk2.vmdk"
//
// File Checksum Integrity Verifier version 2.05.
//
ddac012d72a6c98a60191a9ae6c3b275fbaadc06 h:\eonbackup\pool-1_userhome_vmware_s4h
ana_solutionmanager_20151006.slm7-87\20151021_204012\20151006.slm7-87-disk2.vmdk
本次也附带生成了.ovf和vmdk1的sha1值，与.mf文件中对比了一下，和从服务器导出时的OVF模版生成的sha1值一样，而vmdk2的sha1值确实是和.mf文件中的不同。
2、修改.mf文件的sha1值，先把原先的.mf文件做一个备份
3、重新部署测试
批注：此外，有朋友提到可能是在导出虚拟机模版的时候没有选择"客户端设备选项"
选择和不选择该选项导出ovf模版的文件内容如下，明显多了一个镜像文件
所以说该情况由于导出 模版时候有镜像文件，导入的话也会需要镜像文件，而根据出现的报错信息SHA1 digest of file SLM7-87-disk2.vmdk does not match manifest明显不是此类情况。
疑惑：
是什么原因导致了vmdk的sha1值改变的？还需要进一步进行分析，也希望了解这方面的朋友多多指导。(也是本次发帖的重点)
补充：后续出现的问题
现在能够正常部署OVF虚拟机模版，但是部署之后出现些许问题，可能是由于(还只是猜测)之前对.mf文件中的sha1值做了修改，破坏了硬盘中的信息，一台虚拟机启动之后界面上只出现了 "GRUB_" 四个字符，无法加载系统启动程序；另一台虚机修改的是vmdk2中的sha1值，所以系统盘并未损坏，而另一块盘则开机会进行检查，当然可以在开机10s之内手动跳过该检查，那样是能够进入系统的，大致截图如下：
第一台虚机只有一块盘，对mf文件中的sha1值做了修改，开机界面：
第二块虚机有两块盘，系统盘vmdk1未做修改 (使用工具生成vmdk1的 sha1和起初导出OVF中mf文件内的vmdk1的 sha1值相同)：
虚拟磁盘空间有400GB，从01月15日中午到目前01月16日10：55，差不多更新检查了24小时，也是蛮拼的哈。
待后续找的解决方法会进行补充，也请大家提出宝贵意见，3Q
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/29634949/viewspace-1976891/ ，如需转载，请注明出处，否则将追究法律责任。
最新文章
- 手工删除卸载oracle 11g rac的具体步骤（方法）
- 启动数据库至open状态报错：ORA-03113: end-of-file on communication channel
- ORA-19870 ORA-19504 ORA-17502 ORA-15001 ORA-15040
- windows Server 2008管理员密码禁用了怎么处理
- Msg 3702:Cannot drop the database 'gcard' because it is currently in use.
- suse linux ssh远程无法访问问题
- VSAN 配置过程中遭遇"滑铁卢"
- Sybase RS 介绍
- Sybase中的APL与DOL表
- SUSE配置HANA出现需要升级gcc问题
