On Fri, May 15, 2026 at 11:45:02 -0500, Ian Pilcher wrote:

I am working on a disk burn-in utility, and I'd like to use qemu's blkdebug driver to simulate disk errors.

I've added the qemu namespace to my domain.

<domain xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0" type="kvm">

I've set an alias for my SCSI controller.

<controller type="scsi" index="0" model="virtio-scsi"> <driver queues="4" iothread="1"/> <alias name="ua-scsi0"/> <address type="pci" domain="0x0000" bus="0x07" slot="0x00" function="0x0"/> </controller>

And I've added the qemu command-line options.

<qemu:commandline> <qemu:arg value="-blockdev"/> <qemu:arg value="{"driver":"host_device","filename":"/dev/ram0","node-name":"ram-backend","cache":{"direct":true,"no-flush":false},"discard":"unmap"}"/> <qemu:arg value="-blockdev"/> <qemu:arg value="{"driver":"raw","file":"ram-backend","node-name":"raw-layer"}"/> <qemu:arg value="-blockdev"/> <qemu:arg value="{"driver":"blkdebug","config":"/var/lib/libvirt/images/test.conf","image":"raw-layer","node-name":"debug-disk"}"/> <qemu:arg value="-device"/> <qemu:arg value="scsi-hd,drive=debug-disk,id=scsi0-0-0-1,wwn=0x5000c50030000001,logical_block_size=4096,physical_block_size=4096,bus=ua-scsi0.0,channel=0,scsi-id=0,lun=1"/> </qemu:commandline>

When I try to start the VM, I get this.

Error starting domain: internal error: process exited while connecting to monitor: 2026-05-15T16:42:46.891789Z qemu-system-x86_64: -blockdev {"driver":"host_device","filename":"/dev/ram0","node-name":"ram-backend","cache":{"direct":true,"no-flush":false},"discard":"unmap"}: Could not open '/dev/ram0': No such file or directory

/dev/ram0 definitely exists, and is owned by qemu:qemu.

By default libvirt creates a per-VM mount namespace for the /dev/ filesystem and populates only known/used device nodes into it. Unfortunately with the "<qemu:arg" override we do not know what devices that could use. Thus this way /dev/ram0 indeed isn't present in the /dev/ filesystem presented to the qemu VM.

Google Gemini tells me that this is some sort of security feature, but it hasn't been able to suggest a non-janky way to work around it. (To

So unfortunately we don't currently have a way to add these per-VM. We could add them similarly under the "qemu" XML namespace as you've used the 'arg' elements above but that currently doesn't exist. Thus any change you do will apply to all VMS In /etc/libvirt/qemu.conf you can add /dev/ram0 to cgroup_device_acl. Alternatively you can also disable the "mount" namespace isolation for VMs which will have the same effect. Note that also none of the libvirt security driver intergrations (apparmor, selinux, dac) will apply proper seclabels on the /dev/ entry, so you must ensure that the user (and security label) that your QEMU process runs under can access the device.

me, changing the global libvirt configuration, rando trigger scripts, or creating some sort of redundant fake drive all fall into the janky category.)

Is there really not a clean way to do this?

Unfortunately there isn't one that would be per-VM. As noted it should be viable to add something to the qemu namespace, but nobody yet integrated such a thing.