[Qemu-devel] KVM call agenda for May 18

[Qemu-devel] KVM call agenda for May 18

[Chris Wright]

Please send in any agenda items you are interested in covering.

If we have a lack of agenda items I'll cancel the week's call.

thanks,
-chris

[Qemu-devel] Re: KVM call agenda for May 18

[Brian Jackson]

On Monday 17 May 2010 22:23:46 Chris Wright wrote:
> Please send in any agenda items you are interested in covering.
> 
> If we have a lack of agenda items I'll cancel the week's call.


Perceived long standing bugs that nobody seems to care about. There are a few, one of which is the > 1TB [1] bug that has existed for 4+ months.

And others.

This can wait for a later call if necessary... not worth a call on it's own.


Etc:
[1] http://sourceforge.net/tracker/?func=detail&aid=2933400&group_id=180599&atid=893831


> 
> thanks,
> -chris
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Qemu-devel] Re: KVM call agenda for May 18

[Anthony Liguori]

On 05/18/2010 01:59 AM, Brian Jackson wrote:
> On Monday 17 May 2010 22:23:46 Chris Wright wrote:
>    
>> Please send in any agenda items you are interested in covering.
>>
>> If we have a lack of agenda items I'll cancel the week's call.
>>      
>
> Perceived long standing bugs that nobody seems to care about. There are a few, one of which is the>  1TB [1] bug that has existed for 4+ months.
>    

s/care about/know about/g

This should be filed in launchpad as a qemu bug and it should be tested 
against the latest git.  This bug sounds like we're using an int to 
represent sector offset somewhere but there's not enough info in the bug 
report to figure out for sure.  I just audited the virtio-blk -> raw -> 
aio=threads path and I don't see an obvious place that we're getting it 
wrong.

> And others.
>    

Bugs that affect qemu should be filed in launchpad.  Launchpad has nice 
features like the able to mark bugs as affecting many users which help 
raise visibility.  I can't speak for the source forge tracker, but I do 
regular triage on launchpad for qemu bugs.

Regards,

Anthony Liguori

> This can wait for a later call if necessary... not worth a call on it's own.
>
>
> Etc:
> [1] http://sourceforge.net/tracker/?func=detail&aid=2933400&group_id=180599&atid=893831
>
>
>    
>> thanks,
>> -chris
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>      
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>    

[Qemu-devel] Re: KVM call agenda for May 18

[Brian Jackson]

On Tuesday 18 May 2010 08:52:36 Anthony Liguori wrote:
> On 05/18/2010 01:59 AM, Brian Jackson wrote:
> > On Monday 17 May 2010 22:23:46 Chris Wright wrote:
> >> Please send in any agenda items you are interested in covering.
> >> 
> >> If we have a lack of agenda items I'll cancel the week's call.
> > 
> > Perceived long standing bugs that nobody seems to care about. There are a
> > few, one of which is the>  1TB [1] bug that has existed for 4+ months.
> 
> s/care about/know about/g
> 
> This should be filed in launchpad as a qemu bug and it should be tested
> against the latest git.  This bug sounds like we're using an int to
> represent sector offset somewhere but there's not enough info in the bug
> report to figure out for sure.  I just audited the virtio-blk -> raw ->
> aio=threads path and I don't see an obvious place that we're getting it
> wrong.
> 
> > And others.
> 
> Bugs that affect qemu should be filed in launchpad.  Launchpad has nice
> features like the able to mark bugs as affecting many users which help
> raise visibility.  I can't speak for the source forge tracker, but I do
> regular triage on launchpad for qemu bugs.


I wonder how everyone would feel about closing the kvm tracker to new 
submissions and move everything over to launchpad?


> 
> Regards,
> 
> Anthony Liguori
> 
> > This can wait for a later call if necessary... not worth a call on it's
> > own.
> > 
> > 
> > Etc:
> > [1]
> > http://sourceforge.net/tracker/?func=detail&aid=2933400&group_id=180599&
> > atid=893831
> > 
> >> thanks,
> >> -chris
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe kvm" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Qemu-devel] Re: KVM call agenda for May 18

[Chris Wright]

