Re: [Qemu-devel] [PATCH] migration: Introduce MIGRATION_STATUS_FINISHING

[Pavel Fedin <p.fedin@samsung.com>]

 Hello!

> adding new user-visible states
> has a tendency to break existing clients that aren't prepared for
> unexpected states (although technically such bugs are in the client - in
> the past, libvirt used to be one such client, although we've tried to
> fix it to gracefully ignore unknown states).

 Yes, i know this, my host uses libvirt v1.2.9.3 (i backport necessary patches to it) and it barfed. I didn't check master though...

>  Are we sure no other
> existing state works for this?  I'm not opposed to the addition, just
> wanting to make sure we have good reason for it.

 You know, actually, this is a thing only for qemu's internal use, we don't need a new state at all. Instead, we could introduce a 'bool cpus_stopped' to MigrationState structure and test for it in migration_in_finishing(), like:
--- cut ---
bool migration_in_finishing(MigrationState *s)
{
    return s->cpus_stopped;
}
--- cut ---
 What do you think about this solution? It is much less complicated than...

> One design idea for adding new states is making sure the new state will
> not be exposed unless the client specifies some new option to enable the
> state, so that old clients will never see the state and new clients have
> expressed their interest in the state

 With this kind of approach we would not be able to migrate ITS without this option. Because it's not external clients being interested in this state at the moment, but qemu itself.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia