Re: [Qemu-devel] [RFC 0/7] Optional toplevel sections

[Eric Blake <eblake@redhat.com>]

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

On 10/15/2014 09:59 AM, Juan Quintela wrote:

>> Do we need a new monitor command that says to put the
>> guest into the same state that migration said it should be in (and the
>> command fails if migration was from an older source that did not send
>> the subsection)?
> 
> I think that you don't need the command.
> Target is started "paused" (-S) or "running" (nothing).

Libvirt will _always_ pass -S.  This is because there is a need for
additional handshaking from destination back to source to let the source
know that the destination is ready to take over operation.

> 
> 
> source old: target old: no changes
> source old: target new: the same as now, no changes
> source new: target new: we set the right state.  And if it is not
> "running" we don't run on destination, independent of what is happening.
> source new: target old: if source is in state "running" or "paused", no
>                         change.  If source is in error state, we sent
>                         the section and migration gets aborted (target
>                         don't understand it)
> 
> source new: target new, running with old machine type:
> if state is "running" or "paused", nothing is sent.
> if state is "error", target is set to "error".
> 
> So, I think that we get all the cases possible right, no?

Only if the existing 'cont' is changed to do something other than put
the destination into 'running', which doesn't sound good; or if we add
some new way for the destination to resume to the state passed in migration.

> 
> 
>> How can libvirt introspect that the destination qemu is new enough to
>> understand the subsections, and/or that the source qemu is new enough to
>> send the subsections?
> 
> A new qemu_option value would make for you?

Or even the existence of a new QMP command in parallel to 'cont' that
has semantics of 'please restore this guest to the state it had on
incoming migration'.

> If you use libvirt, and you *don't* need to do anything special to run
> after migration, you shouldn't use -S.  And I would emit an event saying
> "migration was finished".
> 

No, libvirt will ALWAYS use -S.  So what we need is the hooks for using
-S and still relying on the migration stream rather than the current
status quo of a blind 'cont' (or nothing, if libvirt knows the source
was also in the paused state).  In fact, it is more confusing than that:
libvirt has a live migration mode that will auto-fallback to paused
migration if live migration wasn't converging fast enough.  That is, on
the source, we intentionally pause the source to quit waiting for
convergence, but on the destination we then 'cont' to wake the guest
back up.  In _that_ scenario, the migration stream will contain data
that the guest is paused, but we WANT the destination to be running.

> But what I want to know is _what_ events are you interested in?

Really, an event that the destination is ready to be woken up, and some
indication of the destination having received state in the migration
stream (so that it will wake up to the correct state).

> 
> Later, Juan.
> 
> 

-- 
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: 539 bytes --]