esxi重启后，虚拟机状态竟然无效?升级成功后，有故障?

原创已于 2025-07-27 12:01:09 修改 · 1.2k 阅读

19 ·

CC 4.0 BY-SA版权

文章标签：

#esxi #服务器 #虚拟机状态无效

于 2025-07-20 21:21:54 首次发布

esxi主机重启后，虚拟机的状态无效？升级成功后，有故障?

临时修复无效虚拟机方法
 原因告知

事情起因

公司三台esxi主机，需要用vcenter纳管，方便后面可能的资源共享或者做HA，vcenter要求纳管的主机esxi版本最好保持一致，才能不给后续的功能埋下隐患
三台esxi主机，其中两台是esxi7.0,一台是esxi8.0,决定升级esxi7.0—>8.0
注意：这里犯了一个大忌！！！！！！！！！！！
第一个大忌
跨大版本升级是大部分情况下不可取！！！！，你无法预料升级完成后会有什么问题
第二个大忌
升级esxi版本之前一定一定一定要和厂商进行沟通，请他们评测是否具备升级的条件，确认他们内部是否有测试过升级这个版本
万分不幸，以上两个我都犯了!!!

故障初现

我顺利将两台esxi升级到8.0后，周一上班，同事反应虚拟机卡顿，编译一个代码需要很久，甚至打开vim都需要等2s（离大谱），这是我万万没有想到的，以至于到后面，卡的都不能用了。。。。。。滴汗、心跳加速、手心冒汗、紧张，一拥而上
但是还是要解决问题，所以，遇到的时候要稳住，千万要稳住，告诉自己一定能解决（考验你抗压能力的时候到了… 哭😭）

穿插一下如何升级esxi主机

简单的说一下升级的步骤吧，网上一找一大堆的
1.确定你要升级的版本，然后去网上下载这个包，一般是.zip结尾的升级包
2.将下载的包上传到需要升级的esxi主机上，不要解压这个包哈
3.然后找个没人的时间进行升级哈，将虚拟机全部关机，记得给虚拟机做快照!! , 然后将esxi主机置于维护模式，打开esxi主机的SSH功能
4.ssh连接到esxi主机上，查看zip包里需要升级的版本
esxcli software sources profile list -d /vmfs/volumes/xx/xx/patch-file.z
5.一条命令进行升级
esxcli software profile update -d /vmfs/volumes/xx/xxxxx-depot.zip -p xxxxx-standard
这里的 -p 后面跟的就是第四步查出来的包的名字，
6.回车升级，等待稍许时间，没什么问题就回看到输出一大段内容，出现successfully就是成功，然后reboot机器，即可。

处理故障

处理卡顿我是一处理一个不吱声，压根无从下手
首先怀疑是不是快照导致的卡顿，因为过多多大快照也会影响性能，好，那就删快照，删完了后，重启，还是废了，不行。。。还是卡顿
然后怀疑是不是同时编译的人太多了，导致的卡顿，但是升级之前也没有这个问题啊，所以也排除这个可能
最后，联系厂商，打听这台服务器支持8.0吗？他们说内部只测试过7.0 和7.0.1U,没测试过8.0，让我回滚试试，可能升级后不兼容。
好，那我就回滚，殊不知，这才是噩梦的开始。。。。。。。。

穿插一下如何回滚esxi主机的版本

其实回滚很简单
1.虚拟机关机，做好快照备份，置于主机为维护模式.
2.通过带外管理界面（或者你直接到机房接上显示到服务器上都行），我是通过带外管理界面远程控制的。
3.按F12，输入用户名密码，然后按照提示重启
4.重启的时候，你只要看到那个黄色的界面，有进度条啥的，就立马按Shift + r ，然后就能看到屏幕上有之前的版本。
5.然后按 Y （大写的Y哦）即可，等待系统重启进入，完成回滚。

噩梦来临

本来梦想着回滚完成后就正常了，但是还是卡顿。。
但这都不是最重要的，最重要的是esxi主机起来后，进入web管理页面准备启动虚拟机，靠！发现虚拟机状态是无效，最关键的是我的虚拟机是做了快照的，但是那个列表里的虚拟机无法点击啊，点了没反应啊。

这当时一下子就懵逼了，没遇到过哇。
开始翻阅资料，折磨AI
…
…
关键是两个虚拟机都是无效的，这两个虚拟机都是最重要的两个，数据无价！

艰难求索之路

后面查阅资料，猜测是由于虚拟机开启了打开电源自启动的功能，所以才导致的无效。
本身，这个自启动是没有问题的（其实我觉得这个功能可有可无，用的不恰当很容易造成好心办坏事的情况）
我的虚拟机的本身数据量就很大（6T,4T的等）、而且有四五个虚拟机，
每个虚拟机都开启了自启动，在启动过程中，有的虚拟机成功自启动起来了。有的没起来。
我有90%的把握可以说，是由于自启动设置的等待时间造成的后果。
为什么呢？，神奇就神奇在这里了
我们知道，esxi主机启动的时候，也就是机器加电的时候，当esxi一些服务启动完毕后，具备启动虚拟机条件后，虚拟机就会尝试自启动，如果此时，你有多个虚拟机都设置了自启动，但是没有设置他们之间的启动顺序，也就是说，他们会在同一时间内都争夺启动权，争夺启动资源，这样势必会造成错误，这个虚拟机一看自己尝试很多次没起来，就以为是元配置文件的磁盘坏了，就会尝试用最近的快照启动，但是还是不行，这样就死转，最后造成无效的状态。

所以，有多个虚拟机，务必务必务必请设置启动顺序。
最后，我的建议是，能不开启自启动就不开启，坑！！！！

临时修复无效虚拟机方法

虚拟机此刻无效，先做的是要恢复业务
1.重新新建一个虚拟机，内存、cpu都和原本的一致，硬盘先不要添加。
2.新建好的虚拟机，点击编辑设置，点击添加硬盘，选择添加现有硬盘
3.从数据浏览器里找到原本（无效）的虚拟机目录下的vmdk文件（如果你之前做了快照，那肯定有很多vmdk文件，快照的名称一般是000001这样的，选择原有的vmdk文件，不要选择快照文件。）
注意：我这个是系统盘和数据盘是分开的，一共是两个硬盘，所以我添加两块，建议先添加系统盘，先启动，看是否可以启动，如果可以，再添加另外一块数据硬盘
如果你只有一块盘符，既是系统盘也是数据盘，那就添加一块就行。
到此，应该是先恢复业务了。
但是这样的后患就是，同事前一天的数据就不见了（但也比全部丢了强…）

其实后面就是按照这个方法恢复的业务，但是因为我之前做过快照，我就想把这个快照恢复到这个新的虚拟机里去，或者其他方法能恢复就成，but,我和同事一起研究了很久很久，都没能搞定，所以很沮丧，如果有哪位大佬看见了鄙人这篇不才的文章，看到此处，若有解决之道，劳烦评论区指点一二，先在此谢过了（抱拳）！不胜感激…

话说到最后，这个卡顿目前还没解决，目前的方案是：怀疑升级、回退esxi主机，导致里面的虚拟机的系统可能有损坏，或者其他什么原因，所以目前的方案是：
重新建立虚拟机，安装新系统，然后挂载数据盘即可。
后续如果有效果，我会在此告知。

原因告知：
后续查明原因了，是因为vscode的插件导致的，很多人同时使用vscode的插件，利用top命令查看后台的进程，属于vscode的进程很多，且都占据了不小的内存，特别是c/c++插件，他会在每次修改文件或者打开的时候，重新建立索引，这样是一个耗费IO的操作，导致正常编译的活动出现卡顿。