* Brian Jackson (iggy@theiggy.com) wrote:
> On Tuesday 18 May 2010 08:52:36 Anthony Liguori wrote:
> > On 05/18/2010 01:59 AM, Brian Jackson wrote:
> > > On Monday 17 May 2010 22:23:46 Chris Wright wrote:
> > >> Please send in any agenda items you are interested in covering.
> > >> 
> > >> If we have a lack of agenda items I'll cancel the week's call.
> > > 
> > > Perceived long standing bugs that nobody seems to care about. There are a
> > > few, one of which is the>  1TB [1] bug that has existed for 4+ months.
> > 
> > s/care about/know about/g
> > 
> > This should be filed in launchpad as a qemu bug and it should be tested
> > against the latest git.  This bug sounds like we're using an int to
> > represent sector offset somewhere but there's not enough info in the bug
> > report to figure out for sure.  I just audited the virtio-blk -> raw ->
> > aio=threads path and I don't see an obvious place that we're getting it
> > wrong.
> > 
> > > And others.
> > 
> > Bugs that affect qemu should be filed in launchpad.  Launchpad has nice
> > features like the able to mark bugs as affecting many users which help
> > raise visibility.  I can't speak for the source forge tracker, but I do
> > regular triage on launchpad for qemu bugs.
> 
> 
> I wonder how everyone would feel about closing the kvm tracker to new 
> submissions and move everything over to launchpad?

Yeah, this was suggested on the call today.  Anthony's sending out an
email proposal on better bug tracking

thanks,
-chris

[Qemu-devel] Re: KVM call agenda for May 18

[Christoph Hellwig]

On Tue, May 18, 2010 at 08:52:36AM -0500, Anthony Liguori wrote:
> This should be filed in launchpad as a qemu bug and it should be tested  
> against the latest git.  This bug sounds like we're using an int to  
> represent sector offset somewhere but there's not enough info in the bug  
> report to figure out for sure.  I just audited the virtio-blk -> raw ->  
> aio=threads path and I don't see an obvious place that we're getting it  
> wrong.

FYI: I'm going to ignore everything that's in launchpad - even more than
in the stupid SF bugtracker.  While the SF one is almost unsuable
launchpad is entirely unsuable.  If you don't have an account with the
evil spacement empire you can't even check the email addresses of the
reporters, so any communication with them is entirely impossible.

It's time we get a proper bugzilla.qemu.org for both qemu and qemu-kvm
that can be used sanely.  If you ask nicely you might even get a virtual
instance of bugzilla.kernel.org which works quite nicely.

[Qemu-devel] Re: KVM call agenda for May 18

[Anthony Liguori]

On 05/19/2010 03:20 AM, Christoph Hellwig wrote:
> On Tue, May 18, 2010 at 08:52:36AM -0500, Anthony Liguori wrote:
>    
>> This should be filed in launchpad as a qemu bug and it should be tested
>> against the latest git.  This bug sounds like we're using an int to
>> represent sector offset somewhere but there's not enough info in the bug
>> report to figure out for sure.  I just audited the virtio-blk ->  raw ->
>> aio=threads path and I don't see an obvious place that we're getting it
>> wrong.
>>      
> FYI: I'm going to ignore everything that's in launchpad - even more than
> in the stupid SF bugtracker.  While the SF one is almost unsuable
> launchpad is entirely unsuable.  If you don't have an account with the
> evil spacement empire you can't even check the email addresses of the
> reporters, so any communication with them is entirely impossible.
>    

All bug traffic will now come to the list and you can just respond 
directly to that.  The mails include the submitters contact information.

Regards,

Anthony Liguori

> It's time we get a proper bugzilla.qemu.org for both qemu and qemu-kvm
> that can be used sanely.  If you ask nicely you might even get a virtual
> instance of bugzilla.kernel.org which works quite nicely.
>
>    

[Qemu-devel] Re: KVM call agenda for May 18

[Avi Kivity]

On 05/19/2010 11:20 AM, Christoph Hellwig wrote:
>
> It's time we get a proper bugzilla.qemu.org for both qemu and qemu-kvm
> that can be used sanely.  If you ask nicely you might even get a virtual
> instance of bugzilla.kernel.org which works quite nicely.
>    

That would be my preference too but there's a limit to how much we can 
juggle the bug database around.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: KVM call agenda for May 18

[Anthony Liguori]

On 05/17/2010 10:23 PM, Chris Wright wrote:
> Please send in any agenda items you are interested in covering.
>
> If we have a lack of agenda items I'll cancel the week's call.
>    

- Slipping 0.13 release out to July 1st.
- Block I/O performance (high CPU consumption)

Regards,

Anthony Liguori

> thanks,
> -chris
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>    

