systemctl restart libvirtd 会强制终止所有 QEMU 进程，导致虚拟机瞬间断电，因其向 libvirtd 发送 SIGTERM 并触发默认 KillMode=control-group 的清理逻辑；而 systemctl reload libvirtd 仅重载配置，不中断 QEMU 子进程，虚拟机持续运行。
可以平滑重启 libvirtd，但必须用 systemctl reload libvirtd，而不是 restart —— 后者会强制终止所有 QEMU 进程，导致虚拟机瞬间断电。
为什么 systemctl restart libvirtd 会杀掉虚拟机
libvirtd 是管理进程，不是虚拟机本身；QEMU 进程由 libvirtd 启动后即独立运行。但 restart 会向 libvirtd 发送 SIGTERM，触发其默认的“清理子进程”逻辑（尤其在未禁用 KillMode 的 systemd 配置下），最终调用 kill -9 强杀所有它 spawn 过的 QEMU 进程。
- 现象：
ps aux | grep qemu突然清空，virsh list显示全空，宿主机 dmesg 出现qemu-kvm[PID]: segfault或Process 'qemu' killed - 根本原因：systemd 默认
KillMode=control-group，且 libvirtd 未显式设置KillMode=process - 影响范围：所有通过 libvirt 启动的 KVM 虚拟机（包括
virsh start、virt-install、OpenStack nova 启动的实例）
systemctl reload libvirtd 的实际行为
reload 不重启主进程，只重新加载配置（如 /etc/libvirt/libvirtd.conf、/etc/libvirt/qemu.conf 中的监听地址、认证方式、日志级别等），QEMU 子进程完全不受影响，虚拟机继续运行，网络和磁盘 I/O 持续正常。
- 适用场景：修改了
listen_tls = 1、auth_unix_rw = "polkit"、log_filters = "1:remote 2:libvirt"等运行时可重载项 - 不生效的配置：涉及进程模型变更的（如
max_clients调整需 restart）、存储池或网络定义变更（这些是 XML 对象，reload 不触碰） - 验证是否成功：
sudo journalctl -u libvirtd --since "1 minute ago" | grep "Reloading config"
哪些操作看似安全实则危险
别被表象迷惑 —— 有些命令看起来只是“重载”，实际底层仍会中断连接或重建状态。
-
kill -SIGHUP $(pgrep libvirtd)：旧版 libvirt（ -
systemctl force-reload libvirtd：等价于先 stop 再 start，和 restart 一样危险 - 修改
/etc/libvirt/qemu.conf后执行virsh shutdown再start：虽然虚拟机没丢，但业务有停机窗口，不算“平滑” - 直接
systemctl restart libvirtd+ 依赖auto_start=1：恢复的是关机态，不是保存态；虚拟机不会自动 resume，而是 cold boot
真正需要重启时的最小中断方案
如果必须 restart（例如升级 libvirt 包、启用 TLS 证书、修复 auth 模块崩溃），可用 libvirt-guests 配合手动保存来压降影响。
- 提前启用自动保存：
echo "ON_SHUTDOWN=suspend" >> /etc/sysconfig/libvirt-guests（RHEL/CentOS）或对应发行版配置文件 - 执行前手动触发一次保存：
virsh list --state-running --name | xargs -r -n1 sh -c 'virsh managedsave "$1" --verbose' _ - 确认保存完成：
ls /var/lib/libvirt/qemu/save/有对应.save文件，且virsh list仍显示running - 再执行
systemctl restart libvirtd，之后虚拟机会自动从保存状态 resume（前提是auto_start=1且managedsave文件未被清理）
注意：managedsave 不是快照，不保留磁盘状态；若虚拟机正在写入关键数据，仍可能因内存状态恢复滞后导致应用层不一致 —— 这类场景应协调业务侧做可控停机。
