May 2026 - Users - libvirt List Archives

How to use qemu's blkdebug driver (can't see backing device)
by Ian Pilcher 18 May '26

18 May '26

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. 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 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? -- ======================================================================== If your user interface is intuitive in retrospect ... it isn't intuitive ========================================================================

2 1

virt-viewer cage full screen tty issues
by Bram Diederik 08 May '26

08 May '26

my .profile is filled with scripts like this. pasted below. it allows a full screen desktop with out any other screens. at a dedicated tty. but it has two issues. If there already is an connection i need to kill everuthing on the tty. And sometimes when i pkill -9 -t tty9 switch from client system the keyboard and mouse dont work. they do work after i rebooted the VM. I dont google stuff deeply and make it my self if i cant find it right away. So i might be doing it wrong. anyway some one can help me with the two issues. ps one bash question. I have an exit. but a right placed ctrl C can break to prompt i dont want that does some one know how i always run the program or exit to logout state. Cheers. bram if [[ "$(tty)" == "/dev/tty10" ]]; then export XDG_RUNTIME_DIR=/run/user/$(id -u)/cage10 while true; do # start agent if needed [ -z "$SSH_AUTH_SOCK" ] && eval "$(ssh-agent -s)" >/dev/null # load key if needed ssh-add -l >/dev/null 2>&1 || ssh-add ~/.ssh/id_rsa mkdir -p "$XDG_RUNTIME_DIR" chmod 700 "$XDG_RUNTIME_DIR" # Run virt-viewer cage -s -- virt-viewer \ --domain-name vision \ -c "qemu+ssh://bram@jack/system?ssh_compression=yes" \ --attach -f \ --auto-resize=always sleep 2 done exit fi

1 0

virt-host-validate should warn about false positives
by therandshow＠gmail.com 04 May '26

04 May '26

virt-host-validate seems to sometimes complain about freezer support on machines with cgroups v2 where it doesn't matter, it also reports lack of devices cgroup if the user isn't running as root. Ideally, it should report N/A on freezer support for cgroups v2 or just PASS because it has validated that it wasn't necessary. Or maybe just have a warning at the bottom, failure for the freezer cgroup only applies to cgroups v1 For devices cgroup, a warning if the user is running not as root and the test fails, you may need elevated privileges to check cgroup 'devices' or something along those lines. Or failing to put it in the output, it would be nice if these facts were more prominent in a troubleshooting page

2 2