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 -- 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
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 Liguori 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 -- 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
Re: [Qemu-devel] Re: KVM call agenda for July 27
Kevin Wolf writes: > Am 27.07.2010 15:00, schrieb Anthony Liguori: >> On 07/27/2010 02:19 AM, Markus Armbruster wrote: >>> Anthony Liguori 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. -- 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
Re: [Qemu-devel] Re: KVM call agenda for July 27
On 07/27/2010 10:22 AM, Markus Armbruster wrote: Kevin Wolf writes: Am 27.07.2010 15:00, schrieb Anthony Liguori: On 07/27/2010 02:19 AM, Markus Armbruster wrote: Anthony Liguori 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. -- 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
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 Wolf writes: > > > > > >>Am 27.07.2010 15:00, schrieb Anthony Liguori: > >> > >>>On 07/27/2010 02:19 AM, Markus Armbruster wrote: > >>> > Anthony Liguori 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 :| -- 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
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 -- 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
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 :| -- 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
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 -- 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
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 -- 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
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 -- 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
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 -- 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
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 :| -- 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
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 -- 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
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 -- 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
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 :| -- 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
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. -- 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
Re: [Qemu-devel] Re: KVM call agenda for July 27
Anthony Liguori writes: > On 07/27/2010 10:22 AM, Markus Armbruster wrote: >> Kevin Wolf writes: >> >> >>> Am 27.07.2010 15:00, schrieb Anthony Liguori: >>> On 07/27/2010 02:19 AM, Markus Armbruster wrote: > Anthony Liguori 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. -- 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
Re: [Qemu-devel] Re: KVM call agenda for July 27
Am 28.07.2010 13:22, schrieb Markus Armbruster: > Anthony Liguori writes: > >> On 07/27/2010 10:22 AM, Markus Armbruster wrote: >>> Kevin Wolf writes: >>> >>> Am 27.07.2010 15:00, schrieb Anthony Liguori: > On 07/27/2010 02:19 AM, Markus Armbruster wrote: > >> Anthony Liguori 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 -- 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
Re: [Qemu-devel] Re: KVM call agenda for July 27
Kevin Wolf writes: > Am 28.07.2010 13:22, schrieb Markus Armbruster: >> Anthony Liguori 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. -- 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
