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.
> >
> >If I use it, the redirection is no problem.
> >However, when our customers are made to use virsh, it is necessary to
> >explain the redirection.
> >Mostly, a lot of customers do not seem to use the redirection usually.
> >And, executing the command applying the redirection to customers again
> >when the error occurs is troublesome of customers.
> >
> >Therefore, the purpose is to make it immediately correspond to
> >the customer's trouble report.
>
> Technically I think you've fixed all the problems I raised.
>
> I really think we should be looking at either a logging library, or
> (better) syslog. These problems -- like logfile maxsize, logfile
> location, log rotation -- have all been solved before, and I don't
> believe we should reinvent this wheel.
>
> I'm keen to hear what others think though.
I'm not convinced that virsh should have / needs persistent logging like
this. The commands run via it really map straight onto individual APIs,
and as such the error from any one command has no where near enough context
to provide useful information. The virt-install/virt-manager logs are useful
because they typically do have a good amount of context logged enabling easy
error diagnosis fro the logs. I just don't see logs from virsh being anymore
useful, than the stuff already printed on STDOUT/STDERR which a user will
already cut+paste into bug repots quite happily.
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?
Thanks,
Nobuhiro Itou.