Re: [Qemu-devel] Re: KVM call agenda for May 18

[Daniel P. Berrange]

On Tue, May 18, 2010 at 08:53:19AM -0500, Anthony Liguori wrote:
> On 05/17/2010 10:23 PM, Chris Wright wrote:
> >Please send in any agenda items you are interested in covering.
> >
> >If we have a lack of agenda items I'll cancel the week's call.
> >   
> 
> - Slipping 0.13 release out to July 1st.

What is the plan wrt QMP and 0.13 ? Is the intention to have 100%[1] of the
existing monitor commands converted to QMP? There are still quite alot of
monitor commands not converted and given the time take to get this far, it
seems optimistic to expect completion by July, let alone a feature freeze
date preceeding that.

Regards,
Daniel

[1] Excluding obsolete commands like drive_add, pci_add replaced by device_add
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] Re: KVM call agenda for May 18

[Anthony Liguori]

On 05/18/2010 09:09 AM, Daniel P. Berrange wrote:
> On Tue, May 18, 2010 at 08:53:19AM -0500, Anthony Liguori wrote:
>    
>> On 05/17/2010 10:23 PM, Chris Wright wrote:
>>      
>>> Please send in any agenda items you are interested in covering.
>>>
>>> If we have a lack of agenda items I'll cancel the week's call.
>>>
>>>        
>> - Slipping 0.13 release out to July 1st.
>>      
> What is the plan wrt QMP and 0.13 ? Is the intention to have 100%[1] of the
> existing monitor commands converted to QMP?

No.  I don't think our goal is to ever fully convert monitor commands to 
QMP.  Some commands simply don't make sense as QMP commands (like x and xp).

Is there a set of commands that you think need to be converted that 
currently aren't?

Regards,

Anthony Liguori

>   There are still quite alot of
> monitor commands not converted and given the time take to get this far, it
> seems optimistic to expect completion by July, let alone a feature freeze
> date preceeding that.
>
> Regards,
> Daniel
>
> [1] Excluding obsolete commands like drive_add, pci_add replaced by device_add
>    

Re: [Qemu-devel] Re: KVM call agenda for May 18

[Daniel P. Berrange]

On Tue, May 18, 2010 at 09:34:06AM -0500, Anthony Liguori wrote:
> On 05/18/2010 09:09 AM, Daniel P. Berrange wrote:
> >On Tue, May 18, 2010 at 08:53:19AM -0500, Anthony Liguori wrote:
> >   
> >>On 05/17/2010 10:23 PM, Chris Wright wrote:
> >>     
> >>>Please send in any agenda items you are interested in covering.
> >>>
> >>>If we have a lack of agenda items I'll cancel the week's call.
> >>>
> >>>       
> >>- Slipping 0.13 release out to July 1st.
> >>     
> >What is the plan wrt QMP and 0.13 ? Is the intention to have 100%[1] of the
> >existing monitor commands converted to QMP?
> 
> No.  I don't think our goal is to ever fully convert monitor commands to 
> QMP.  Some commands simply don't make sense as QMP commands (like x and xp).

We're a really long way from a complete conversion even  ignoring 
commands which don't make sense in QMP. The current state almost 
covers the commands libvirt currently uses, but there's much more 
beyond that.

> Is there a set of commands that you think need to be converted that 
> currently aren't?

Notable outstanding commands that libvirt has a non-negligable
chance of wanting to use in the not too distant future

 - blockdev_add/del (to replace drive_add/del)
 - commit/delvm/loadvm/savevm
 - screendump
 - set_link
 - mouse_{move,button,set}
 - sendkey
 - acl_{add,remove,policy,reset,show}
 - boot_set
 - watchdog_action


