On 09.06.22 12:19, Daniel P. Berrangé 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 ?
With virtio-balloon free page hinting and virtio-mem, that number does not reflect reality (IOW, with sparse ramblocks the total size of ramblocks is not expressive; it's rather a "worst case"). -- Thanks, David / dhildenb
