虚拟机物理重启前，必须先确认数据已持久化、服务已优雅停止、快照/备份已就位，再检查宿主机资源与存储状态，否则极可能损坏虚拟磁盘或导致启动失败。
虚拟机物理重启前必须确认哪些关键步骤？先看这份检查清单
物理重启和虚拟机重启完全是两码事,虚拟机重启只是客户机操作系统的重启，而物理重启意味着宿主机断电再上电，整个虚拟化层都会经历一次冷启动，这时候，所有运行中的虚拟机都会失去内存态，所有未落盘的写入会直接消失。虚拟机物理重启前必须确认的事项，本质上是在回答一个问题：当前的环境能不能承受一次全量冷启动。
数据持久化状态：先让系统“消化”完写入
最容易忽略的是客户机内存里的脏页和磁盘缓冲,别指望虚拟机里的应用已经把数据都写到磁盘了，很多数据库、消息队列为了让性能好看，会先写内存再异步刷盘，物理重启一瞬间，这些数据就没了，所以你需要确认：
- 执行
sync命令，强制刷新文件系统缓冲区，注意，sync只对已挂载的文件系统有效，扛不住崩溃级断电。 - 在客户机里优雅关闭数据库或中间件服务,比如
systemctl stop mysqld或/etc/init.d/postgresql stop，让应用自己完成缓冲刷盘和日志落盘。 - 检查
/var/log/messages或事件日志里有没有块设备IO错误，如果有，说明底层存储已经不稳定，这时候物理重启会放大风险。
服务依赖关系：别让主机关机变成连锁事故
一台宿主机上往往跑了多台虚拟机,它们之间有外部依赖，比如一台虚拟机是NFS服务端，另一台挂载它的目录；或者一台是数据库，另一台是Web应用，物理重启会把所有客户机同时杀掉，依赖方会瞬间失去连接，恢复时如果没有按顺序启动，就可能出现服务拒绝连接、表空间未挂载、锁未释放等问题，建议提前确认：
- 记录各虚拟机的启动顺序,在宿主机重启后按依赖关系依次启动。
- 确认有没有客户机配置了开机自启,如果有，检查自启脚本里有没有等依赖服务的逻辑。
- 确认分布式存储（比如Ceph、VSAN）的健康状态，如果宿主机也是存储节点，物理重启可能导致OSD离线，需要等集群完成数据重平衡后再启动虚拟机。
快照与备份：你的后悔药够不够用
物理重启属于高影响操作,不能裸奔，至少在重启前做一次临时快照或增量备份，不需要全量，但必须有最近的可恢复点，行业共识认为，物理重启前没有快照的虚拟机，一旦起不来，恢复成本会成倍上升，具体做法：
- VMware环境：在vCenter里对虚拟机右键，选“快照”->“生成快照”，只勾选虚拟机内存和磁盘，等待完成。
- KVM环境：使用
virsh snapshot-create-as命令创建磁盘快照，或利用qemu-img做层叠快照。 - Hyper-V环境：在检查点菜单里选择“生产检查点”，并确保集成服务已启用。
如果宿主机本身有灾备任务,尽量错开物理重启时间，避免备份窗口和重启窗口重叠。
虚拟机强制重启会不会丢数据？风险边界要清楚
很多运维人员分不清强制重启和物理重启的区别,实际上这是两个不同的风险级别。虚拟机强制重启指的是在客户机内执行reboot -f，或者通过宿主机的virsh destroy、vCenter的“关闭虚拟机电源”操作，这相当于给虚拟机拔电，而不是物理拔掉宿主机电源。
强制重启和正常重启的区别
正常重启会让操作系统走完关机流程：关闭文件系统、卸载设备、停止服务，强制重启则跳过这些步骤，区别如下：
| 对比维度 | 正常重启 | 强制重启 |
|---|---|---|
| 文件系统缓存 | 会同步并卸载 | 直接丢弃 |
| 数据库日志 | 走检查点 | 可能未做检查点 |
| 虚拟磁盘完整性 | 风险较低 | 可能损坏元数据 |
| 启动速度 | 较慢 | 较快 |
在大多数情况下,现代虚拟机文件系统没有太大问题，因为虚拟磁盘本质是文件，底层通常有日志或写时复制保护，但如果是独占磁盘裸设备映射，或者使用了精简置备的稀疏文件，强制重启后出现数据块丢失的概率就会明显增加。
哪些情况可以接受强制重启
- 客户机已经完全无响应,SSH、控制台都无法操作，正常重启超时。
- 宿主机内存不足,虚拟机处于不可中断的D状态，卡住内核进程。
- 已经确认该虚拟机是无状态应用,比如临时计算节点、测试环境。
如果确定要强制重启,务必在宿主机上先检查虚拟机的磁盘IO是否空闲，命令是virsh domstats或iostat，如果IO很忙，等一会儿再操作，能降低数据丢失风险。
虚拟机重启前要检查什么：一套可复用的操作流程
下面这套流程适用于大多数虚拟化平台,按顺序执行，能覆盖绝大多数风险点。
第一步：登录检查系统负载
不要直接在宿主机上重启,先进入虚拟机内部看状态：
- 执行
uptime，看系统负载是否过高，如果1分钟负载大于CPU核数，说明系统很忙，强制重启可能导致进程数据丢失。 - 执行
df -h检查磁盘空间，如果根分区使用率超过90%，重启后系统可能无法正常启动，或者启动过程因写临时文件失败而卡住。 - 执行
free -h看内存是否耗尽，如果Swap占用高，说明部分内存页还在交换区，重启会把这些交换内容清空，相关进程的数据也会丢。
第二步：优雅关闭或迁移
尽量使用平台提供的优雅关闭接口,而不是直接在物理机上按电源键，具体操作：
- VMware ESXi：通过vCenter执行“关闭客户机操作系统”，或者用命令行
vmware-rpcclient触发客户机关机。 - KVM：使用
virsh shutdown vm-name，该命令会向客户机发送ACPI关机信号，让客户机走正常关机流程。 - Hyper-V：使用
Stop-VM -Name "vm-name" -Save先把内存状态保存到磁盘，再进行物理重启。 - XenServer：使用
xe vm-shutdown vm=vm-name。
如果虚拟机数量较多,可以考虑迁移，只需要在物理重启前执行
virsh migrate --live vm-name target-host，把虚拟机热迁移到其他宿主机，这样这台物理机重启就不会影响业务，部分高级许可的虚拟化平台支持无停机迁移，使用前确认存储是否共享。
第三步：确认宿主机状态
虚拟机都关闭或迁移后,再检查宿主机自身：
- 在宿主机上执行
sync，刷新宿主机文件系统缓存。 - 执行
esxcli system shutdown poweroff -d 10（VMware）或systemctl poweroff（Linux KVM宿主机），确保关机流程正确。 - 检查硬件告警灯,比如BMC/IPMI面板上是否有红色告警，如果内存或RAID卡亮了黄灯，物理重启后可能直接起不来，需要先报修。
- 如果宿主机连接了SAN存储,在重启前确认光纤通道链路是否正确，HBA卡没有报错，用
fc-list或esxcli storage san查看状态。
关于虚拟机物理重启的常见问题解答
问：物理重启后虚拟机启动不了，常见原因有哪些？
最常见的原因是虚拟磁盘文件被锁或损坏,检查宿主机上对应虚拟机的.vmdk或qcow2文件是否存在锁文件，在VMware里查看任务栏是否有未完成的任务；在KVM里执行virsh list --all看域状态，如果状态是“paused”，尝试virsh resume恢复，检查虚拟机的BIOS启动顺序是否被重置，特别是UEFI引导的虚拟机，物理重启后可能因NVRAM变量丢失而找不到引导设备。
问：物理重启后虚拟机里的数据库怎么恢复？
确认数据库文件所在磁盘是否完整,以MySQL为例，重启后先查看/var/lib/mysql下的.ibd和.frm文件是否存在，尝试用innodb_force_recovery模式启动，设置innodb_force_recovery=1，跳过损坏页检查，但只能作为临时手段，恢复完成后要立即备份并正常重启，PostgreSQL则使用pg_controldata检查控制文件状态，如果显示“database system was interrupted”，可以使用pg_resetwal重置预写日志，但此法会丢失未提交事务。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/622245.html
