kvm虚拟机内挂载块设备失败时，若内核已识别设备但/dev下缺失节点，可手动用mknod创建：先通过lsblk或cat /sys/block/vdb/dev确认主次设备号（如252:16），再执行sudo mknod /dev/vdb b 252 16并设置权限，最后用fdisk -l或blkid验证；此为临时方案，应优先修复udev或virtio_blk模块问题。
确认设备是否已被虚拟机内核识别
不能凭设备名猜测编号。先验证内核是否真正“看见”了这块盘：
- 运行 lsblk 或 cat /proc/partitions，查找目标设备（如 vdb），记录其主设备号（MAJ）和次设备号（MIN）
- 检查 /sys/block/vdb/dev 是否存在且可读：执行
cat /sys/block/vdb/dev，输出形如 252:16，即主号 252、次号 16 —— 这是唯一可信来源 - 若
/sys/block/vdb/不存在，说明 virtio-blk 未初始化或驱动未加载，此时mknod无效，应先运行lsmod | grep virtio_blk并必要时modprobe virtio_blk
在虚拟机内执行 mknod 创建节点
进入虚拟机终端（非宿主机），以 root 身份操作：
- 创建设备文件：
sudo mknod /dev/vdb b 252 16（将 252 和 16 替换为上一步查到的实际值） - 设置标准权限与属组：
sudo chown root:disk /dev/vdb && sudo chmod 660 /dev/vdb - 如需挂载分区（如 vdb1），再创建：
sudo mknod /dev/vdb1 b 252 17（次设备号 = 主号 + 分区序号，vdb1 通常为 17）
验证节点是否真正可用
仅文件存在不等于设备就可访问：
- 运行
file /dev/vdb，应返回 block special file - 执行
sudo fdisk -l /dev/vdb或sudo blkid /dev/vdb，确认能读出容量、分区表或文件系统信息 - 若报错 Operation not permitted，检查是否启用了 SELinux/AppArmor；若提示 Cannot open，可能是虚拟机启动时未启用
sys_admincapability（KVM QEMU 启动参数需含-device virtio-blk-pci,...且 guest 内核配置支持）
这不是长久之计，要修复根本原因
手动创建的节点在重启后消失，且易出错。生产环境应优先排查自动机制：
- 确认虚拟机内 udev 是否运行：
systemctl is-active systemd-udevd；若非 active，启用它或改用 devtmpfs（多数现代发行版默认启用） - 手动触发扫描：
sudo udevadm trigger --subsystem-match=block && sudo udevadm settle - 检查 virtio 设备绑定状态：
lspci | grep -i virtio，确保设备出现在 PCI 列表中 - 若使用自定义 initramfs 或最小化系统（如 Alpine、CoreOS），需确认其 init 脚本是否挂载了
devtmpfs到/dev—— 缺失则 udev 无法工作，mknod是唯一临时手段
