* Daniel P. Berrangé ([email protected]) wrote: > On Thu, Jun 09, 2022 at 12:07:31PM +0200, Claudio Fontana wrote: > > Hello all, > > > > it would be really good to be able to rely on this command or something > > similar, > > to be able to know the approximate size of a migration before starting it. > > > > in QEMU ram_bytes_total() returns what I would like to have, > > but there is currently no QMP way to get it without starting a migration, > > which when trying to optimize it/size it is just about too late. > > Aside from the main VM RAM, what other RAM blocks are likely to have > a size large enough to be of consequence to the live migration > data copy, and whose size is not already known to the mgmt app from > the guest config choices it made ? VGA RAM could be a few 100MB I > guess, but the mgmt app knows about that. I've always assumed everything > else is just noise in comparison to the main RAM region. > > Still I wonder how useful this is as its just a static figure, and the > problems with migration transfer are the bulking up of data when the > VM is repeatedly dirtying stuff at a high rate. > > > Do you think x-query-ramblock could be promoted to non-experimental? > > It would have to be re-written, as this current impl is just emitting > a huge printf formatted string. To be considered supportable, the data > would have to be formally modelled in QAPI instead. > > IOW, it would be a case of introducing a new command that emits formal > data, convertintg 'info ramblock' to use that, and then deprecating this > x-query-ramblock. > > > Should another one be made available instead, like : > > query-ram-bytes-total ? > > That would be simpler if you're just wanting it to give a single > figure.
Is this what qmp_query_memory_size_summary does? Dave > > With regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| > -- Dr. David Alan Gilbert / [email protected] / Manchester, UK
