On Fri, Jul 17, 2026 at 11:10:46 +0200, lejeczek via Users wrote:
Hi guys.
I cannot start a domain - I wonder if the firmware, in xml, have anything to do with it or issue is different?
Jul 17 11:07:41 virtqemud[5658]: Unable to read from monitor: Connection reset by peer Jul 17 11:07:41 virtqemud[5658]: internal error: QEMU unexpectedly closed the monitor (vm='ubusrv2'): 2026-07-17T09:07:41.089484Z qemu-kvm: -blockdev {"node-name":"libvirt-2-format","read-only":false,"discard":"unmap","cache":{"direct":true,"no-flush":false},"driver":"qcow2","encrypt":{"format":"luks","key-secret":"libvirt-2-format-encryption-secret0"},"file":"libvirt-2-storage","backing":null}: Could not initialize refcount handling: Input/output error Jul 17 11:07:41 virtqemud[5658]: internal error: process exited while connecting to monitor: 2026-07-17T09:07:41.089484Z qemu-kvm: -blockdev {"node-name":"libvirt-2-format","read-only":false,"discard":"unmap","cache":{"direct":true,"no-flush":false},"driver":"qcow2","encrypt":{"format":"luks","key-secret":"libvirt-2-format-encryption-secret0"},"file":"libvirt-2-storage","backing":null}: Could not initialize refcount handling: Input/output error
Above happens with:
<os firmware='efi'> <type arch='x86_64' machine='pc-q35-rhel10.2.0'>hvm</type> <firmware> <feature enabled='no' name='enrolled-keys'/> <feature enabled='yes' name='secure-boot'/> </firmware> <loader readonly='yes' type='pflash' format='raw'>/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</loader> <nvram template='/usr/share/edk2/ovmf/OVMF_VARS.fd' templateFormat='raw' format='raw'>/var/lib/libvirt/qemu/nvram/ubusrv2_VARS.fd</nvram>
if I do not use EFI than domain starts, no above virtqemud errors, but guest does not boot, expectedly I think - I used to boot a ok.
That is weird. The error message specifically mentions the disk image as point of failure. But that doesn't really have anything to do with EFI firmware. The firmware image and nvram are instantiated via -blockdev though. The error message comes from qemu. There's exactly one code path that can create such error. Inside qemu it sepcifically comes from 'qcow2_do_open' when 'qcow2_refcount_init' returns failure. Inside of 'qcow2_refcount_init' only 'bdrv_co_pread' can return I/O error as errno. I'm not sure how that could happen. Did you update qemu recently?