The full list of unconverted commands though is much long:

  $ grep cmd qemu-monitor.hx  | grep -v cmd_new | grep -v async
        .mhandler.cmd = do_help_cmd,
        .mhandler.cmd = do_commit,
        .mhandler.cmd = do_logfile,
        .mhandler.cmd = do_log,
        .mhandler.cmd = do_savevm,
        .mhandler.cmd = do_loadvm,
        .mhandler.cmd = do_delvm,
        .mhandler.cmd = do_singlestep,
        .mhandler.cmd = do_gdbserver,
        .mhandler.cmd = do_memory_dump,
        .mhandler.cmd = do_physical_memory_dump,
        .mhandler.cmd = do_print,
        .mhandler.cmd = do_ioport_read,
        .mhandler.cmd = do_ioport_write,
        .mhandler.cmd = do_sendkey,
        .mhandler.cmd = do_sum,
        .mhandler.cmd = do_usb_add,
        .mhandler.cmd = do_usb_del,
        .mhandler.cmd = do_mouse_move,
        .mhandler.cmd = do_mouse_button,
        .mhandler.cmd = do_mouse_set,
        .mhandler.cmd = do_wav_capture,
        .mhandler.cmd = do_stop_capture,
        .mhandler.cmd = do_boot_set,
        .mhandler.cmd = do_inject_nmi,
        .mhandler.cmd = drive_hot_add,
        .mhandler.cmd = net_host_device_add,
        .mhandler.cmd = net_host_device_remove,
        .mhandler.cmd = net_slirp_hostfwd_add,
        .mhandler.cmd = net_slirp_hostfwd_remove,
        .mhandler.cmd = do_watchdog_action,
        .mhandler.cmd = do_acl_show,
        .mhandler.cmd = do_acl_policy,
        .mhandler.cmd = do_acl_add,
        .mhandler.cmd = do_acl_remove,
        .mhandler.cmd = do_acl_reset,
        .mhandler.cmd = do_inject_mce,

   $ grep 'mhandler.info' monitor.c | grep -v info_new | grep -v async
        .mhandler.info = do_info_network,
        .mhandler.info = do_info_registers,
        .mhandler.info = do_info_history,
        .mhandler.info = irq_info,
        .mhandler.info = pic_info,
        .mhandler.info = tlb_info,
        .mhandler.info = mem_info,
        .mhandler.info = do_info_jit,
        .mhandler.info = do_info_numa,
        .mhandler.info = usb_info,
        .mhandler.info = usb_host_info,
        .mhandler.info = do_info_profile,
        .mhandler.info = do_info_capture,
        .mhandler.info = do_info_snapshots,
        .mhandler.info = pcmcia_info,
        .mhandler.info = do_info_cpu_stats,
        .mhandler.info = do_info_usernet,
        .mhandler.info = do_info_qtree,
        .mhandler.info = do_info_qdm,
        .mhandler.info = do_info_roms,

I don't think we can claim all those are irrelevant for QMP.

So are we still targetting complete conversion of relevant commands
for 0.13, or is it just going to be a stepping stone where declare 
QMP stable, but known to be incomplete for coverage of commands ?

Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] Re: KVM call agenda for May 18

[Anthony Liguori]

On 05/18/2010 09:55 AM, Daniel P. Berrange wrote:
> On Tue, May 18, 2010 at 09:34:06AM -0500, Anthony Liguori wrote:
>    
>> On 05/18/2010 09:09 AM, Daniel P. Berrange wrote:
>>      
>>> On Tue, May 18, 2010 at 08:53:19AM -0500, Anthony Liguori wrote:
>>>
>>>        
>>>> On 05/17/2010 10:23 PM, Chris Wright wrote:
>>>>
>>>>          
>>>>> Please send in any agenda items you are interested in covering.
>>>>>
>>>>> If we have a lack of agenda items I'll cancel the week's call.
>>>>>
>>>>>
>>>>>            
>>>> - Slipping 0.13 release out to July 1st.
>>>>
>>>>          
>>> What is the plan wrt QMP and 0.13 ? Is the intention to have 100%[1] of the
>>> existing monitor commands converted to QMP?
>>>        
>> No.  I don't think our goal is to ever fully convert monitor commands to
>> QMP.  Some commands simply don't make sense as QMP commands (like x and xp).
>>      
> We're a really long way from a complete conversion even  ignoring
> commands which don't make sense in QMP. The current state almost
> covers the commands libvirt currently uses, but there's much more
> beyond that.
>
>    
>> Is there a set of commands that you think need to be converted that
>> currently aren't?
>>      
> Notable outstanding commands that libvirt has a non-negligable
> chance of wanting to use in the not too distant future
>
>   - blockdev_add/del (to replace drive_add/del)
>   - commit/delvm/loadvm/savevm
>   - screendump
>   - set_link
>   - mouse_{move,button,set}
>   - sendkey
>   - acl_{add,remove,policy,reset,show}
>   - boot_set
>   - watchdog_action
>
>
> The full list of unconverted commands though is much long:
>    

Thanks.  A lot of these should be easy to convert.

