Re: [Qemu-devel] Re: KVM call agenda for July 27
Anthony Liguori anth...@codemonkey.ws writes: On 07/27/2010 10:22 AM, Markus Armbruster wrote: Kevin Wolfkw...@redhat.com writes: Am 27.07.2010 15:00, schrieb Anthony Liguori: On 07/27/2010 02:19 AM, Markus Armbruster wrote: Anthony Liguorianth...@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
Am 28.07.2010 13:22, schrieb Markus Armbruster: Anthony Liguori anth...@codemonkey.ws writes: On 07/27/2010 10:22 AM, Markus Armbruster wrote: Kevin Wolfkw...@redhat.com writes: Am 27.07.2010 15:00, schrieb Anthony Liguori: On 07/27/2010 02:19 AM, Markus Armbruster wrote: Anthony Liguorianth...@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
Kevin Wolf kw...@redhat.com writes: Am 28.07.2010 13:22, schrieb Markus Armbruster: Anthony Liguori anth...@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.
[Qemu-devel] Re: KVM call agenda for July 27
Anthony Liguori anth...@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
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
On 07/27/2010 02:19 AM, Markus Armbruster wrote: Anthony Liguorianth...@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
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
Am 27.07.2010 15:00, schrieb Anthony Liguori: On 07/27/2010 02:19 AM, Markus Armbruster wrote: Anthony Liguorianth...@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
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
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
Kevin Wolf kw...@redhat.com writes: Am 27.07.2010 15:00, schrieb Anthony Liguori: On 07/27/2010 02:19 AM, Markus Armbruster wrote: Anthony Liguorianth...@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
On 07/27/2010 10:22 AM, Markus Armbruster wrote: Kevin Wolfkw...@redhat.com writes: Am 27.07.2010 15:00, schrieb Anthony Liguori: On 07/27/2010 02:19 AM, Markus Armbruster wrote: Anthony Liguorianth...@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
On Tue, Jul 27, 2010 at 10:28:04AM -0500, Anthony Liguori wrote: On 07/27/2010 10:22 AM, Markus Armbruster wrote: Kevin Wolfkw...@redhat.com writes: Am 27.07.2010 15:00, schrieb Anthony Liguori: On 07/27/2010 02:19 AM, Markus Armbruster wrote: Anthony Liguorianth...@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
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
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
* Daniel P. Berrange (berra...@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
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
* Avi Kivity (a...@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
On Tue, Jul 27, 2010 at 09:29:13AM -0700, Chris Wright wrote: * Daniel P. Berrange (berra...@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
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 databssdechexfilename 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
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
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
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 databssdechexfilename 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
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 databssdechexfilename 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.
[Qemu-devel] Re: KVM call agenda for July 27
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Qemu-devel] Re: KVM call agenda for July 27
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Qemu-devel] Re: KVM call agenda for July 27
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?
