Re: [PATCH] Improve error propagation via return path

[Peter Xu <peterx@redhat.com>]

On Tue, Oct 21, 2025 at 05:54:09PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> On 21.10.25 17:34, Peter Xu wrote:
> > On Tue, Oct 21, 2025 at 07:52:53AM +0000, Dhruv Choudhary wrote:
> > > Use the return-path thread to send error details from the
> > > destination to the source on a migration failure. Management
> > > applications can then query the source QEMU for errors, as
> > > the single source of truth, making failures easy to trace.
> > > 
> > > Signed-off-by: Dhruv Choudhary <dhruv.choudhary@nutanix.com>
> > 
> > +Vladimir, Dan
> > 
> > IIUC we may still need to know whether the src QEMU supports this message
> > or not.
> > 
> > OTOH, we have introduced exit-on-error since 9.1:
> > 
> > # @exit-on-error: Exit on incoming migration failure.  Default true.
> > #     When set to false, the failure triggers a :qapi:event:`MIGRATION`
> > #     event, and error details could be retrieved with `query-migrate`.
> > #     (since 9.1)
> > 
> > This patch is going the other way.  That feature suggests the mgmt query
> > the error from dest directly.
> > 
> > We should stick with one plan rather than doing both.
> > 
> 
> Why?
> 
> exit-on-error=false is good anyway: when QMP connection is established, the
> management of target QEMU process is the same: we do call qmp commands to
> add devices, etc. We get QMP events. Actually, exiting is unexpected, better
> to fit into QMP protocol, continuing to send events and wait for qmp quit
> to exit.
> 
> Passing error back to the source simply improves error message on source,
> which otherwise is often confusing.
> 
> Using both, we of course see same error in two places.. But we do have two
> QEMU processes, which both handled by on-host managing services. We should
> correctly report error on both parts anyway.
> 
> Improving error messages on source is just and improvement, which makes
> current behavior better (with or without exit-on-error=false).
> 
> Removing exit-on-error=false semantics (with or without passing errors back)
> would be a step backward, to violating of QMP protocol by unexpected exits.

I didn't mean to propose removing exit-on-error, what I meant is when with
it this patch doesn't look like helpful.

Has libvirt been integrated with exit-on-error?  If so, IMHO we don't need
this patch anymore.  To me it's not an improvement when with exit-on-error,
because duplicating the error from dest to src makes it harder to know
where the error happened.

-- 
Peter Xu