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?
