[Qemu-devel] KVM call agenda for July 27

[Qemu-devel] KVM call agenda for July 27

[Chris Wright]

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

thanks,
-chris

[Qemu-devel] Re: KVM call agenda for July 27

[Anthony Liguori]

On 07/26/2010 04:28 PM, Chris Wright wrote:
> Please send in any agenda items you are interested in covering.
>    

- 0.13 update
   I'll pre-empt the 0.13 question with an answer.  I'm just testing the 
VNC changes and if all goes well, I'll tag tonight.

   Initial thinking is to keep 0.14 short and target Dec 1st.

- if danpb can make it, would like to discuss -help output parsing
   summary: help parsing is terrible, but given the fact that 
capabilities is going to take a while to get totally right, would like 
to discuss an interim solution that gives us more flexibility to do 
reasonable things with the help output.


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
>    

[Qemu-devel] Re: KVM call agenda for July 27

[Anthony Liguori]

On 07/26/2010 05:28 PM, Anthony Liguori wrote:
> On 07/26/2010 04:28 PM, Chris Wright wrote:
>> Please send in any agenda items you are interested in covering.
>
> - 0.13 update
>   I'll pre-empt the 0.13 question with an answer.  I'm just testing 
> the VNC changes and if all goes well, I'll tag tonight.
>
>   Initial thinking is to keep 0.14 short and target Dec 1st.
>
> - if danpb can make it, would like to discuss -help output parsing
>   summary: help parsing is terrible, but given the fact that 
> capabilities is going to take a while to get totally right, would like 
> to discuss an interim solution that gives us more flexibility to do 
> reasonable things with the help output.

- any additional input on probed_raw?

>
> 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
>

[Qemu-devel] Re: KVM call agenda for July 27

[Alex Williamson]

On Mon, 2010-07-26 at 18:28 -0500, Anthony Liguori wrote:
> On 07/26/2010 05:28 PM, Anthony Liguori wrote:
> > On 07/26/2010 04:28 PM, Chris Wright wrote:
> >> Please send in any agenda items you are interested in covering.
> >
> > - 0.13 update
> >   I'll pre-empt the 0.13 question with an answer.  I'm just testing 
> > the VNC changes and if all goes well, I'll tag tonight.
> >
> >   Initial thinking is to keep 0.14 short and target Dec 1st.
> >
> > - if danpb can make it, would like to discuss -help output parsing
> >   summary: help parsing is terrible, but given the fact that 
> > capabilities is going to take a while to get totally right, would like 
> > to discuss an interim solution that gives us more flexibility to do 
> > reasonable things with the help output.
> 
> - any additional input on probed_raw?

 - cpu model #s, does anyone know things that would break if we bumped
the qemu64 model up to 13 (or higher?) and made definitions for
Conroe/Penryn/Nehalem use more representative model #s?

[Qemu-devel] Re: KVM call agenda for July 27

[Markus Armbruster]

Anthony Liguori <anthony@codemonkey.ws> writes:

> - any additional input on probed_raw?

Isn't it a fait accompli?  I stopped providing input when commit
79368c81 appeared.

[Qemu-devel] Re: KVM call agenda for July 27

[Daniel P. Berrange]

On Mon, Jul 26, 2010 at 05:28:21PM -0500, Anthony Liguori wrote:
> On 07/26/2010 04:28 PM, Chris Wright wrote:
> >Please send in any agenda items you are interested in covering.
> >   
> 
> - 0.13 update
>   I'll pre-empt the 0.13 question with an answer.  I'm just testing the 
> VNC changes and if all goes well, I'll tag tonight.
> 
>   Initial thinking is to keep 0.14 short and target Dec 1st.
> 
> - if danpb can make it, would like to discuss -help output parsing
>   summary: help parsing is terrible, but given the fact that 
> capabilities is going to take a while to get totally right, would like 
> to discuss an interim solution that gives us more flexibility to do 
> reasonable things with the help output.

I'm not able to make this call today & next week i'm on PTO. I would
like to think that we could get a suitable capabilities sytem in place
for 0.14 release. Since 0.13 is nearly ready & libvirt works with it
aside from the cache issue which is now addressed in libvirt, I don't
think its useful to change libvirt further. We need to just focus on
getting capabilities (and QMP in general for that matter) ready for
0.14 and not let it slip still further into 0.15.

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 :|

[Qemu-devel] Re: KVM call agenda for July 27

[Anthony Liguori]

On 07/27/2010 02:19 AM, Markus Armbruster wrote:
> Anthony Liguori<anthony@codemonkey.ws>  writes:
>
>    
>> - any additional input on probed_raw?
>>      
> Isn't it a fait accompli?  I stopped providing input when commit
> 79368c81 appeared.
>    

No.  79368c81 was to close the security hole (and I do consider it a 
security hole).  But as I mentioned on the list, I'm also not satisfied 
with it and that's why I proposed probed_raw.  I was hoping to get a 
little more input from those that objected to 79368c81 as to whether 
probed_raw was more agreeable.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: KVM call agenda for July 27

[Jes Sorensen]

On 07/27/10 02:13, Alex Williamson wrote:
> On Mon, 2010-07-26 at 18:28 -0500, Anthony Liguori wrote:
>> On 07/26/2010 05:28 PM, Anthony Liguori wrote:
>>> On 07/26/2010 04:28 PM, Chris Wright wrote:
>>>> Please send in any agenda items you are interested in covering.
>>>
>>> - 0.13 update
>>>   I'll pre-empt the 0.13 question with an answer.  I'm just testing 
>>> the VNC changes and if all goes well, I'll tag tonight.
>>>
>>>   Initial thinking is to keep 0.14 short and target Dec 1st.
>>>
>>> - if danpb can make it, would like to discuss -help output parsing
>>>   summary: help parsing is terrible, but given the fact that 
>>> capabilities is going to take a while to get totally right, would like 
>>> to discuss an interim solution that gives us more flexibility to do 
>>> reasonable things with the help output.
>>
>> - any additional input on probed_raw?
> 
>  - cpu model #s, does anyone know things that would break if we bumped
> the qemu64 model up to 13 (or higher?) and made definitions for
> Conroe/Penryn/Nehalem use more representative model #s?

That was my topic for the call :)

The currenct qemu64 cpu model is a mess, family 6, model 2 is not even a
64 bit processor, plus we enable a bunch of flags that didn't exist in
those processors: pni, popcnt, cx16, sse4a, lm, nx, lahf_lm, svm, abm
(if I got the list right).

Jes

Re: [Qemu-devel] Re: KVM call agenda for July 27

[Kevin Wolf]

Am 27.07.2010 15:00, schrieb Anthony Liguori:
> On 07/27/2010 02:19 AM, Markus Armbruster wrote:
>> Anthony Liguori<anthony@codemonkey.ws>  writes:
>>
>>    
>>> - any additional input on probed_raw?
>>>      
>> Isn't it a fait accompli?  I stopped providing input when commit
>> 79368c81 appeared.
>>    
> 
> No.  79368c81 was to close the security hole (and I do consider it a 
> security hole).  But as I mentioned on the list, I'm also not satisfied 
> with it and that's why I proposed probed_raw.  I was hoping to get a 
> little more input from those that objected to 79368c81 as to whether 
> probed_raw was more agreeable.

Actually I believe qraw is less agreeable. It just too much magic. You
wouldn't expect that your raw images are turned into some other format
that you can't mount or use with any other program any more.

Kevin

[Qemu-devel] Re: KVM call agenda for July 27

[Anthony Liguori]

On 07/27/2010 06:51 AM, Daniel P. Berrange wrote:
> On Mon, Jul 26, 2010 at 05:28:21PM -0500, Anthony Liguori wrote:
>    
>> On 07/26/2010 04:28 PM, Chris Wright wrote:
>>      
>>> Please send in any agenda items you are interested in covering.
>>>
>>>        
>> - 0.13 update
>>    I'll pre-empt the 0.13 question with an answer.  I'm just testing the
>> VNC changes and if all goes well, I'll tag tonight.
>>
>>    Initial thinking is to keep 0.14 short and target Dec 1st.
>>
>> - if danpb can make it, would like to discuss -help output parsing
>>    summary: help parsing is terrible, but given the fact that
>> capabilities is going to take a while to get totally right, would like
>> to discuss an interim solution that gives us more flexibility to do
>> reasonable things with the help output.
>>      
> I'm not able to make this call today&  next week i'm on PTO

No problem.  Enjoy your holiday.

> . I would
> like to think that we could get a suitable capabilities sytem in place
> for 0.14 release. Since 0.13 is nearly ready&  libvirt works with it
> aside from the cache issue which is now addressed in libvirt, I don't
> think its useful to change libvirt further.

So 0.8.2 is broken or did 0.8.2 get fixed?

What changes would need to be made for 0.13 to work with existing 
versions of libvirt?

If we can agree that 0.13 is the last time we make these changes, I'd be 
willing to do it one more time.  I'd strongly suggest switching 
eliminating the help parsing entirely instead of just waiting for 
capabilities.

>   We need to just focus on
> getting capabilities (and QMP in general for that matter) ready for
> 0.14 and not let it slip still further into 0.15.
>    

No objections on my side.

Regards,

Anthony Liguori

> Regards,
> Daniel
>    

[Qemu-devel] Re: KVM call agenda for July 27

[Cole Robinson]

On 07/27/2010 09:30 AM, Anthony Liguori wrote:
> On 07/27/2010 06:51 AM, Daniel P. Berrange wrote:
>> On Mon, Jul 26, 2010 at 05:28:21PM -0500, Anthony Liguori wrote:
>>    
>>> On 07/26/2010 04:28 PM, Chris Wright wrote:
>>>      
>>>> Please send in any agenda items you are interested in covering.
>>>>
>>>>        
>>> - 0.13 update
>>>    I'll pre-empt the 0.13 question with an answer.  I'm just testing the
>>> VNC changes and if all goes well, I'll tag tonight.
>>>
>>>    Initial thinking is to keep 0.14 short and target Dec 1st.
>>>
>>> - if danpb can make it, would like to discuss -help output parsing
>>>    summary: help parsing is terrible, but given the fact that
>>> capabilities is going to take a while to get totally right, would like
>>> to discuss an interim solution that gives us more flexibility to do
>>> reasonable things with the help output.
>>>      
>> I'm not able to make this call today&  next week i'm on PTO
> 
> No problem.  Enjoy your holiday.
> 
>> . I would
>> like to think that we could get a suitable capabilities sytem in place
>> for 0.14 release. Since 0.13 is nearly ready&  libvirt works with it
>> aside from the cache issue which is now addressed in libvirt, I don't
>> think its useful to change libvirt further.
> 
> So 0.8.2 is broken or did 0.8.2 get fixed?
> 

Just to clarify the issues:

1) qemu -help/-version output was changed: libvirt chokes when trying to
parse it: no VMs can use qemu.git/qemu-0.13

2) libvirt improperly parses cache= value from -help output, does not
think emulator supports cache= value. user specified cache values are
not passed on the qemu CLI

Libvirt 0.8.2 fixed the first issue. Libvirt.git will soon fix the
second issue, 0.8.3 is out at the end of the week.

> What changes would need to be made for 0.13 to work with existing 
> versions of libvirt?
> 

- Revert the version string change in
f75ca1ae205f24dae296c82d534c37746f87232f

- Apply Bruces cache -help output patch

Thanks,
Cole

> If we can agree that 0.13 is the last time we make these changes, I'd be 
> willing to do it one more time.  I'd strongly suggest switching 
> eliminating the help parsing entirely instead of just waiting for 
> capabilities.
> 
>>   We need to just focus on
>> getting capabilities (and QMP in general for that matter) ready for
>> 0.14 and not let it slip still further into 0.15.
>>    
> 
> No objections on my side.
> 
> Regards,
> 
> Anthony Liguori
> 
>> Regards,
>> Daniel
>>    
> 

Re: [Qemu-devel] Re: KVM call agenda for July 27

[Markus Armbruster]

Kevin Wolf <kwolf@redhat.com> writes:

> Am 27.07.2010 15:00, schrieb Anthony Liguori:
>> On 07/27/2010 02:19 AM, Markus Armbruster wrote:
>>> Anthony Liguori<anthony@codemonkey.ws>  writes:
>>>
>>>    
>>>> - any additional input on probed_raw?
>>>>      
>>> Isn't it a fait accompli?  I stopped providing input when commit
>>> 79368c81 appeared.
>>>    
>> 
>> No.  79368c81 was to close the security hole (and I do consider it a 
>> security hole).  But as I mentioned on the list, I'm also not satisfied 
>> with it and that's why I proposed probed_raw.  I was hoping to get a 
>> little more input from those that objected to 79368c81 as to whether 
>> probed_raw was more agreeable.
>
> Actually I believe qraw is less agreeable. It just too much magic. You
> wouldn't expect that your raw images are turned into some other format
> that you can't mount or use with any other program any more.

I also dislike probed_raw, for the same reasons.

Raw can't be probed safely, by its very nature.  For historical reasons,
we try anyway.  I think we should stop doing that, even though that
breaks existing use relying on the misfeature.  Announce it now, spit
out scary warnings, kill it for good 1-2 releases later.

If we're unwilling to do that, then I'd *strongly* prefer doing nothing
over silently messing with the raw writes to sector 0 (so does
Christoph, and he explained why).  But since it's already committed, I
figure it's here to stay.

Re: [Qemu-devel] Re: KVM call agenda for July 27

[Anthony Liguori]

On 07/27/2010 10:22 AM, Markus Armbruster wrote:
> Kevin Wolf<kwolf@redhat.com>  writes:
>
>    
>> Am 27.07.2010 15:00, schrieb Anthony Liguori:
>>      
>>> On 07/27/2010 02:19 AM, Markus Armbruster wrote:
>>>        
>>>> Anthony Liguori<anthony@codemonkey.ws>   writes:
>>>>
>>>>
>>>>          
>>>>> - any additional input on probed_raw?
>>>>>
>>>>>            
>>>> Isn't it a fait accompli?  I stopped providing input when commit
>>>> 79368c81 appeared.
>>>>
>>>>          
>>> No.  79368c81 was to close the security hole (and I do consider it a
>>> security hole).  But as I mentioned on the list, I'm also not satisfied
>>> with it and that's why I proposed probed_raw.  I was hoping to get a
>>> little more input from those that objected to 79368c81 as to whether
>>> probed_raw was more agreeable.
>>>        
>> Actually I believe qraw is less agreeable. It just too much magic. You
>> wouldn't expect that your raw images are turned into some other format
>> that you can't mount or use with any other program any more.
>>      
> I also dislike probed_raw, for the same reasons.
>
> Raw can't be probed safely, by its very nature.  For historical reasons,
> we try anyway.  I think we should stop doing that, even though that
> breaks existing use relying on the misfeature.  Announce it now, spit
> out scary warnings, kill it for good 1-2 releases later.
>
> If we're unwilling to do that, then I'd *strongly* prefer doing nothing
> over silently messing with the raw writes to sector 0 (so does
> Christoph, and he explained why).

If we add docs/deprecated-features.txt, schedule removal for at least 1 
year in the future, and put a warning in the code that prints whenever 
raw is probed, I think I could warm up to this.

Since libvirt should be insulating users from this today, I think the 
fall out might not be terrible.

Regards,

Anthony Liguori

>    But since it's already committed, I
> figure it's here to stay.
>    

Re: [Qemu-devel] Re: KVM call agenda for July 27

[Daniel P. Berrange]

On Tue, Jul 27, 2010 at 10:28:04AM -0500, Anthony Liguori wrote:
> On 07/27/2010 10:22 AM, Markus Armbruster wrote:
> >Kevin Wolf<kwolf@redhat.com>  writes:
> >
> >   
> >>Am 27.07.2010 15:00, schrieb Anthony Liguori:
> >>     
> >>>On 07/27/2010 02:19 AM, Markus Armbruster wrote:
> >>>       
> >>>>Anthony Liguori<anthony@codemonkey.ws>   writes:
> >>>>
> >>>>
> >>>>         
> >>>>>- any additional input on probed_raw?
> >>>>>
> >>>>>           
> >>>>Isn't it a fait accompli?  I stopped providing input when commit
> >>>>79368c81 appeared.
> >>>>
> >>>>         
> >>>No.  79368c81 was to close the security hole (and I do consider it a
> >>>security hole).  But as I mentioned on the list, I'm also not satisfied
> >>>with it and that's why I proposed probed_raw.  I was hoping to get a
> >>>little more input from those that objected to 79368c81 as to whether
> >>>probed_raw was more agreeable.
> >>>       
> >>Actually I believe qraw is less agreeable. It just too much magic. You
> >>wouldn't expect that your raw images are turned into some other format
> >>that you can't mount or use with any other program any more.
> >>     
> >I also dislike probed_raw, for the same reasons.
> >
> >Raw can't be probed safely, by its very nature.  For historical reasons,
> >we try anyway.  I think we should stop doing that, even though that
> >breaks existing use relying on the misfeature.  Announce it now, spit
> >out scary warnings, kill it for good 1-2 releases later.
> >
> >If we're unwilling to do that, then I'd *strongly* prefer doing nothing
> >over silently messing with the raw writes to sector 0 (so does
> >Christoph, and he explained why).
> 
> If we add docs/deprecated-features.txt, schedule removal for at least 1 
> year in the future, and put a warning in the code that prints whenever 
> raw is probed, I think I could warm up to this.
> 
> Since libvirt should be insulating users from this today, I think the 
> fall out might not be terrible.

Next libvirt (0.8.3)  will always set format to 'raw' if the user does
not give any alternative. Thus QEMU's probing code will never be run
for the main disk. We can't stop  it probing for backing stores, with
the exception of qcow2 images using the embedded backingstore format.

BTW, it is questionable whether VMDK should be probing for backing
store format all, rather than forcing all VMDK backing stores to
also be VMDK. (If we want  full compliance/compatbility with VMWare's
impl which obviously doesn't use stuff like qcow2)

For cow & qcow perhaps we should mark them as deprecated and explicitly
recommend people to use qcow2 instead ? Or make them only use backing
stores whose format matches the main store ?

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 July 27

[Avi Kivity]

  On 07/27/2010 06:28 PM, Anthony Liguori wrote:
>
> If we add docs/deprecated-features.txt, schedule removal for at least 
> 1 year in the future, and put a warning in the code that prints 
> whenever raw is probed, I think I could warm up to this.
>
> Since libvirt should be insulating users from this today, I think the 
> fall out might not be terrible.

On a related note, we should ask libvirt to make qemu stderr output 
available to its users, or perhaps an ABRT plugin to report such 
messages from libvirt's logs.

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

Re: [Qemu-devel] Re: KVM call agenda for July 27

[Daniel P. Berrange]

On Tue, Jul 27, 2010 at 07:17:06PM +0300, Avi Kivity wrote:
>  On 07/27/2010 06:28 PM, Anthony Liguori wrote:
> >
> >If we add docs/deprecated-features.txt, schedule removal for at least 
> >1 year in the future, and put a warning in the code that prints 
> >whenever raw is probed, I think I could warm up to this.
> >
> >Since libvirt should be insulating users from this today, I think the 
> >fall out might not be terrible.
> 
> On a related note, we should ask libvirt to make qemu stderr output 
> available to its users, or perhaps an ABRT plugin to report such 
> messages from libvirt's logs.

QEMU stderr+out is already recorded in /var/lib/libvirt/qemu/$GUESTNAME.log
along with the env variables and argv used to spawn it. Or did you mean 
provide an API + virsh command /virt-manager UI for accessing the logs ?

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 July 27

[Chris Wright]

* Daniel P. Berrange (berrange@redhat.com) wrote:
> On Tue, Jul 27, 2010 at 07:17:06PM +0300, Avi Kivity wrote:
> >  On 07/27/2010 06:28 PM, Anthony Liguori wrote:
> > >
> > >If we add docs/deprecated-features.txt, schedule removal for at least 
> > >1 year in the future, and put a warning in the code that prints 
> > >whenever raw is probed, I think I could warm up to this.
> > >
> > >Since libvirt should be insulating users from this today, I think the 
> > >fall out might not be terrible.
> > 
> > On a related note, we should ask libvirt to make qemu stderr output 
> > available to its users, or perhaps an ABRT plugin to report such 
> > messages from libvirt's logs.
> 
> QEMU stderr+out is already recorded in /var/lib/libvirt/qemu/$GUESTNAME.log
> along with the env variables and argv used to spawn it. Or did you mean 
> provide an API + virsh command /virt-manager UI for accessing the logs ?

I read that to mean...propagate stderr from qemu to be right in front of
the user.  So that's output from virsh or in virt-manager.  Trouble is,
that's only useful (at best) when starting a guest.  Perhaps some
virt-manager thing (an exclamation point to show there's errors in the
log and a way to read them), and a virsh utility to match (although
that'd require the user to actually poll the interface, at which point
they can just as easily just look at the log).

thanks,
-chris

Re: [Qemu-devel] Re: KVM call agenda for July 27

[Avi Kivity]

  On 07/27/2010 07:29 PM, Chris Wright wrote:
>
>> QEMU stderr+out is already recorded in /var/lib/libvirt/qemu/$GUESTNAME.log
>> along with the env variables and argv used to spawn it. Or did you mean
>> provide an API + virsh command /virt-manager UI for accessing the logs ?
> I read that to mean...propagate stderr from qemu to be right in front of
> the user.

Yes, that's what I meant.

> So that's output from virsh or in virt-manager.  Trouble is,
> that's only useful (at best) when starting a guest.  Perhaps some
> virt-manager thing (an exclamation point to show there's errors in the
> log and a way to read them), and a virsh utility to match (although
> that'd require the user to actually poll the interface, at which point
> they can just as easily just look at the log).

If things work there's  no reason for the user to go look at the logs.  
An exclamation point invites clicking.

Even better would be an ABRT plugin, so if something goes (marginally) 
wrong, the siren pops up and you're invited to report the bug.

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

Re: [Qemu-devel] Re: KVM call agenda for July 27

[Chris Wright]

* Avi Kivity (avi@redhat.com) wrote:
>  On 07/27/2010 07:29 PM, Chris Wright wrote:
> >
> >>QEMU stderr+out is already recorded in /var/lib/libvirt/qemu/$GUESTNAME.log
> >>along with the env variables and argv used to spawn it. Or did you mean
> >>provide an API + virsh command /virt-manager UI for accessing the logs ?
> >I read that to mean...propagate stderr from qemu to be right in front of
> >the user.
> 
> Yes, that's what I meant.
> 
> >So that's output from virsh or in virt-manager.  Trouble is,
> >that's only useful (at best) when starting a guest.  Perhaps some
> >virt-manager thing (an exclamation point to show there's errors in the
> >log and a way to read them), and a virsh utility to match (although
> >that'd require the user to actually poll the interface, at which point
> >they can just as easily just look at the log).
> 
> If things work there's  no reason for the user to go look at the
> logs.  An exclamation point invites clicking.
> 
> Even better would be an ABRT plugin, so if something goes
> (marginally) wrong, the siren pops up and you're invited to report
> the bug.

Despite some of the ABRT growing pains, ABRT plugin seems like a good
idea.  I don't know enough of the plugins to know if that requires
formatted output and just grepping for some known regexps.

thanks,
-chris

Re: [Qemu-devel] Re: KVM call agenda for July 27

[Avi Kivity]

  On 07/27/2010 07:36 PM, Chris Wright wrote:
>
>> If things work there's  no reason for the user to go look at the
>> logs.  An exclamation point invites clicking.
>>
>> Even better would be an ABRT plugin, so if something goes
>> (marginally) wrong, the siren pops up and you're invited to report
>> the bug.
> Despite some of the ABRT growing pains, ABRT plugin seems like a good
> idea.  I don't know enough of the plugins to know if that requires
> formatted output and just grepping for some known regexps.

It's annoying to us old hands, but it does give that nice integrated 
system feel that we're missing, and it works even if virt-manager is in 
the background (or if you don't use virt-manager at all).

Given that there's a kerneloops pluging that presumably does similar 
parsing, I don't think it's too hard:

$ size /usr/lib64/abrt/libKerneloopsScanner.so
    text       data        bss        dec        hex    filename
   18293       1416         16      19725       4d0d    
/usr/lib64/abrt/libKerneloopsScanner.so

-- 

error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Re: KVM call agenda for July 27

[Daniel P. Berrange]

On Tue, Jul 27, 2010 at 09:29:13AM -0700, Chris Wright wrote:
> * Daniel P. Berrange (berrange@redhat.com) wrote:
> > On Tue, Jul 27, 2010 at 07:17:06PM +0300, Avi Kivity wrote:
> > >  On 07/27/2010 06:28 PM, Anthony Liguori wrote:
> > > >
> > > >If we add docs/deprecated-features.txt, schedule removal for at least 
> > > >1 year in the future, and put a warning in the code that prints 
> > > >whenever raw is probed, I think I could warm up to this.
> > > >
> > > >Since libvirt should be insulating users from this today, I think the 
> > > >fall out might not be terrible.
> > > 
> > > On a related note, we should ask libvirt to make qemu stderr output 
> > > available to its users, or perhaps an ABRT plugin to report such 
> > > messages from libvirt's logs.
> > 
> > QEMU stderr+out is already recorded in /var/lib/libvirt/qemu/$GUESTNAME.log
> > along with the env variables and argv used to spawn it. Or did you mean 
> > provide an API + virsh command /virt-manager UI for accessing the logs ?
> 
> I read that to mean...propagate stderr from qemu to be right in front of
> the user.  So that's output from virsh or in virt-manager.  Trouble is,
> that's only useful (at best) when starting a guest.  Perhaps some
> virt-manager thing (an exclamation point to show there's errors in the
> log and a way to read them), and a virsh utility to match (although
> that'd require the user to actually poll the interface, at which point
> they can just as easily just look at the log).

We already propagate the stderr back to the client when guest startup
fails.

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 July 27

[Avi Kivity]

  On 07/27/2010 07:42 PM, Daniel P. Berrange wrote:
>
>> I read that to mean...propagate stderr from qemu to be right in front of
>> the user.  So that's output from virsh or in virt-manager.  Trouble is,
>> that's only useful (at best) when starting a guest.  Perhaps some
>> virt-manager thing (an exclamation point to show there's errors in the
>> log and a way to read them), and a virsh utility to match (although
>> that'd require the user to actually poll the interface, at which point
>> they can just as easily just look at the log).
> We already propagate the stderr back to the client when guest startup
> fails.

I'm talking about when it doesn't fail, just spews out some warnings.

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

Re: [Qemu-devel] Re: KVM call agenda for July 27

[Avi Kivity]

  On 07/27/2010 07:47 PM, Avi Kivity wrote:
>  On 07/27/2010 07:42 PM, Daniel P. Berrange wrote:
>>
>>> I read that to mean...propagate stderr from qemu to be right in 
>>> front of
>>> the user.  So that's output from virsh or in virt-manager.  Trouble is,
>>> that's only useful (at best) when starting a guest.  Perhaps some
>>> virt-manager thing (an exclamation point to show there's errors in the
>>> log and a way to read them), and a virsh utility to match (although
>>> that'd require the user to actually poll the interface, at which point
>>> they can just as easily just look at the log).
>> We already propagate the stderr back to the client when guest startup
>> fails.
>
> I'm talking about when it doesn't fail, just spews out some warnings.
>

Note, it needn't be during startup.  If qemu says something while the 
guest is running, we need to get it to bugzilla, just like a kernel 
WARN_ON() or BUG_ON() will make it to kerneloops.org.

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

Re: [Qemu-devel] Re: KVM call agenda for July 27

[Daniel P. Berrange]

On Tue, Jul 27, 2010 at 07:42:34PM +0300, Avi Kivity wrote:
>  On 07/27/2010 07:36 PM, Chris Wright wrote:
> >
> >>If things work there's  no reason for the user to go look at the
> >>logs.  An exclamation point invites clicking.
> >>
> >>Even better would be an ABRT plugin, so if something goes
> >>(marginally) wrong, the siren pops up and you're invited to report
> >>the bug.
> >Despite some of the ABRT growing pains, ABRT plugin seems like a good
> >idea.  I don't know enough of the plugins to know if that requires
> >formatted output and just grepping for some known regexps.
> 
> It's annoying to us old hands, but it does give that nice integrated 
> system feel that we're missing, and it works even if virt-manager is in 
> the background (or if you don't use virt-manager at all).
> 
> Given that there's a kerneloops pluging that presumably does similar 
> parsing, I don't think it's too hard:
> 
> $ size /usr/lib64/abrt/libKerneloopsScanner.so
>    text       data        bss        dec        hex    filename
>   18293       1416         16      19725       4d0d    
> /usr/lib64/abrt/libKerneloopsScanner.so

One issue though - a kernel oopps is a clear bug. A failure to start
QEMU is often just a mis-configuration, not a bug. We don't want to spa
developers with ABRT reports everytime a user misconfigures a guest.

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 July 27

[Avi Kivity]

  On 07/27/2010 08:01 PM, Daniel P. Berrange wrote:
>
>> It's annoying to us old hands, but it does give that nice integrated
>> system feel that we're missing, and it works even if virt-manager is in
>> the background (or if you don't use virt-manager at all).
>>
>> Given that there's a kerneloops pluging that presumably does similar
>> parsing, I don't think it's too hard:
>>
>> $ size /usr/lib64/abrt/libKerneloopsScanner.so
>>     text       data        bss        dec        hex    filename
>>    18293       1416         16      19725       4d0d
>> /usr/lib64/abrt/libKerneloopsScanner.so
> One issue though - a kernel oopps is a clear bug. A failure to start
> QEMU is often just a mis-configuration, not a bug. We don't want to spa
> developers with ABRT reports everytime a user misconfigures a guest.

Shouldn't libvirt/virt-manager know that the configuration will fail 
beforehand?

Well, I guess for things like broken paths or bad permissions, no.

So we should clearly differentiate between qemu reporting its own bugs 
(a warn() function) and qemu reporting user errors.  In fact that's what 
the kernel does, ordinary printk()s aren't reported, just bugs.

-- 
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 July 27

[Markus Armbruster]

Anthony Liguori <anthony@codemonkey.ws> writes:

> On 07/27/2010 10:22 AM, Markus Armbruster wrote:
>> Kevin Wolf<kwolf@redhat.com>  writes:
>>
>>    
>>> Am 27.07.2010 15:00, schrieb Anthony Liguori:
>>>      
>>>> On 07/27/2010 02:19 AM, Markus Armbruster wrote:
>>>>        
>>>>> Anthony Liguori<anthony@codemonkey.ws>   writes:
>>>>>
>>>>>
>>>>>          
>>>>>> - any additional input on probed_raw?
>>>>>>
>>>>>>            
>>>>> Isn't it a fait accompli?  I stopped providing input when commit
>>>>> 79368c81 appeared.
>>>>>
>>>>>          
>>>> No.  79368c81 was to close the security hole (and I do consider it a
>>>> security hole).  But as I mentioned on the list, I'm also not satisfied
>>>> with it and that's why I proposed probed_raw.  I was hoping to get a
>>>> little more input from those that objected to 79368c81 as to whether
>>>> probed_raw was more agreeable.
>>>>        
>>> Actually I believe qraw is less agreeable. It just too much magic. You
>>> wouldn't expect that your raw images are turned into some other format
>>> that you can't mount or use with any other program any more.
>>>      
>> I also dislike probed_raw, for the same reasons.
>>
>> Raw can't be probed safely, by its very nature.  For historical reasons,
>> we try anyway.  I think we should stop doing that, even though that
>> breaks existing use relying on the misfeature.  Announce it now, spit
>> out scary warnings, kill it for good 1-2 releases later.
>>
>> If we're unwilling to do that, then I'd *strongly* prefer doing nothing
>> over silently messing with the raw writes to sector 0 (so does
>> Christoph, and he explained why).
>
> If we add docs/deprecated-features.txt, schedule removal for at least
> 1 year in the future, and put a warning in the code that prints
> whenever raw is probed, I think I could warm up to this.
>
> Since libvirt should be insulating users from this today, I think the
> fall out might not be terrible.

Okay, I'll prepare a patch.

Re: [Qemu-devel] Re: KVM call agenda for July 27

[Kevin Wolf]

Am 28.07.2010 13:22, schrieb Markus Armbruster:
> Anthony Liguori <anthony@codemonkey.ws> writes:
> 
>> On 07/27/2010 10:22 AM, Markus Armbruster wrote:
>>> Kevin Wolf<kwolf@redhat.com>  writes:
>>>
>>>    
>>>> Am 27.07.2010 15:00, schrieb Anthony Liguori:
>>>>      
>>>>> On 07/27/2010 02:19 AM, Markus Armbruster wrote:
>>>>>        
>>>>>> Anthony Liguori<anthony@codemonkey.ws>   writes:
>>>>>>
>>>>>>
>>>>>>          
>>>>>>> - any additional input on probed_raw?
>>>>>>>
>>>>>>>            
>>>>>> Isn't it a fait accompli?  I stopped providing input when commit
>>>>>> 79368c81 appeared.
>>>>>>
>>>>>>          
>>>>> No.  79368c81 was to close the security hole (and I do consider it a
>>>>> security hole).  But as I mentioned on the list, I'm also not satisfied
>>>>> with it and that's why I proposed probed_raw.  I was hoping to get a
>>>>> little more input from those that objected to 79368c81 as to whether
>>>>> probed_raw was more agreeable.
>>>>>        
>>>> Actually I believe qraw is less agreeable. It just too much magic. You
>>>> wouldn't expect that your raw images are turned into some other format
>>>> that you can't mount or use with any other program any more.
>>>>      
>>> I also dislike probed_raw, for the same reasons.
>>>
>>> Raw can't be probed safely, by its very nature.  For historical reasons,
>>> we try anyway.  I think we should stop doing that, even though that
>>> breaks existing use relying on the misfeature.  Announce it now, spit
>>> out scary warnings, kill it for good 1-2 releases later.
>>>
>>> If we're unwilling to do that, then I'd *strongly* prefer doing nothing
>>> over silently messing with the raw writes to sector 0 (so does
>>> Christoph, and he explained why).
>>
>> If we add docs/deprecated-features.txt, schedule removal for at least
>> 1 year in the future, and put a warning in the code that prints
>> whenever raw is probed, I think I could warm up to this.
>>
>> Since libvirt should be insulating users from this today, I think the
>> fall out might not be terrible.
> 
> Okay, I'll prepare a patch.

This kills -hda and friends for raw images. I'm not sure this is a good
idea.

Kevin

Re: [Qemu-devel] Re: KVM call agenda for July 27

[Markus Armbruster]

Kevin Wolf <kwolf@redhat.com> writes:

> Am 28.07.2010 13:22, schrieb Markus Armbruster:
>> Anthony Liguori <anthony@codemonkey.ws> writes:
>> 
>>> On 07/27/2010 10:22 AM, Markus Armbruster wrote:
[...]
>>>> Raw can't be probed safely, by its very nature.  For historical reasons,
>>>> we try anyway.  I think we should stop doing that, even though that
>>>> breaks existing use relying on the misfeature.  Announce it now, spit
>>>> out scary warnings, kill it for good 1-2 releases later.
>>>>
>>>> If we're unwilling to do that, then I'd *strongly* prefer doing nothing
>>>> over silently messing with the raw writes to sector 0 (so does
>>>> Christoph, and he explained why).
>>>
>>> If we add docs/deprecated-features.txt, schedule removal for at least
>>> 1 year in the future, and put a warning in the code that prints
>>> whenever raw is probed, I think I could warm up to this.
>>>
>>> Since libvirt should be insulating users from this today, I think the
>>> fall out might not be terrible.
>> 
>> Okay, I'll prepare a patch.
>
> This kills -hda and friends for raw images. I'm not sure this is a good
> idea.

Please wait and see my patch.