On Wed, Feb 11, 2026 at 15:26:49 +0100, Ján Tomko wrote:
On a Thursday in 2026, Peter Krempa via Devel wrote:
From: Peter Krempa <pkrempa@redhat.com>
Strictly validating qemu replies and rejecting unknown values can have bad consequences in case qemu adds a new value.
Refactor the code parsing 'io-status' field from 'query-block' to be tolerant to new values to avoid failure.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> --- src/qemu/qemu_monitor.c | 42 -------------------------------- src/qemu/qemu_monitor.h | 3 --- src/qemu/qemu_monitor_json.c | 47 +++++++++++++++++++++++++++++++++--- 3 files changed, 43 insertions(+), 49 deletions(-)
[...]
@@ -2358,9 +2376,30 @@ qemuMonitorJSONGetBlockInfo(qemuMonitor *mon,
/* Missing io-status indicates no error */ if ((status = virJSONValueObjectGetString(dev, "io-status"))) { - info.io_status = qemuMonitorBlockIOStatusToError(status); - if (info.io_status < 0) - return -1; + int st = qemuMonitorBlockIOStatusTypeFromString(status); + + if (st < 0) { + VIR_WARN("Unhandled value '%s' of 'io-status' field in 'query-block' reply", + status);
VIR_DEBUG maybe? In case someone calls virDomainGetDiskErrors too often, this would get spammy.
Some other places in the monitor code where we process incoming values also use VIR_WARN. I'll leave it as _WARN for now and I'll have a look at a possibly more systematic solution which would avoid spam and still provide discoverability. Ideally the domain messages API would collect these but plumbing them out from the monitor code will be hard.