Re: [PATCH V9 00/46] Live Update

[Steven Sistare]

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.

>> 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

> Further, in many clouds (including ours), our VM-management is generational 
> with the
> development of the software versioning, so we *always* run tests and know 
> whether or not a VM is CPR-capable.
> 
> If it is not CPR-capable, we would never run the VM in the first place, which 
> means we would never
> really use that option at all.
> 
> I do see the appeal of the option, but could we simplify it, since it is 
> opt-in?