[Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts

[Gleb Natapov]

On Mon, Nov 23, 2009 at 09:05:58AM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
> >Then I don't see why Juan claims what he claims.
> 
> Live migration is unidirectional.  As long as qemu can send out all
> of the data without the stream closing, it will "succeed" on the
> source.  While this may sound like a bug, it's an impossible problem
> to solve as it's dealing with reliable communication between two
> unreliable nodes (i.e. the two general's problem).  This is why the
> source qemu does not exit after a successful live migration.  It
As far as I remember the two general's problem talks about unreliable
channel, not unreliable nodes. Why not having destination send ACK/NACK
to the source when it knows that migration succeeded/failed. If source
gets NACK it continues, if it gets ACK it exits, otherwise it stays in
paused state. Yes, there are worst case scenarios where this will not work,
but it will not be worse then what we have now.

> merely stays in the stopped state.  The idea is that a third party
> management tool can be the "reliable third party" that can make the
> final determination about whether the migration has succeeded and
> take actions on the source and destination nodes appropriately.
> 
> In this precise case, if post_load() fails, it may or may not cause
> the source to fail the migration depending on how large the TCP
> window sizes are, how much data is in flight, and how much state is
> left to process.
> 
If post_load() fails it should inform management about failure and
management will restart the source. I this how it works now?

--
                        Gleb.