Re: [PULL 15/18] qapi: introduce x-query-ramblock QMP command

[David Hildenbrand <david@redhat.com>]

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