Okay, so I'm trying to figure out whether this QEMU bug is related to user-mode or system-mode. The problem is that when using the -blockdev option along with -snapshot, the snapshot isn't working as expected. Instead of changes being written to a temporary file, they're going directly to the disk image. First, I remember that in QEMU, snapshots can be used to create point-in-time images without modifying the original disk. The -snapshot option usually creates a temporary file where any changes are stored until you commit them or shut down the VM. The user provided steps to reproduce: they run QEMU with -blockdev and -snapshot, make a change (create test.txt), power off the guest, then restart and find that test.txt is still present. This suggests that the snapshot didn't capture the changes temporarily but wrote them directly. When they switch from using -blockdev to the legacy -drive option, the snapshot works fine. So the issue seems tied to how blockdev handles snapshots compared to drive. I need to think about what's different between -blockdev and -drive in QEMU. The blockdev options are part of the newer device model and allow more flexibility, including using block devices with different backends or configurations. Maybe there's a missing parameter when using blockdev that tells QEMU to use a snapshot. Looking into how QEMU handles snapshots: with -snapshot, it creates a QCOW2 file by default if not specified otherwise. The problem arises because the changes are going to the base image instead of a temporary one. This might be due to the way the block device is configured when using -blockdev without specifying where the snapshot should be stored. Perhaps with -blockdev, you need an additional parameter to specify that it's a snapshot. Maybe something like node-name or a driver option that tells QEMU to create a snapshot file instead of modifying the base image directly. In contrast, the legacy -drive might automatically handle this when combined with -snapshot, ensuring that any writes go to a temporary file and not the original disk. So the bug is likely in how the blockdev configuration interacts with the snapshot option. It's possible that the -blockdev setup doesn't correctly apply the necessary settings for snapshots, leading QEMU to bypass the temporary storage and write directly. Since this involves device configurations and how QEMU handles block devices at a lower level, it seems like a system-mode issue. System-mode bugs typically involve hardware emulation, device drivers, and deeper OS interactions. system