>    $ grep cmd qemu-monitor.hx  | grep -v cmd_new | grep -v async
>          .mhandler.cmd = do_help_cmd,
>    
We don't need this.
>          .mhandler.cmd = do_commit,
>          .mhandler.cmd = do_logfile,
>          .mhandler.cmd = do_log,
>    

I think we can skip log and logfile.

>          .mhandler.cmd = do_savevm,
>          .mhandler.cmd = do_loadvm,
>          .mhandler.cmd = do_delvm,
>          .mhandler.cmd = do_singlestep,
>          .mhandler.cmd = do_gdbserver,
>          .mhandler.cmd = do_memory_dump,
>          .mhandler.cmd = do_physical_memory_dump,
>    

I'd prefer to skip the memory dump commands.
>          .mhandler.cmd = do_print,
>    
We can skip this.
>          .mhandler.cmd = do_ioport_read,
>          .mhandler.cmd = do_ioport_write,
>          .mhandler.cmd = do_sendkey,
>          .mhandler.cmd = do_sum,
>    
We can skip do_sum.
>          .mhandler.cmd = do_usb_add,
>          .mhandler.cmd = do_usb_del,
>          .mhandler.cmd = do_mouse_move,
>          .mhandler.cmd = do_mouse_button,
>          .mhandler.cmd = do_mouse_set,
>          .mhandler.cmd = do_wav_capture,
>          .mhandler.cmd = do_stop_capture,
>    
I'd prefer we skip wav capture.
>          .mhandler.cmd = do_boot_set,
>          .mhandler.cmd = do_inject_nmi,
>          .mhandler.cmd = drive_hot_add,
>          .mhandler.cmd = net_host_device_add,
>          .mhandler.cmd = net_host_device_remove,
>          .mhandler.cmd = net_slirp_hostfwd_add,
>          .mhandler.cmd = net_slirp_hostfwd_remove,
>          .mhandler.cmd = do_watchdog_action,
>          .mhandler.cmd = do_acl_show,
>          .mhandler.cmd = do_acl_policy,
>          .mhandler.cmd = do_acl_add,
>          .mhandler.cmd = do_acl_remove,
>          .mhandler.cmd = do_acl_reset,
>          .mhandler.cmd = do_inject_mce,
>     $ grep 'mhandler.info' monitor.c | grep -v info_new | grep -v async
>          .mhandler.info = do_info_network,
>          .mhandler.info = do_info_registers,
>          .mhandler.info = do_info_history,
>          .mhandler.info = irq_info,
>          .mhandler.info = pic_info,
>          .mhandler.info = tlb_info,
>          .mhandler.info = mem_info,
>          .mhandler.info = do_info_jit,
>          .mhandler.info = do_info_numa,
>          .mhandler.info = usb_info,
>          .mhandler.info = usb_host_info,
>          .mhandler.info = do_info_profile,
>          .mhandler.info = do_info_capture,
>          .mhandler.info = do_info_snapshots,
>          .mhandler.info = pcmcia_info,
>          .mhandler.info = do_info_cpu_stats,
>          .mhandler.info = do_info_usernet,
>          .mhandler.info = do_info_qtree,
>          .mhandler.info = do_info_qdm,
>          .mhandler.info = do_info_roms,
>    

I'd rather not convert info commands until there were users.  Info 
commands don't map well to QMP because of their lack of structure.

Regards,

Anthony Liguori

> I don't think we can claim all those are irrelevant for QMP.
>
> So are we still targetting complete conversion of relevant commands
> for 0.13, or is it just going to be a stepping stone where declare
> QMP stable, but known to be incomplete for coverage of commands ?
>
> Daniel
>    

Re: [Qemu-devel] Re: KVM call agenda for May 18

[Markus Armbruster]

"Daniel P. Berrange" <berrange@redhat.com> writes:

> On Tue, May 18, 2010 at 09:34:06AM -0500, Anthony Liguori wrote:
>> On 05/18/2010 09:09 AM, Daniel P. Berrange wrote:
>> >On Tue, May 18, 2010 at 08:53:19AM -0500, Anthony Liguori wrote:
>> >   
>> >>On 05/17/2010 10:23 PM, Chris Wright wrote:
>> >>     
>> >>>Please send in any agenda items you are interested in covering.
>> >>>
>> >>>If we have a lack of agenda items I'll cancel the week's call.
>> >>>
>> >>>       
>> >>- Slipping 0.13 release out to July 1st.
>> >>     
>> >What is the plan wrt QMP and 0.13 ? Is the intention to have 100%[1] of the
>> >existing monitor commands converted to QMP?
>> 
>> No.  I don't think our goal is to ever fully convert monitor commands to 
>> QMP.  Some commands simply don't make sense as QMP commands (like x and xp).
>
> We're a really long way from a complete conversion even  ignoring 
> commands which don't make sense in QMP. The current state almost 
> covers the commands libvirt currently uses, but there's much more 
> beyond that.
>
>> Is there a set of commands that you think need to be converted that 
>> currently aren't?
>
> Notable outstanding commands that libvirt has a non-negligable
> chance of wanting to use in the not too distant future
>
>  - blockdev_add/del (to replace drive_add/del)

