* Re: [Qemu-devel] Re: KVM call agenda for July 27
@ 2010-07-27 15:28 ` Anthony Liguori
0 siblings, 0 replies; 54+ messages in thread
From: Anthony Liguori @ 2010-07-27 15:28 UTC (permalink / raw)
To: Markus Armbruster; +Cc: Kevin Wolf, Chris Wright, qemu-devel, kvm
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.
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
2010-07-27 15:28 ` Anthony Liguori
@ 2010-07-27 15:37 ` Daniel P. Berrange
-1 siblings, 0 replies; 54+ messages in thread
From: Daniel P. Berrange @ 2010-07-27 15:37 UTC (permalink / raw)
To: Anthony Liguori
Cc: Markus Armbruster, Kevin Wolf, Chris Wright, qemu-devel, kvm
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 :|
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
@ 2010-07-27 15:37 ` Daniel P. Berrange
0 siblings, 0 replies; 54+ messages in thread
From: Daniel P. Berrange @ 2010-07-27 15:37 UTC (permalink / raw)
To: Anthony Liguori
Cc: Kevin Wolf, Chris Wright, Markus Armbruster, kvm, qemu-devel
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 :|
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
2010-07-27 15:28 ` Anthony Liguori
@ 2010-07-27 16:17 ` Avi Kivity
-1 siblings, 0 replies; 54+ messages in thread
From: Avi Kivity @ 2010-07-27 16:17 UTC (permalink / raw)
To: Anthony Liguori
Cc: Markus Armbruster, Kevin Wolf, Chris Wright, kvm, qemu-devel
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
@ 2010-07-27 16:17 ` Avi Kivity
0 siblings, 0 replies; 54+ messages in thread
From: Avi Kivity @ 2010-07-27 16:17 UTC (permalink / raw)
To: Anthony Liguori
Cc: Kevin Wolf, Chris Wright, Markus Armbruster, kvm, qemu-devel
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
2010-07-27 16:17 ` Avi Kivity
@ 2010-07-27 16:24 ` Daniel P. Berrange
-1 siblings, 0 replies; 54+ messages in thread
From: Daniel P. Berrange @ 2010-07-27 16:24 UTC (permalink / raw)
To: Avi Kivity
Cc: Anthony Liguori, Markus Armbruster, Kevin Wolf, Chris Wright, kvm,
qemu-devel
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 :|
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
@ 2010-07-27 16:24 ` Daniel P. Berrange
0 siblings, 0 replies; 54+ messages in thread
From: Daniel P. Berrange @ 2010-07-27 16:24 UTC (permalink / raw)
To: Avi Kivity; +Cc: Kevin Wolf, Chris Wright, kvm, qemu-devel, Markus Armbruster
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 :|
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
2010-07-27 16:24 ` Daniel P. Berrange
@ 2010-07-27 16:29 ` Chris Wright
-1 siblings, 0 replies; 54+ messages in thread
From: Chris Wright @ 2010-07-27 16:29 UTC (permalink / raw)
To: Daniel P. Berrange
Cc: Avi Kivity, Anthony Liguori, Markus Armbruster, Kevin Wolf,
Chris Wright, kvm, qemu-devel
* 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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
@ 2010-07-27 16:29 ` Chris Wright
0 siblings, 0 replies; 54+ messages in thread
From: Chris Wright @ 2010-07-27 16:29 UTC (permalink / raw)
To: Daniel P. Berrange
Cc: Kevin Wolf, Chris Wright, kvm, Markus Armbruster, qemu-devel,
Avi Kivity
* 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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
2010-07-27 16:29 ` Chris Wright
@ 2010-07-27 16:32 ` Avi Kivity
-1 siblings, 0 replies; 54+ messages in thread
From: Avi Kivity @ 2010-07-27 16:32 UTC (permalink / raw)
To: Chris Wright
Cc: Daniel P. Berrange, Anthony Liguori, Markus Armbruster,
Kevin Wolf, kvm, qemu-devel
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
@ 2010-07-27 16:32 ` Avi Kivity
0 siblings, 0 replies; 54+ messages in thread
From: Avi Kivity @ 2010-07-27 16:32 UTC (permalink / raw)
To: Chris Wright; +Cc: Kevin Wolf, kvm, qemu-devel, Markus Armbruster
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
2010-07-27 16:32 ` Avi Kivity
@ 2010-07-27 16:36 ` Chris Wright
-1 siblings, 0 replies; 54+ messages in thread
From: Chris Wright @ 2010-07-27 16:36 UTC (permalink / raw)
To: Avi Kivity
Cc: Chris Wright, Daniel P. Berrange, Anthony Liguori,
Markus Armbruster, Kevin Wolf, kvm, qemu-devel
* 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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
@ 2010-07-27 16:36 ` Chris Wright
0 siblings, 0 replies; 54+ messages in thread
From: Chris Wright @ 2010-07-27 16:36 UTC (permalink / raw)
To: Avi Kivity; +Cc: Chris Wright, Kevin Wolf, kvm, Markus Armbruster, qemu-devel
* 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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
2010-07-27 16:36 ` Chris Wright
@ 2010-07-27 16:42 ` Avi Kivity
-1 siblings, 0 replies; 54+ messages in thread
From: Avi Kivity @ 2010-07-27 16:42 UTC (permalink / raw)
To: Chris Wright
Cc: Daniel P. Berrange, Anthony Liguori, Markus Armbruster,
Kevin Wolf, kvm, qemu-devel
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
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [Qemu-devel] Re: KVM call agenda for July 27
@ 2010-07-27 16:42 ` Avi Kivity
0 siblings, 0 replies; 54+ messages in thread
From: Avi Kivity @ 2010-07-27 16:42 UTC (permalink / raw)
To: Chris Wright; +Cc: Kevin Wolf, kvm, qemu-devel, Markus Armbruster
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
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [Qemu-devel] Re: KVM call agenda for July 27
2010-07-27 16:42 ` Avi Kivity
@ 2010-07-27 17:01 ` Daniel P. Berrange
-1 siblings, 0 replies; 54+ messages in thread
From: Daniel P. Berrange @ 2010-07-27 17:01 UTC (permalink / raw)
To: Avi Kivity
Cc: Chris Wright, Anthony Liguori, Markus Armbruster, Kevin Wolf, kvm,
qemu-devel
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 :|
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
@ 2010-07-27 17:01 ` Daniel P. Berrange
0 siblings, 0 replies; 54+ messages in thread
From: Daniel P. Berrange @ 2010-07-27 17:01 UTC (permalink / raw)
To: Avi Kivity; +Cc: Chris Wright, Kevin Wolf, kvm, qemu-devel, Markus Armbruster
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 :|
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
2010-07-27 17:01 ` Daniel P. Berrange
@ 2010-07-27 17:37 ` Avi Kivity
-1 siblings, 0 replies; 54+ messages in thread
From: Avi Kivity @ 2010-07-27 17:37 UTC (permalink / raw)
To: Daniel P. Berrange
Cc: Chris Wright, Anthony Liguori, Markus Armbruster, Kevin Wolf, kvm,
qemu-devel
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.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
@ 2010-07-27 17:37 ` Avi Kivity
0 siblings, 0 replies; 54+ messages in thread
From: Avi Kivity @ 2010-07-27 17:37 UTC (permalink / raw)
To: Daniel P. Berrange
Cc: Chris Wright, Kevin Wolf, kvm, qemu-devel, Markus Armbruster
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.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
2010-07-27 16:29 ` Chris Wright
@ 2010-07-27 16:42 ` Daniel P. Berrange
-1 siblings, 0 replies; 54+ messages in thread
From: Daniel P. Berrange @ 2010-07-27 16:42 UTC (permalink / raw)
To: Chris Wright
Cc: Avi Kivity, Anthony Liguori, Markus Armbruster, Kevin Wolf, kvm,
qemu-devel
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 :|
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
@ 2010-07-27 16:42 ` Daniel P. Berrange
0 siblings, 0 replies; 54+ messages in thread
From: Daniel P. Berrange @ 2010-07-27 16:42 UTC (permalink / raw)
To: Chris Wright; +Cc: Kevin Wolf, kvm, qemu-devel, Markus Armbruster, Avi Kivity
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 :|
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
2010-07-27 16:42 ` Daniel P. Berrange
@ 2010-07-27 16:47 ` Avi Kivity
-1 siblings, 0 replies; 54+ messages in thread
From: Avi Kivity @ 2010-07-27 16:47 UTC (permalink / raw)
To: Daniel P. Berrange
Cc: Chris Wright, Anthony Liguori, Markus Armbruster, Kevin Wolf, kvm,
qemu-devel
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
@ 2010-07-27 16:47 ` Avi Kivity
0 siblings, 0 replies; 54+ messages in thread
From: Avi Kivity @ 2010-07-27 16:47 UTC (permalink / raw)
To: Daniel P. Berrange
Cc: Chris Wright, Kevin Wolf, kvm, qemu-devel, Markus Armbruster
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
2010-07-27 16:47 ` Avi Kivity
@ 2010-07-27 16:48 ` Avi Kivity
-1 siblings, 0 replies; 54+ messages in thread
From: Avi Kivity @ 2010-07-27 16:48 UTC (permalink / raw)
To: Daniel P. Berrange
Cc: Chris Wright, Anthony Liguori, Markus Armbruster, Kevin Wolf, kvm,
qemu-devel
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
@ 2010-07-27 16:48 ` Avi Kivity
0 siblings, 0 replies; 54+ messages in thread
From: Avi Kivity @ 2010-07-27 16:48 UTC (permalink / raw)
To: Daniel P. Berrange
Cc: Chris Wright, Kevin Wolf, kvm, qemu-devel, Markus Armbruster
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
2010-07-27 15:28 ` Anthony Liguori
` (2 preceding siblings ...)
(?)
@ 2010-07-28 11:22 ` Markus Armbruster
2010-07-28 11:25 ` Kevin Wolf
-1 siblings, 1 reply; 54+ messages in thread
From: Markus Armbruster @ 2010-07-28 11:22 UTC (permalink / raw)
To: Anthony Liguori; +Cc: Kevin Wolf, Chris Wright, qemu-devel, kvm
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.
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [Qemu-devel] Re: KVM call agenda for July 27
2010-07-28 11:22 ` Markus Armbruster
@ 2010-07-28 11:25 ` Kevin Wolf
0 siblings, 0 replies; 54+ messages in thread
From: Kevin Wolf @ 2010-07-28 11:25 UTC (permalink / raw)
To: Markus Armbruster; +Cc: Anthony Liguori, Chris Wright, qemu-devel, kvm
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
@ 2010-07-28 11:25 ` Kevin Wolf
0 siblings, 0 replies; 54+ messages in thread
From: Kevin Wolf @ 2010-07-28 11:25 UTC (permalink / raw)
To: Markus Armbruster; +Cc: Chris Wright, qemu-devel, kvm
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Qemu-devel] Re: KVM call agenda for July 27
2010-07-28 11:25 ` Kevin Wolf
(?)
@ 2010-07-28 13:08 ` Markus Armbruster
-1 siblings, 0 replies; 54+ messages in thread
From: Markus Armbruster @ 2010-07-28 13:08 UTC (permalink / raw)
To: Kevin Wolf; +Cc: Chris Wright, qemu-devel, kvm
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.
^ permalink raw reply [flat|nested] 54+ messages in thread