Message ID | 20230926161841.98464-1-joao.m.martins@oracle.com |
---|---|
Headers | show |
Series | migration: Downtime observability improvements | expand |
On Tue, Sep 26, 2023 at 05:18:36PM +0100, Joao Martins wrote: > For now, mainly precopy data, and here I added both tracepoints and > QMP stats via query-migrate. Postcopy is still missing. IIUC many of those will cover postcopy too, but not all? I think the problem is postcopy didn't update downtime_start, however it updates MigrationState.downtime, and probably we can start to keep it more like precopy, e.g., in postcopy_start(), where downtime_start can be time_at_stop (or it can be more accurate; now it's probably fetching the timestamp too early). Basically if we want to expose anything, especially some qapi object, IMHO we'd better make it work for both pre/post copy because otherwise it'll be hard for mgmt app to know which qemu supports precopy only, and which support both (if we'll add that for postcopy too). Thanks,
On 04/10/2023 18:19, Peter Xu wrote: > On Tue, Sep 26, 2023 at 05:18:36PM +0100, Joao Martins wrote: >> For now, mainly precopy data, and here I added both tracepoints and >> QMP stats via query-migrate. Postcopy is still missing. > > IIUC many of those will cover postcopy too, but not all? > > I think the problem is postcopy didn't update downtime_start, however it > updates MigrationState.downtime, and probably we can start to keep it more > like precopy, e.g., in postcopy_start(), where downtime_start can be > time_at_stop (or it can be more accurate; now it's probably fetching the > timestamp too early). > Good point! > Basically if we want to expose anything, especially some qapi object, IMHO > we'd better make it work for both pre/post copy because otherwise it'll be > hard for mgmt app to know which qemu supports precopy only, and which > support both (if we'll add that for postcopy too). > Yeap, I totally agree.