[Qemu-devel] KVM call minutes for Feb 22

[Qemu-devel] KVM call minutes for Feb 22

[Michael S. Tsirkin]

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.
     Would be the most beneficial if we can make it stateless.
     Might be good for security but hard to integrate.

4. qcow3
     there will be a wiki with features we want there

5. google summer of code
	we only have 3 projects
	need more projects/mentors, we have another week

6. switch from gpxe to ipxe
	needed to get patches applied
	we'll likely switch
	need some testing
	might be possible by 0.15

-- 
MST

[Qemu-devel] KVM call minutes for Feb 22

[Chris Wright]

0.14 recap
- keeping schedule on wiki was helpful
- changelog was helpful
- testing (could even more emphasis could be improved)
- -rc cycles
  - -rc2 and final release just hours

0.15
- tentative date July 1st
- qapi
- qed features
- virtagent?
  - depends on whether to terminate in qemu vs external
    - terminating w/in qemu is close to feature complete
    - using QMP (kinda, QObject -> JSON marshalling, still use HTTP)
    - QMP is not bi-directional XMLRPC, one way with event posting
    - XMLRPC + server logic add to the basic QEMU side attack surface
      - splitting out to external process
    - state associated with guest in external process complicates live migration
      - e.g. handling in-process command in server
      - guest client reconnects during migration
      - can virtagent features be stateless 
    - Avi's favorite Lua based extension language coming RSN ;)
  - let's use copy and paste as a concrete example
    - usecase to help define the requirements and expose
      architectural
    - Jes will do this, make concrete counter proposal to hosting
      virtagent server in qemu
  - splitting QEMU into more modular components is a large architectural
    step, but better step

Block format acceptance
- qcow3 wiki starting

GSoC projects
- only 3 so far, mentoring organization applications Feb 28th
  - can update app 
- please add your thoughts here so that we can have a successful
- Luiz will send out a note as more explicit reminder

gpxe vs ipxe
- gpxe still stagnate
- ipxe accepting patches (e.g. igbvf)
- perhaps switch in 0.15 (Alex take a look)

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

[Alon Levy]

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?

>      Would be the most beneficial if we can make it stateless.
>      Might be good for security but hard to integrate.
> 
> 4. qcow3
>      there will be a wiki with features we want there
> 
> 5. google summer of code
> 	we only have 3 projects
> 	need more projects/mentors, we have another week
> 
> 6. switch from gpxe to ipxe
> 	needed to get patches applied
> 	we'll likely switch
> 	need some testing
> 	might be possible by 0.15
> 
> -- 
> MST
> 

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