Re: [Qemu-devel] [PATCH v3 resend 7/8] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

On 07/22/2013 08:01 AM, mrhines@linux.vnet.ibm.com wrote:
> From: "Michael R. Hines" <mrhines@us.ibm.com>
> 
> As described in the previous patch, until now, the MIG_STATE_SETUP
> state was not really a 'formal' state. It has been used as a 'zero' state
> (what we're calling 'NONE' here) and QEMU has been unconditionally transitioning
> into this state when the QMP migration command was called. Instead we want to
> introduce MIG_STATE_NONE, which is our starting state in the state machine, and
> then immediately transition into the MIG_STATE_SETUP state when the QMP migrate
> command is issued.
> 
> In order to do this, we must delay the transition into MIG_STATE_ACTIVE until
> later in the migration_thread(). This is done to be able to timestamp the amount of
> time spent in the SETUP state for proper accounting to the user during
> an RDMA migration.
> 
> Furthermore, the management software, until now, has never been aware of the
> existence of the SETUP state whatsoever. This must change, because, timing of this
> state implies that the state actually exists.
> 
> These two patches cannot be separated because the 'query_migrate' QMP
> switch statement needs to know how to handle this new state transition.

This patch causes an issue with libvirt migration:

https://bugzilla.redhat.com/show_bug.cgi?id=1015636

> +    case MIG_STATE_SETUP:
> +        info->has_status = true;
> +        info->status = g_strdup("setup");
> +        break;

You are now returning a state that older libvirt versions are not
expecting.  Obviously, we can patch newer libvirt to make migration work
again, but should we be thinking about damage control by stating that an
older management app should still be able to drive migration on a new
qemu?  Or is it acceptable to state that newer qemu requires newer
management tools?

If we try to support this working under older management tools, maybe
the approach is that we have to add some new migration capability; newer
management tools set the capability to true and are therefore allowed to
see the new state name; older management tools do not set the capability
and when that is the case we guarantee that we do not return a state
string that the older tool is not expecting.  Thoughts on whether we
should pursue this?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]