Working on it.  It's hairy.

>  - commit/delvm/loadvm/savevm

Luiz posted an RFC patch.  It's hairy.

>  - screendump

Haven't looked into it.

>  - set_link

Patch posted weeks ago, still not merged.

>  - mouse_{move,button,set}
>  - sendkey
>  - acl_{add,remove,policy,reset,show}
>  - boot_set
>  - watchdog_action

Same as screendump.

> The full list of unconverted commands though is much long:
[...]
> I don't think we can claim all those are irrelevant for QMP.
>
> So are we still targetting complete conversion of relevant commands
> for 0.13, or is it just going to be a stepping stone where declare 
> QMP stable, but known to be incomplete for coverage of commands ?

Completeness and stability are mostly orthogonal.  If we get the
fundamentals right, we can add missing stuff without destabilizing
existing stuff.  To get them right, we need to cover enough material to
develop our understanding of the problems, and to enable real use.
Until libvirt can use QMP, we fail on "real use".

Re: [Qemu-devel] Re: KVM call agenda for May 18

[Markus Armbruster]

Markus Armbruster <armbru@redhat.com> writes:

[...]
>>  - set_link
>
> Patch posted weeks ago, still not merged.

Correction: it got merged weeks ago, as commit 5369e3c0.  I got
confused.

[...]

Re: [Qemu-devel] Re: KVM call agenda for May 18

[Luiz Capitulino]

On Tue, 18 May 2010 15:55:41 +0100
"Daniel P. Berrange" <berrange@redhat.com> wrote:

> On Tue, May 18, 2010 at 09:34:06AM -0500, Anthony Liguori wrote:
> > On 05/18/2010 09:09 AM, Daniel P. Berrange wrote:
> > >On Tue, May 18, 2010 at 08:53:19AM -0500, Anthony Liguori wrote:
> > >   
> > >>On 05/17/2010 10:23 PM, Chris Wright wrote:
> > >>     
> > >>>Please send in any agenda items you are interested in covering.
> > >>>
> > >>>If we have a lack of agenda items I'll cancel the week's call.
> > >>>
> > >>>       
> > >>- Slipping 0.13 release out to July 1st.
> > >>     
> > >What is the plan wrt QMP and 0.13 ? Is the intention to have 100%[1] of the
> > >existing monitor commands converted to QMP?
> > 
> > No.  I don't think our goal is to ever fully convert monitor commands to 
> > QMP.  Some commands simply don't make sense as QMP commands (like x and xp).
> 
> We're a really long way from a complete conversion even  ignoring 
> commands which don't make sense in QMP. The current state almost 
> covers the commands libvirt currently uses, but there's much more 
> beyond that.

 As far as I understood it, the plan for the first QMP release has always
been to only convert the subset of commands relevant/used by libvirt.

 We've been trying to figure out this set for a long time.

> > Is there a set of commands that you think need to be converted that 
> > currently aren't?
> 
> Notable outstanding commands that libvirt has a non-negligable
> chance of wanting to use in the not too distant future
> 
>  - blockdev_add/del (to replace drive_add/del)

 Markus is working on this.

>  - commit/delvm/loadvm/savevm

 I did a first try, but errors in those handlers are a mess and didn't
map well to QMP. I think QError improvements are needed to get this done.

>  - screendump
>  - set_link

 Both already converted.

>  - mouse_{move,button,set}
>  - sendkey
>  - acl_{add,remove,policy,reset,show}
>  - boot_set
>  - watchdog_action

 Not converted and I'm not sure how hard they are.

> The full list of unconverted commands though is much long:

[...]

> I don't think we can claim all those are irrelevant for QMP.
> 
> So are we still targetting complete conversion of relevant commands
> for 0.13, or is it just going to be a stepping stone where declare 
> QMP stable, but known to be incomplete for coverage of commands ?

 The first thing to do is to agree on what a 'complete coverage' would be,
what we have been trying to do since January is to provide a complete set
for libvirt, our unique well known client so far.

 Apart from the 'outstanding' set above, can you elaborate on how
QMP on 0.13 would not satisfy libvirt needs?

Re: [Qemu-devel] Re: KVM call agenda for May 18

[Daniel P. Berrange]

On Tue, May 18, 2010 at 01:00:40PM -0300, Luiz Capitulino wrote:
> On Tue, 18 May 2010 15:55:41 +0100
> "Daniel P. Berrange" <berrange@redhat.com> wrote:
> 
> > On Tue, May 18, 2010 at 09:34:06AM -0500, Anthony Liguori wrote:
> > > On 05/18/2010 09:09 AM, Daniel P. Berrange wrote:
> > > >On Tue, May 18, 2010 at 08:53:19AM -0500, Anthony Liguori wrote:
> > > >   
> > > >>On 05/17/2010 10:23 PM, Chris Wright wrote:
> > > >>     
> > > >>>Please send in any agenda items you are interested in covering.
> > > >>>
> > > >>>If we have a lack of agenda items I'll cancel the week's call.
> > > >>>
> > > >>>       
> > > >>- Slipping 0.13 release out to July 1st.
> > > >>     
> > > >What is the plan wrt QMP and 0.13 ? Is the intention to have 100%[1] of the
> > > >existing monitor commands converted to QMP?
> > > 
> > > No.  I don't think our goal is to ever fully convert monitor commands to 
> > > QMP.  Some commands simply don't make sense as QMP commands (like x and xp).
> > 
> > We're a really long way from a complete conversion even  ignoring 
> > commands which don't make sense in QMP. The current state almost 
> > covers the commands libvirt currently uses, but there's much more 
> > beyond that.
> 
>  As far as I understood it, the plan for the first QMP release has always
> been to only convert the subset of commands relevant/used by libvirt.

Well we've evolved the plan several times since QMP started & the set
of commands used by libvirt has evolved too! So I just want to define 
exactly what we're proposing to support for 0.13 release.

> > I don't think we can claim all those are irrelevant for QMP.
> > 
> > So are we still targetting complete conversion of relevant commands
> > for 0.13, or is it just going to be a stepping stone where declare 
> > QMP stable, but known to be incomplete for coverage of commands ?
> 
>  The first thing to do is to agree on what a 'complete coverage' would be,
> what we have been trying to do since January is to provide a complete set
> for libvirt, our unique well known client so far.
> 
>  Apart from the 'outstanding' set above, can you elaborate on how
> QMP on 0.13 would not satisfy libvirt needs?

The must haves are blockdev_add, and the commit/delvm/loadvm/savevm
stuff, since they're already in use. 

The problem I fear is that we're aiming for a moving target here.

eg, by the time QEMU 0.13 comes out libvirt may have received patches
using yet more QEMU monitor commands. So the list I mention above is
my best guesstimate at the commands that could appear in libvirt in
the not too distant future. The more of those we can support the better
so that we avoid geting into a case where QEMU 0.13 is released, but a
yet newer libvirt wants extra QMP commands that weren't included in 0.13.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] Re: KVM call agenda for May 18

[Anthony Liguori]

On 05/18/2010 11:16 AM, Daniel P. Berrange wrote:
> The must haves are blockdev_add, and the commit/delvm/loadvm/savevm
> stuff, since they're already in use.
>
> The problem I fear is that we're aiming for a moving target here.
>
> eg, by the time QEMU 0.13 comes out libvirt may have received patches
> using yet more QEMU monitor commands.

libvirt could just stop taking patches that use monitor commands.

There's no way we're going to break the deadlock if we don't work 
together here.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: KVM call agenda for May 18

[Luiz Capitulino]

On Tue, 18 May 2010 17:16:54 +0100
"Daniel P. Berrange" <berrange@redhat.com> wrote:

