Re: [Qemu-devel] [PATCH 2/3] move vm stop/start to migrate_set_state

[Jamie Lokier]

Anthony Liguori wrote:
> Jamie Lokier wrote:
> >Anthony Liguori wrote:
> >  
> >>Paolo Bonzini wrote:
> >>    
> >>>On 07/09/2009 03:45 PM, Anthony Liguori wrote:
> >>>      
> >>>>How does the disk become full during the final stage?  The guest isn't
> >>>>running.
> >>>>        
> >>>The host disk can become full and cause a "migrate exec" to fail.  Or 
> >>>for network migration migration, you could have the connection drop 
> >>>exactly during the final stage.  In this case, the VM would be 
> >>>unconditionally restarted.
> >>>      
> >>Because migration failed.  Is that not the desired behavior?  It seems 
> >>like it is to me.
> >>
> >>If I try to do a live migration, it should either succeed and my guest 
> >>experiences minimal downtime or it should fail and my guest should 
> >>experience minimal downtime.
> >>    
> >
> >What happens if the destination host sends "migration completed", and
> >then the connection drops before that message is delivered reliably to
> >the sending host?
> >  
> 
> We don't check the return value of close

Linux doesn't return I/O or network errors from close() anyway, except
for a few network filesystems, and not even those in older kernels.  It
generally returns zero.

(If you were saving to disk and wanted to detect write I/O errors,
which by the way includes disk full when writing to a network
filesystem, you'll need to call fsync().  I'm not sure if this is relevant).

> so the last possible place failure can occur is the last write.  By
> definition, if the write failed, the migration session could not
> have been completed successfully.  Migration is unidirectional.
> There is no "migration completed" message from the destination.
> We're very conservative wrt restarting the source.

Yes, I agree, as long as it's conservative and only restarts when the
last byte needed to start the destination has definitely not been
written, that's safe.  That's a good design.

If you get an error during the last write(), I wouldn't trust that to
mean the recipient will definitely not see the data you wrote.  (Enjoy
the double negative).  It's another variation of the handshake
uncertainty, this time reflected in what write() should report when
it's uncertain about a network transmission.  If it reports an error
when it's uncertain, then you can't trust that a write() error means
the data was not written, only that a problem was detected.

By saving the final "commit" byte for it's own 1-byte write(), then if
you get an error from any earlier write, then of course you know the
last byte has not been sent and it's safe to resume the source.
Reading SO_ERROR before the 1-byte write() would maximise this chance,
but it's probably so rare as to be pointless.

-- Jamie