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

[David Hildenbrand]

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.

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

--
Thanks,

David / dhildenb