On 1/8/25 16:38, Jim Fehlig wrote:
Happy new year everyone! One resolution I have is to revive this
topic and
strive to get the feature merged :-).
On 8/8/24 17:37, Jim Fehlig wrote:
> This series is essentially V1 of a prior RFC [1] to support QEMU's
> mapped-ram stream format [2] and migration capability. Along with
> supporting mapped-ram, it implements a design approach we discussed
> for supporting parallel save/restore [3]. In summary, the approach is
>
> 1. Add mapped-ram migration capability
> 2. Steal an element from save header 'unused' for a 'features'
variable
> and bump save version to 3.
IIRC, the work stalled while looking for agreement on this part of the approach.
It's implemented in patch7, and there I asked about using the 'format' field
of
SaveImageHeader, instead of introducing another field
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/
NV4E4O2STJQU7F52RFHWLE52C42NX75E/
In fact, after looking again with fresher eyes, I'm wondering if adding a new
'format' is enough? I.e., add a new element to virQEMUSaveFormat enum. An older
libvirt would refuse to process an image saved with the new format. This should
allow us to avoid bumping the save version, which in turn avoids the version
control knob in qemu.conf. Defaulting to mapped-ram would be a matter of
changing the existing 'save_image_format' from 'raw' to 'sparse'
(or whatever we
want to call it).
Does this seem reasonable? Have I forgot about something since this work stalled?
FYI, I've been adjusting the series according to this proposal. Looks good so
far. I wont be able to work on it tomorrow, but should have an updated patchset
posted soon.
Regards,
Jim