Re: [PATCH 0/2] migration: include timing and RAM stats on destination when query-migrate

[Peter Xu <peterx@redhat.com>]

On Thu, Apr 16, 2026 at 11:53:55PM +0700, Trieu Huynh wrote:
> Hello Peter,

Hi, Trieu,

> One specific use case where the source is completely unavailable is loading 
> from a migration snapshot (non-live).
> In this scenario, there is no active source QEMU to query_for_stats. The 
> dst (IMHO) is the only entity that can report how long the loading took 
> and how much data was actually processed from the snapshot file.
> This use case is a little bit niche but still a valid one though, isn't it?

Yes it's in general valid, but it also depends.  There's a reason that QEMU
supported load snapshot over the years and nobody was asking for it.  I
believe it's because people simply don't need it.

Load snapshot, unlike generic form of live migration, doesn't have much
uncertainty on its own.  It should either succeed after a while, or fail
with an error.  People should not expect to need to query anything.

It will likely, and should, hold true even if with async load snapshot in
the future.

It is only valid in that it might be useful for developers who works on
snapshot, especially tuning the performance.  But then it also means we
shouldn't expose it to an user API (QMP is in this case).  For dev only
reportings, we should rely on trace points unless we have good reason to
make it visible to users.

In general, we don't need to add unnecessary API maint burden to ourselves
when not needed.

Thanks,

-- 
Peter Xu