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. qemu-img shows no issues. Any thoughts? many thanks, L.
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?
Yes I did - now I've downgraded - 10.1.0-24.el10 seems baaaddd! This is a very serious issue - if not from the code's point of view - it is to end-users. "broken" version is available to the public (centos at least) from default repos. This Qemu, has certainly fucked up my not so perfect composure. 10.1.0-23.el10 seems good.
On Fri, Jul 17, 2026 at 13:50:43 +0200, lejeczek via Users wrote:
Yes I did - now I've downgraded - 10.1.0-24.el10 seems baaaddd! This is a very serious issue - if not from the code's point of view - it is to end-users. "broken" version is available to the public (centos at least) from default repos. This Qemu, has certainly fucked up my not so perfect composure. 10.1.0-23.el10 seems good.
That is indeed unfortunate. Please report this to the qemu mailing list. Include versions where it's broken and where it's fixed as well as the commandline including all devices.
participants (2)
-
lejeczek -
Peter Krempa