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.