Hi, Joao, On Tue, Sep 26, 2023 at 05:18:40PM +0100, Joao Martins wrote: > Deliver the downtime breakdown also via `query-migrate` > to allow users to understand what their downtime value > represents.
I agree downtime is an area we definitely need to improve.. however do we need to make it part of qapi? Or do we need them mostly for debugging purpose? Any introduction of motivation of this work, especially on exporting the values to the mgmt apps? > > Signed-off-by: Joao Martins <joao.m.mart...@oracle.com> > --- > qapi/migration.json | 22 ++++++++++++++++++++++ > migration/migration.c | 14 ++++++++++++++ > 2 files changed, 36 insertions(+) > > diff --git a/qapi/migration.json b/qapi/migration.json > index 2d91fbcb22ff..088e1b2bf440 100644 > --- a/qapi/migration.json > +++ b/qapi/migration.json > @@ -217,6 +217,27 @@ > 'data': [ 'start', 'stop', 'precopy-iterable', 'precopy-noniterable', > 'resume-return-path' ] } > > +## > +# @DowntimeStats: > +# > +# Detailed migration downtime statistics. > +# > +# @stop: Time taken to stop the VM during switchover. > +# > +# @precopy: Time taken to save all precopy state during switchover. > +# > +# @precopy-iterable: Time taken to save all precopy iterable state. > +# > +# @precopy-noniterable: Time taken to save all precopy non iterable state. > +# > +# @resume-return-path: Time taken to resume if return path is enabled, > +# otherwise zero. All these fields will more or less duplicate the ones in the other MigrationDowntime just introduced. We suffer from duplicated fields for migration parameters, proof shows that dropping the duplication is normally harder.. I'm trying to dedup the existing Migration*Parameter* objects and still in progress, so even if we want to expose downtime in qapi I hope we can expose only one and single object. IIUC we can already do that by keeping DowntimeStats, keeing an object in MigrationState, and just drop MigrationDowntime? Thanks, -- Peter Xu
