On Wed, Jan 07, 2026 at 04:41:09PM +0530, Prasad Pandit wrote: > On Tue, 6 Jan 2026 at 20:39, Peter Xu <[email protected]> wrote: > > Copying Dan and Jiri in case ... > > * Thank you for copying. > > >> } else if (s->current_state == ACTIVE && s->trigger == > >> 'error-occurred') { > >> s->current_state = STOP > >> s->reason = "Error occurred, migration failed" > > > > We can't change status that were already used, like FAILED. Libvirt and > > all mgmt may rely on it. > > * True; If we decide to go in that direction, we'll have to tell > libvirtd(8) and others about new states. > > > Personally I don't see much benefit on adding a new "trigger" internal API. > > If we want to forbid some state machine transitions, we can use a > > transition map. Said that, IMHO it's separate from what we're discussing > > here. > > * If we can reduce/rationalise the current 17-18 states and related > complexity, it'll help to simplify things.
Personally I still don't see the benefit of doing so. I agree MIGRATION_STATUS_CANCELLING isn't a must to have, but since we have it already and libvirt should treat it almost the same as ACTIVE we don't have problem with it either. It doesn't sound like a big issue. I don't see how we can shrink the rest of status otherwise, or what would you propose for removal? Thanks, -- Peter Xu
