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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
