* Eduardo Habkost (ehabk...@redhat.com) wrote: > On Tue, Apr 20, 2021 at 12:51:43PM +0100, Dr. David Alan Gilbert wrote: > > * Eduardo Habkost (ehabk...@redhat.com) wrote: > > > On Mon, Apr 19, 2021 at 07:47:34PM +0100, Dr. David Alan Gilbert wrote: > > > > * Daniel P. Berrangé (berra...@redhat.com) wrote: > > > > > On Mon, Apr 19, 2021 at 06:15:56PM +0100, Daniel P. Berrangé wrote: > > > > > > On Mon, Apr 19, 2021 at 06:11:47PM +0100, Dr. David Alan Gilbert > > > > > > wrote: > > > > > > > * Eduardo Habkost (ehabk...@redhat.com) wrote: > > > > > > > > I would make live migration policy an enum, just to make sure > > > > > > > > we are explicit about the requirements: > > > > > > > > > > > > > > > > - UNKNOWN: this is the current state in QEMU 6.0, where we don't > > > > > > > > really know what the user expects. > > > > > > > > This can be the default on existing versioned machine types, > > > > > > > > just for compatibility. > > > > > > > > I suggest making this print warnings for every migration > > > > > > > > blocker (like this patch does). > > > > > > > > I suggest deprecating this behavior as soon as we can. > > > > > > > > > > > > > > > > - PREFERRED: try to make the VM migratable when possible, but > > > > > > > > don't print a warning or error out if migration is blocked. > > > > > > > > This seems to be the behavior expected by libvirt today. > > > > > > > > > > > > > > > > - NOT_NEEDED: live migration is not needed, and QEMU is free to > > > > > > > > enable features that block live migration or change guest ABI. > > > > > > > > We can probably make this the default on machine types that > > > > > > > > never supported live migration. > > > > > > > > > > > > > > I suggest you could do this by adding: > > > > > > > -warn-none-migratable > > > > > > > -no-warn-none-migratable > > > > > > > > > > > > > > and then argue about defaults another time. > > > > > > > > > > > > If we're going to add new args, lets at least future proof our > > > > > > approach with an extensible option that we can wire into QMP > > > > > > too later > > > > > > > > > > > > -migratable none|preferred|required > > > > > > > > > > > > and letting us add extra key/value pairs to tune it if desired. > > > > > > > > > > Having said that, we potentially don't need a dedicated arg if we > > > > > just make 'migratable=none|preferred|required' be a property of > > > > > the machine type and hook everything off that > > > > > > > > I think my only difficulty with that is that I don't find any of those > > > > 3 words 'obvious'. > > > > > > Any suggestions of replacements for those 3 words? > > > > > > Would the descriptions below be enough to clarify their meaning > > > in documentation? > > > > I prefer things that are fairly obvious without needing to look at the > > documentation until you want the detail. > > > > > - NONE: live migration is not needed, and device or machine code > > > is allowed to enable features that block live migration or > > > change guest ABI. > > > (Not implemented yet) > > > > > > - PREFERRED: machine and device code should try to make the VM > > > migratable when possible, but won't emit a warning or error out > > > if migration is blocked. > > > (Current default behavior) > > > > > > - REQUIRED: live migration support is required, and adding a > > > migration blocker will be an error. > > > (Implemented today by --only-migratable) > > > > How about > > -migratable blocked > > Live migration is not allowed; an outbound migration will fail > > "none" and NOT_NEEDED above were about letting QEMU automatically > enable features that block live migration or change guest ABI. > > If that's implied by "blocked", I'd like to get that documented > explicitly. If that's not implied by "blocked", I don't > understand what's the use case for "blocked".
My 'blocked' is stronger - migration is hard disabled by a blocker always; it's for (rare) cases where the user wants to stop a migration happening, even if qemu believes it can do it. > > > > -migratable allowed > > Live migration is allowed, but some devices/options may block > > it if they're unable to migrate [current default] > > "preferred" above was about QEMU trying to keep live migration > working as much as possible. That's something we all expect QEMU > to do, but it's not documented anywhere. > > If that's implied by "allowed", I'd like to get that documented > explicitly. If that's not implied by "allowed", then we have a > problem. My difficulty by your definition is I don't understand what 'working as much as possible' means - that's the current behaviour as I understand it. I think mine is more explicit. > > > > > -migratable warn > > Live migration is allowed, but if some device/option is > > unable to migrate, migration will be blocked and a warning > > printed > > This makes sense, but I don't think we need to support this use > case. I thought that was exactly what Vitaly's patch tried to do? > > > > -migratable required > > Live migration is allowed, attempting to add a device or > > enable an option that can't migrate will fail. [--only-migratable] > > This matches "required" above. Dave > -- > Eduardo -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK