qemu-img create 是创建可启动虚拟磁盘镜像最常用方式，支持 qcow2（动态扩容、快照）和 raw（性能优、兼容强）格式，指定容量为最大逻辑大小，实际初始体积极小；dd 用于扇区级完整复制含引导结构的镜像，需关机或 Live CD 下操作；mkfs + mount -o loop 适用于打包文件系统级镜像，需 root 权限并注意挂载/卸载完整性。
用 qemu-img create 创建可启动的虚拟磁盘镜像
这是最常用、最直接的方式，适用于 KVM/QEMU 环境下新建空白磁盘用于安装系统。生成的镜像可直接挂载、格式化、写入文件，或作为 -hda 启动参数传给 qemu-system-x86_64。
关键点在于格式选择和容量控制：
-
qcow2是首选：支持动态扩容（初始只占几KB）、快照、压缩、写时拷贝，适合开发/测试场景；但性能略低于raw -
raw格式无额外开销，I/O 性能最好，兼容性最强（可被dd、losetup、VMware 直接识别），但文件体积固定且无法快照 - 命令中指定的大小（如
20G）是“最大逻辑容量”，不是实际占用空间——qcow2镜像刚创建时通常只有 192KB
示例：
qemu-img create -f qcow2 ubuntu-dev.qcow2 20G
执行后检查：ls -lh ubuntu-dev.qcow2 会显示极小体积，而非 20G。
用 dd 创建全盘位级镜像（含分区表与引导区）
当你需要从物理机或已运行的系统完整复制（含 MBR/GPT、bootloader、所有分区结构），dd 是唯一可靠方式。它不做文件系统解析，纯粹按扇区复制，因此能保留启动能力。
常见错误现象：
- 直接
dd if=/dev/sda of=image.img时系统仍在运行 → 镜像内容不一致（尤其/boot或/正在写入）→ 启动失败或 fsck 报错 - 未对齐块大小导致速度极慢（默认
bs=512效率低下） - 未用
status=progress或pv监控进度，误以为卡死
安全做法：
- 必须在目标系统关机、Live CD 下操作，或至少卸载所有源分区（
umount /dev/sda1等） - 使用大块传输：
sudo dd if=/dev/sda of=disk.img bs=4M status=progress - 验证完整性：
sudo md5sum /dev/sda和md5sum disk.img对比（注意：仅当源设备未变化时成立）
用 mkfs + mount -o loop 构建文件系统级镜像
当你只需要打包一组文件（如嵌入式 rootfs、容器基础层、定制 initramfs），而非模拟整块硬盘，这种方式更轻量、可控性强。
流程本质是：创建空文件 → 格式化为 ext4/vfat → 挂载 → 复制文件 → 卸载。
容易踩的坑：
- 忘记
sudo：格式化和挂载都需要 root 权限 - 挂载后未
sync或umount就直接使用镜像 → 数据丢失或损坏 - 挂载选项遗漏
-o loop，系统报错special device xxx does not exist - 复制时未排除
/proc//sys//dev等虚拟文件系统 → 镜像无法清理或启动失败
示例（构建 1GB ext4 镜像）：
fallocate -l 1G rootfs.img<br>sudo mkfs.ext4 rootfs.img<br>mkdir -p mnt<br>sudo mount -o loop rootfs.img mnt<br>sudo cp -a /path/to/files/* mnt/<br>sudo umount mnt
镜像制作后必须验证的三个关键点
很多镜像看似生成成功，但在虚拟机里起不来，问题往往出在启动链上。
务必检查：
-
/etc/fstab中是否使用 UUID 挂载 root 分区：运行blkid rootfs.img查 UUID，确认/etc/fstab内容匹配（不能写成/dev/sda1这类设备名） - 是否存在 EFI 分区及
/boot/efi内容：若原系统是 UEFI 启动，镜像必须包含 ESP 分区且grubx64.efi存在，否则 QEMU 用-bios启动会黑屏 - 内核与 initramfs 是否完整：进入挂载后的镜像目录，检查
/boot/vmlinuz*和/boot/initrd.img*是否存在且非零字节
真正麻烦的从来不是“怎么生成文件”，而是“生成的文件能不能被正确识别并启动”。每次修改完镜像，建议用 qemu-system-x86_64 -hda your.img -m 1024 -nographic 快速验证能否进入 GRUB 菜单。
