Re: [PATCH V9 00/46] Live Update

[Michael Galaxy]

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?


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

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?

- Michael


> - Steve