From: Peter Krempa <[email protected]>

While we don't normally try to re-wrap errors to be more descriptive,
probing of qemu capabilities is a special case as the errors can be
cryptic and don't give users enough information about what's going on.
An example is (obtained from a patched qemu which accidentally returned
a broken QMP schema):

  $ virsh start VM
  error: Failed to start domain 'VM'
  error: internal error: Duplicate hash table key 'str'

The error is unusable. On the other hand in 'virQEMUCapsLogProbeFailure'
we do special logging of the caps probing failure with a custom UUID so
that it can be easily found in the logs which reports a much better
error message. Re-raise the same as a normal error too so that the user
gets similar experience:

  $ virsh start VM
  error: Failed to start domain 'VM'
  error: internal error: Failed to probe capabilities for 
/home/user/git/qemu.git/build/qemu-system-x86_64: internal error: Duplicate 
hash table key 'str'

This does mean though that the error is logged twice, once via the
custom log entry and second via 'virReportError'. Given that this error
is extremely unlikely, having two log entries IMO doesn't warant
reworking the whole error reporting infra to allow passing extra
metadata just for this one case.

Signed-off-by: Peter Krempa <[email protected]>
---
 src/qemu/qemu_capabilities.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index a28f87ad2b..be57dcad8e 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -6065,6 +6065,10 @@ virQEMUCapsLogProbeFailure(const char *binary)
                   meta,
                   _("Failed to probe capabilities for %1$s: %2$s"),
                   binary, virGetLastErrorMessage());
+
+    virReportError(VIR_ERR_INTERNAL_ERROR,
+                   _("Failed to probe capabilities for %1$s: %2$s"),
+                   binary, virGetLastErrorMessage());
 }


-- 
2.54.0

Reply via email to