Hi, Daniel
Thank you for committing virsh log patch.
> Way simpler, that works, I just fixed a couple of things:
> - removed defines for buffer size which were not needed anymore
Oops, sorry. I had forgotten to erase it.
> - if no log file name was given do not try to open it
Okey. I
On Wed, Jun 06, 2007 at 05:39:40PM +0900, Nobuhiro Itou wrote:
> > I expect the use to be the following:
> > - users uses virsh for virtualization operation
> > - something suddenly does not work
> > - then he re-runs the command with logging
> > - then he can analyze the log
Hi, Daniel
Thank you for your comment and code review.
> > > But since the patch is relatively simple based on existing virsh logging
> > > code, I think this could go as a command line option for virsh, for
> > > example
> > >--log filename
> > > where the detailed logs can then be saved
On Fri, Jun 01, 2007 at 07:35:00PM +0900, Nobuhiro Itou wrote:
> Hi, Daniel
Hi Nobuhiro,
> > But since the patch is relatively simple based on existing virsh logging
> > code, I think this could go as a command line option for virsh, for example
> >--log filename
> > where the detailed lo
Hi, Daniel
Thank you for your comment.
> My experience with systematic logging at command line level is that
> you end up polluting your file system with (hidden) log files, and while it
> may be fine for a developper it's not something you want to inflict to
> your customers. Also the fixed na
On Tue, May 29, 2007 at 11:52:08AM +0100, Richard W.M. Jones wrote:
> Did you see my other response to this?
>
> https://www.redhat.com/archives/libvir-list/2007-May/msg00256.html
>
> That script, modified a bit further (see attachment) does logging fairly
> well. Having it invoked as a wrapper
Daniel Veillard wrote:
[...]
Morning Daniel,
My experience with systematic logging at command line level is that
you end up polluting your file system with (hidden) log files, and while it
may be fine for a developper it's not something you want to inflict to
your customers. Also the fixed na
On Tue, May 22, 2007 at 03:15:03PM +0100, Richard W.M. Jones wrote:
> Nobuhiro Itou wrote:
> >>But my broader point is: What use would this feature be, since you can
> >>capture the output of virsh easily using shell redirection? The Xen
> >>'xm' command doesn't have this feature and I don't kno
On Tue, 2007-05-22 at 20:32 +0100, Daniel P. Berrange wrote:
> On Tue, May 22, 2007 at 03:15:03PM +0100, Richard W.M. Jones wrote:
> >
> > I really think we should be looking at either a logging library, or
> > (better) syslog. These problems -- like logfile maxsize, logfile
> > location, log r
Hi, Rich
Thank you for your suggestion.
We also think this kind of solution.
But from our view,
the best solution is inclusion of this patch to libvirt.
the second solution is to use your suggestion.
So his mail is asking the logging policy of libvirt.
Thanks
Atsushi SAKAI
"Richard W.M. Jone
Nobuhiro Itou wrote:
Certainly, virsh does not provide enough information now.
But I want virsh to provide useful information in the future.
First, I want to implement this logging function.
In addition, I think that we should not let customers take trouble.
Cannot you apply this patch?
The
Hi, Dan
Thank you for your comment.
> > >>But my broader point is: What use would this feature be, since you can
> > >>capture the output of virsh easily using shell redirection? The Xen
> > >>'xm' command doesn't have this feature and I don't know if anyone has
> > >>asked for it.
> > >
> >
On Tue, May 22, 2007 at 03:15:03PM +0100, Richard W.M. Jones wrote:
> Nobuhiro Itou wrote:
> >>But my broader point is: What use would this feature be, since you can
> >>capture the output of virsh easily using shell redirection? The Xen
> >>'xm' command doesn't have this feature and I don't kno
Nobuhiro Itou wrote:
But my broader point is: What use would this feature be, since you can
capture the output of virsh easily using shell redirection? The Xen
'xm' command doesn't have this feature and I don't know if anyone has
asked for it.
If I use it, the redirection is no problem.
Howe
Hi,
Thank you for your review.
How about this correction?
> Actually I had a closer look at this patch, and there are some problems
> (thanks to Jim Meyering who pointed these out). For example:
>
> Using sprintf into a fixed size message buffer with no other checks may
> cause a buffer overf
Hi,
> > I made the patch which output debug messages and error messages
> > of virsh to the log file.
> > I think that it is necessary to leave logs to the file for the
> > investigation at the failure.
> > Debug messages can take appointed optional information,
> > and error messages will make it
Actually I had a closer look at this patch, and there are some problems
(thanks to Jim Meyering who pointed these out). For example:
Using sprintf into a fixed size message buffer with no other checks may
cause a buffer overflow:
+sprintf(msg_buf, "[%d.%02d.%02d %02d:%02d:%02d ",
You sh
Nobuhiro Itou wrote:
Hi,
I made the patch which output debug messages and error messages
of virsh to the log file.
I think that it is necessary to leave logs to the file for the
investigation at the failure.
Debug messages can take appointed optional information,
and error messages will make it
Hi,
I made the patch which output debug messages and error messages
of virsh to the log file.
I think that it is necessary to leave logs to the file for the
investigation at the failure.
Debug messages can take appointed optional information,
and error messages will make it easy to specify a cause
19 matches
Mail list logo
