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 <[email protected]> > > > > +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