> On Tue, May 18, 2010 at 01:00:40PM -0300, Luiz Capitulino wrote:
> > On Tue, 18 May 2010 15:55:41 +0100
> > "Daniel P. Berrange" <berrange@redhat.com> wrote:
> > 
> > > On Tue, May 18, 2010 at 09:34:06AM -0500, Anthony Liguori wrote:
> > > > On 05/18/2010 09:09 AM, Daniel P. Berrange wrote:
> > > > >On Tue, May 18, 2010 at 08:53:19AM -0500, Anthony Liguori wrote:
> > > > >   
> > > > >>On 05/17/2010 10:23 PM, Chris Wright wrote:
> > > > >>     
> > > > >>>Please send in any agenda items you are interested in covering.
> > > > >>>
> > > > >>>If we have a lack of agenda items I'll cancel the week's call.
> > > > >>>
> > > > >>>       
> > > > >>- Slipping 0.13 release out to July 1st.
> > > > >>     
> > > > >What is the plan wrt QMP and 0.13 ? Is the intention to have 100%[1] of the
> > > > >existing monitor commands converted to QMP?
> > > > 
> > > > No.  I don't think our goal is to ever fully convert monitor commands to 
> > > > QMP.  Some commands simply don't make sense as QMP commands (like x and xp).
> > > 
> > > We're a really long way from a complete conversion even  ignoring 
> > > commands which don't make sense in QMP. The current state almost 
> > > covers the commands libvirt currently uses, but there's much more 
> > > beyond that.
> > 
> >  As far as I understood it, the plan for the first QMP release has always
> > been to only convert the subset of commands relevant/used by libvirt.
> 
> Well we've evolved the plan several times since QMP started & the set
> of commands used by libvirt has evolved too! So I just want to define 
> exactly what we're proposing to support for 0.13 release.

 The current set of libvirt used commands plus the must haves ones, this is
the maximum we can be committed with for the next release.

 If time allows, I will pick more from the outstanding list.

> > > I don't think we can claim all those are irrelevant for QMP.
> > > 
> > > So are we still targetting complete conversion of relevant commands
> > > for 0.13, or is it just going to be a stepping stone where declare 
> > > QMP stable, but known to be incomplete for coverage of commands ?
> > 
> >  The first thing to do is to agree on what a 'complete coverage' would be,
> > what we have been trying to do since January is to provide a complete set
> > for libvirt, our unique well known client so far.
> > 
> >  Apart from the 'outstanding' set above, can you elaborate on how
> > QMP on 0.13 would not satisfy libvirt needs?
> 
> The must haves are blockdev_add, and the commit/delvm/loadvm/savevm
> stuff, since they're already in use. 
> 
> The problem I fear is that we're aiming for a moving target here.
> 
> eg, by the time QEMU 0.13 comes out libvirt may have received patches
> using yet more QEMU monitor commands. So the list I mention above is
> my best guesstimate at the commands that could appear in libvirt in
> the not too distant future. The more of those we can support the better
> so that we avoid geting into a case where QEMU 0.13 is released, but a
> yet newer libvirt wants extra QMP commands that weren't included in 0.13.

 This problem isn't 0.13 specific as I expect new Monitor commands to
be added in qemu at every release. It's true that QMP makes this more
evident due its limited set, still we have to deal with the fact that
the command set is always going to be extended.

 Here's what I think we should do:

1. Clients should check for the availability of commands by issuing
   query-commands. Eg.

   A) Issue query-commands at startup and cache its output
   B) Before issuing any command, check whether it's supported
   C) Issue an error message if the command is not supported

2. Both projects should work closely, so that features are in sync at
   every release

3. We could create an official 'priority list' in qemu's tree, with
   a listing of commands to be converted for the next release and
   clients should work closely by suggesting changes to this list

Re: [Qemu-devel] Re: KVM call agenda for May 18

[Avi Kivity]

On 05/18/2010 05:34 PM, Anthony Liguori wrote:
>
> No.  I don't think our goal is to ever fully convert monitor commands 
> to QMP.  Some commands simply don't make sense as QMP commands (like x 
> and xp).

Examining memory does make sense for QMP, although it is already 
available through the gdb protocol, so it's kind of redundant.


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [Qemu-devel] Re: KVM call agenda for May 18

[Anthony Liguori]

On 05/18/2010 12:31 PM, Avi Kivity wrote:
> On 05/18/2010 05:34 PM, Anthony Liguori wrote:
>>
>> No.  I don't think our goal is to ever fully convert monitor commands 
>> to QMP.  Some commands simply don't make sense as QMP commands (like 
>> x and xp).
>
> Examining memory does make sense for QMP, although it is already 
> available through the gdb protocol, so it's kind of redundant.

The x and xp commands are meant to be used with all sorts of 
expressions.  I agree examining memory makes sense but we certainly want 
a very different interface for it.

Regards,

Anthony Liguori