必须先确认hypervisor状态：esxi用vim-cmd vmsvc/getallvms验证hostd运行，kvm用virsh list --all检查libvirtd连接；若失败则先启动服务而非直接操作vm，避免因驱动、存储、网络未就绪导致恢复失败。
虚拟化宿主机崩溃后，先确认 Hypervisor 状态再动系统
宿主机一崩，所有虚拟机都停摆，但恢复顺序不能从 VM 开始。必须先验证 Hypervisor 本身是否存活、能否接管资源。比如在 ESXi 上，vim-cmd vmsvc/getallvms 能列出已注册的虚拟机；KVM 环境下运行 virsh list --all，如果命令卡住或报 connection refused，说明 libvirtd 进程没起来，得先 systemctl start libvirtd，而不是急着 virsh start 某个 VM。
常见错误是跳过这步直接进救援模式挂载 VM 磁盘修配置——结果发现宿主机连桥接网卡都没加载，br0 不存在，iptables 规则全丢，修了 VM 配置也起不来。
- ESXi：检查 DCUI（Direct Console User Interface）界面是否显示 “Hostd started” 或 “Management agents running”
- KVM：确认
/proc/sys/net/bridge/bridge-nf-call-iptables是 1，否则虚拟网络转发失效 - 云平台自建 KVM：留意
dnsmasq是否随libvirtd自启，否则 VM 启动后拿不到 DHCP 地址
启动顺序不是“先内核再服务”，而是“先设备驱动再存储栈再网络”
宿主机恢复后，别急着 systemctl start 任何服务。Linux 在虚拟化场景下，systemd 的依赖链常被硬件抽象层打断。比如 RAID 卡驱动没加载，/dev/md0 就不会出现，后续所有挂载 /mnt/data 的服务都会超时失败，但日志里只写 Dependency failed for Local File Systems，不提根本原因。
实操建议按以下顺序手动触发关键单元：
- 先等
systemd-udev-settle.service完成（或用udevadm settle），确保所有块设备节点就位 - 运行
lsblk -f看 LVM / md / ZFS 池是否激活；若否，手动vgchange -ay或zpool import -a - 检查
systemctl status systemd-networkd，确认br0或ovs-system已 up；否则virsh net-start default会静默失败 - 最后才
systemctl start libvirtd，且观察journalctl -u libvirtd -n 50 --no-pager里有没有Failed to connect to storage pool
VM 启动失败时，别只看 guest 日志，先查宿主机的 dmesg 和 libvirt 域日志
一个典型现象：VM 在 virsh start 后立刻变成 shut off，virsh console 连不上，journalctl -u libvirtd 只有 domain event 'stopped'。这时候翻 guest 里的 /var/log/messages 毫无意义——问题根本不在里面。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
真正该查的是：
-
dmesg -T | grep -i "kvm\|vfio\|iommu"：确认 CPU 是否开启虚拟化（svm或vmx）、IOMMU 是否启用（影响直通设备） -
cat /var/log/libvirt/qemu/<vm-name>.log</vm-name>：里面通常有 QEMU 启动时的完整参数和报错，比如qcow2: Image is corrupt; cannot be opened read/write -
virsh domstate <vm-name> --reason</vm-name>：返回具体终止原因，如crashed、panicked或shutdown
特别注意：某些旧版 libvirt 在存储池路径含空格或中文时会静默失败，virsh pool-dumpxml 输出里若看到 或乱码路径，就得重定义池。
自动恢复策略要区分“重启即恢复”和“需人工干预”的边界
很多人给 VM 配 on_crash = restart 或 on_reboot = restart，以为能兜底。但实际中，90% 的 VM 崩溃不是 guest 内部问题，而是宿主机资源不足或存储中断。盲目自动重启只会让磁盘 I/O 队列雪崩，甚至触发宿主机 OOM Killer 杀掉 kswapd 进程，形成死循环。
更稳妥的做法是分层设置：
- 对数据库类 VM：禁用自动重启，改用
on_crash = preserve，保留内存镜像供事后virsh dump分析 - 对无状态 Web VM：设
on_reboot = restart，但加startup_delay = 30，错开启动时间避免并发 IO 峰值 - 所有 VM 的
memoryBacking必须配hugepages=1和locked=1，否则宿主机内存紧张时，qemu-kvm进程会被 swap 出去，导致 VM 假死
最易被忽略的一点：libvirtd 自身的 RestartSec=10 在 systemd 里默认是关闭的。一旦它因 cgroup 内存限制被 OOM Killer 干掉，就不会自动拉起——得手动在 /etc/systemd/system/multi-user.target.wants/libvirtd.service 里补上 Restart=always 和 RestartSec=5。
