Re: [PATCH V9 00/46] Live Update

[Michael Galaxy <mgalaxy@akamai.com>]

  Good morning,

On 7/10/23 10:10, Steven Sistare wrote:
> On 6/12/2023 10:59 AM, Michael Galaxy wrote:
>> Hi Steve,
>> On 6/7/23 12:37, Steven Sistare wrote:
>>> On 6/7/2023 11:55 AM, Michael Galaxy wrote:
>>>> Another option could be to expose "-migrate-mode-disable" (instead of enable) and just enable all 3 modes by default,
>>>> since we are already required to switch from "normal" mode to a CPR-specific mode when it is time to do a live update,
>>>> if the intention is to preserve the capability to completely prevent a running QEMU from using these modes
>>>> before the VM starts up.
>>>>
>>>> - Michael
>>>>
>>>> On 6/6/23 17:15, Michael Galaxy wrote:
>>>>> Hi Steve,
>>>>>
>>>>> In the current design you have, we have to specify both the command line parameter "-migrate-mode-enable cpr-reboot"
>>>>> *and* issue the monitor command "migrate_set_parameter mode cpr-${mode}".
>>>>>
>>>>> Is it possible to opt-in to the CPR mode just once over the monitor instead of having to specify it twice on the command line?
>>>>> This would also match the live migration model: You do not need to necessarily "opt in" to live migration mode through
>>>>> a command line parameter, you simply request it when you need to. Can CPR behave the same way?
>>>>>
>>>>> This would also make switching over to a CPR-capable version of QEMU much simpler and would even make it work for
>>>>> existing libvirt-managed guests as their command line parameters would no longer need to change. This would allow us to
>>>>> simply power-off and power-on existing VMs to make them CPR-capable and then work on a libvirt patch later when
>>>>> we're ready to do so.
>>>>>
>>>>>
>>>>> Comments?
>>> Hi Michael,
>>>     Requiring -migrate-enable-mode allows qemu to initialize objects
>>> differently, if necessary, so that migration for a mode is not blocked.
>>> See callers of migrate_mode_enabled.  There is only one so far, in
>>> ram_block_add.  If the mode is cpr-exec, then it creates anonymous ram
>>> blocks using memfd_create, else using MAP_ANON.  In the V7 series, this
>>> was controlled by a '-machine memfd-alloc=on' option.
>>>
>>> migrate-enable-mode is more future proof for the user.  If something new must
>>> initialize differently to support cpr, then it adds a call to migrate_mode_enabled,
>>> and the command line remains the same.  However, I could be persuaded to go either way.
>> OK, so it is cpr-exec that needs this option (because of ram block allocation), not really cpr-reboot.
>> Could the option then be made to only be required for cpr-exec and not cpr-reboot, then,
>> since cpr-reboot doesn't require that consideration?
> In a different forum Juan said this is a memory issue, so it should be expressed
> as a memory related option.  So, I will delete -migrate-enable-mode and revert back
> to -machine memfd-alloc, as defined in the V7 patch series.

Acknowledged. I'm going to try to get my reviewed-by's in soon. Sorry I 
haven't done it sooner.

We've finished testing these patches on our systems and are moving forward.


>>> A secondary reason for -migrate-enable-mode is to support the only-cpr-capable
>>> option.  It needs to know which mode will be used, in order to check a
>>> mode-specific blocker list.
>> Still, only-cpr-capable is also optional. If and only if one needs this option, the mode could be
>> specified as part of the option itself, rather than requiring an extra command line parameter, no?
> Yes, I will make that change.
>
> - Steve

Acknowledged.