Re: [Qemu-devel] KVM call minutes for Feb 22

[Anthony Liguori]

On 02/22/2011 11:32 AM, Alon Levy wrote:
> On Tue, Feb 22, 2011 at 06:06:22PM +0200, Michael S. Tsirkin wrote:
>    
> > Looks like Chris will send minutes too,
> > so I didn't do much to polish this,
> > I didn't realise he's doing it until I had this, so
> > here's the braindump: hope it helps.
> >
> > 1. 0.14 postmortem
> > - what went well
> >         wiki for planning
> >         testing
> > - what can be improved
> >         rc - cycle could be longer
> >
> > 2. 0.15 should be end of June
> >     July 1?
> >     - features:
> >       QED
> >       other?
> >       virtagent? might be blocked by the rpc issue (discussion followed)
> >
> > 3. virtagent rpc
> >       what should virtagent use to talk to the world outside of QEMU?
> >       Generalize QMP?
> >       Use an external rpc library?
> >       Do we want to/can we have virtagent out of process?
> >       Hard to make well with live migration.
> >      
> Spice had (when migration was bidirectional) an external agent (spice client)
> that worked fine with live migration. I agree an external agent makes live
> migration more difficult, but I disagree it is a blocker. It did require 
> bidirectional
> data exchange with qemu, but how is that a problem? why do all migrations have 
> to
> be identical to to-file migrations?
>    

I don't understand well enough exactly how this worked in Spice but 
there are a few reasons migration is unidirectional.  Namely:

1) Round trips during the critical phase add downtime that is 
proportional to the latency between two nodes.  As a rule, if you had 
bidirectional migration, it needs to minimize the number of round trips 
to the lowest number possible.  Having zero round trips is therefore 
always desirable.

2) Migrate-to-file doesn't work if bidirectional communication is required.

3) So far, all forms of bidirectional requirement can be/have been 
satisfied by encapsulating the QEMU migration protocol within another 
protocol.  This use of layering is the preferred approach to extension 
and is what the current migration code is designed for.

Regards,

Anthony Liguori