On 07/22/2013 08:01 AM, mrhi...@linux.vnet.ibm.com wrote: > From: "Michael R. Hines" <mrhi...@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
signature.asc
Description: OpenPGP digital signature