Re: [RFC PATCH v1 00/26] migration: File based migration with multifd and fixed-ram

[Fabiano Rosas <farosas@suse.de>]

David Hildenbrand <david@redhat.com> writes:

> On 30.03.23 20:03, Fabiano Rosas wrote:
>> Hi folks,
>> 
>> I'm continuing the work done last year to add a new format of
>> migration stream that can be used to migrate large guests to a single
>> file in a performant way.
>> 
>> This is an early RFC with the previous code + my additions to support
>> multifd and direct IO. Let me know what you think!
>> 
>> Here are the reference links for previous discussions:
>> 
>> https://lists.gnu.org/archive/html/qemu-devel/2022-08/msg01813.html
>> https://lists.gnu.org/archive/html/qemu-devel/2022-10/msg01338.html
>> https://lists.gnu.org/archive/html/qemu-devel/2022-10/msg05536.html
>> 
>> The series has 4 main parts:
>> 
>> 1) File migration: A new "file:" migration URI. So "file:mig" does the
>>     same as "exec:cat > mig". Patches 1-4 implement this;
>> 
>> 2) Fixed-ram format: A new format for the migration stream. Puts guest
>>     pages at their relative offsets in the migration file. This saves
>>     space on the worst case of RAM utilization because every page has a
>>     fixed offset in the migration file and (potentially) saves us time
>>     because we could write pages independently in parallel. It also
>>     gives alignment guarantees so we could use O_DIRECT. Patches 5-13
>>     implement this;
>> 
>> With patches 1-13 these two^ can be used with:
>> 
>> (qemu) migrate_set_capability fixed-ram on
>> (qemu) migrate[_incoming] file:mig
>
> There are some use cases (especially virtio-mem, but also virtio-balloon 
> with free-page-hinting) where we end up having very sparse guest RAM. We 
> don't want to have such "memory without meaning" in the migration stream 
> nor restore it on the destination.
>

Is that what is currently defined by ramblock_page_is_discarded ->
virtio_mem_rdm_is_populated ?

> Would that still be supported with the new format? For example, have a 
> sparse VM savefile and remember which ranges actually contain reasonable 
> data?

We do ignore zero pages, so I don't think it would be an issue to have
another criteria for ignoring pages. It seems if we do enable postcopy
load w/ fixed-ram that would be already handled in postcopy_request_page.