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?
