我的 VMware ESX 服务器控制台卷变为只读。 如何保存我的虚拟机？
两个 RAID 卷，VMware 内核/控制台在 RAID1 上运行，vmdks 在 RAID5 上运行。 在控制台输入登录名只会导致 SCSI 错误，不会提示密码。 值得称赞的是，虚拟机实际上仍在运行。 不过，我们认为，重新启动后，内核可能不会再次启动，并且虚拟机将关闭。
我们有虚拟机的数据库和磁盘备份，但没有 vmdk 本身的备份。
我有什么选择？
我们当前最好的想法是
- 使用 VMware Converter 从正在运行的虚拟机创建实时 vmdks，就像 P2V 迁移一样。
- 重新启动主机服务器并运行 RAID 诊断，找出“h”中发生的情况
- 尝试再次启动 ESX，可能是在重建其 RAID 卷之后
- 可能必须在其卷上重新安装 ESX 并重新附加虚拟机
- 如果这不起作用，将步骤 1 中创建的“实时”vmdks 连接到不同的 VM 主机。
Two RAID volumes, VMware kernel/console running on a RAID1, vmdks live on a RAID5. Entering a login at the console just results in SCSI errors, no password prompt. Praise be, the VMs are actually still running. We're thinking, though, that upon reboot the kernel may not start again and the VMs will be down.
We have database and disk backups of the VMs, but not backups of the vmdks themselves.
What are my options?
Our current best idea is
- Use VMware Converter to create live vmdks from the running VMs, as if it was a P2V migration.
- Reboot host server and run RAID diagnostics, figure out what in the "h" happened
- Attempt to start ESX again, possibly after rebuilding its RAID volume
- Possibly have to re-install ESX on its volume and re-attach VMs
- If that doesn't work, attach the "live" vmdks created in step 1 to a different VM host.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是背板。 RAID1 的两个驱动器和 RAID5 的一个驱动器均无法访问。 令人难以置信的是，VMware 虚拟机管理程序在内存中持续运行三天，无法访问其主机磁盘，从而使其管理的虚拟机保持活动状态。
在上面的步骤 3 中，我们诊断了硬件问题并更换了 RAID 控制器、电缆和背板。 重新启动后，我们通过指示控制器查询驱动器的配置来重新初始化 RAID。 两者均已退化，但均已成功修复。
在步骤 4 中，无需重新安装 ESX； 尽管在启动时，它不想注册虚拟机。 我们必须挖掘一些隐藏的管理内容来指示内核对虚拟机进行重新签名。 （在虚拟机文档中搜索“重新签名”。）
我相信我们的后备计划会起作用，运行“孤立”的虚拟机的 VMware Converter 映像经过测试并且运行良好，没有数据丢失。 我强烈建议在关闭尽可能多的服务并使虚拟机进入尽可能只读状态后，对进入此状态的任何虚拟机执行 VMware Converter 映像。 在其他地方或在原始主机上加载 vmdk 作为修复通常比使用备份从头开始重建服务器要快得多。
It was the backplane. Both drives of the RAID1 and one drive of the RAID5 were inaccessible. Incredibly, the VMware hypervisor continued to run for three days from memory with no access to its host disk, keeping the VMs it managed alive.
At step 3 above we diagnosed the hardware problem and replaced the RAID controller, cables, and backplane. After restart, we re-initialized the RAID by instructing the controller to query the drives for their configurations. Both were degraded and both were repaired successfully.
At step 4, it was not necessary to reinstall ESX; although, at bootup, it did not want to register the VMs. We had to dig up some buried management stuff to instruct the kernel to resignature the VMs. (Search VM docs for "resignature.")
I believe that our fallback plan would have worked, the VMware Converter images of the VMs that were running "orphaned" were tested and ran fine with no data loss. I highly recommend performing a VMware Converter imaging of any VM that gets into this state, after shutting down as many services as possible and getting the VM into as read-only a state as possible. Loading a vmdk either elsewhere or on the original host as a repair is usually going to be WAY faster than rebuilding a server from the ground up with backups.