<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:large"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">ср, 9 февр. 2022 г. в 12:30, Daniel P. Berrangé <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Feb 07, 2022 at 02:04:14PM +0300, Nikolay Shirokovskiy wrote:<br>
> пн, 7 февр. 2022 г. в 13:29, Michal Prívozník <<a href="mailto:mprivozn@redhat.com" target="_blank">mprivozn@redhat.com</a>>:<br>
> <br>
> > On 2/7/22 09:22, Nikolay Shirokovskiy wrote:<br>
> > > Hi, all.<br>
> > ><br>
> > > Libvirt QEMU driver writes QEMU process log to<br>
> > > /var/log/libvirt/qemu/<VM_NAME>.log file. This file is owned by libvirt<br>
> > > that is no API client knows about it and no client will remove it. Thus<br>
> > > this file stays forever. I guess it does not cause harddisk space waste<br>
> > > in some deploys as the number of VMs thru node lifecycle is not very<br>
> > large.<br>
> > ><br>
> > > In Virtuozzo we have a service which checks VMs disks every 5 min using<br>
> > > guestfs. This generates about 100k files and about 400MiB disk usage per<br>
> > > VM per year. This is a lot. I guess we could refine the service to avoid<br>
> > > this issue yet I think the issue is general and need to be addressed.<br>
> > ><br>
> > > If this is agreed then in terms of architecture should we have a<br>
> > > distinct timer/service to cleanup log files or we'd better clean up in<br>
> > > scope of qemu driver itself?<br>
> ><br>
> > I believe that this was one the issues that virtlogd tried to solve. By<br>
> > doing log rotation and keeping the last three files (by default). This<br>
> > can be fine tuned in virtlogd.conf.<br>
> ><br>
> <br>
> Hi, Michal.<br>
> <br>
> Yes virtlogd/logrotate can limit the size of logs for a single VM. But if<br>
> we keep logs forever for every VM that existed at some point in time then<br>
> the total size of logs can increase without any limit.<br>
> <br>
> I should mention that when we check VMs disks using guestfs it creates a<br>
> new transient VM every time. That is why we have so many logs left. But<br>
> most of these logs are not of interest - a VM was deleted a long time ago.<br>
> <br>
> So the suggestion is to keep logs for deleted VMs only for some period of<br>
> time, say a month.<br>
<br>
We have a logrotate config, that was pre-dating the existance of<br>
virtlogd, so its rules currently should be a no-op because<br>
virtlogd will have already rotated stuff before the logrotrate<br>
rules trigger. <br>
<br>
I wonder, however, if there is a way to set the logrotate rules<br>
to delete files, without interfering/clashing with virtlogd<br>
rollover.<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:large"><span style="font-size:16px">I investigated this approach a bit. This piece of configuration looks</span></div>most promising:<br><br>    weekly<br>    maxsize 2097153<br>    # copytruncate is off<br>    nocreate<br>    maxage 30<br>    sharedscripts<br>    postrotate<br>        kill -HUP virtlogd<br>    endscript<br><br>We also need to support reopening log files on SIGHUP in virtlogd of course.<br><br>'maxage' allows you to remove outdated rotated files. 'nocreate' is also required<br>as otherwise logrotate will create foo.log again with a fresh timestamp and<br>eventually foo.log will never be deleted. We need 'maxsize' instead of 'size'<br>also. The thing is 'maxage' is only applied on rotation which will never happened<br>with 'size' if log is abandoned.<br><br>Unfortunately 'maxsize' allows weekly rotations which will clash with virtlogd<br>rotations. I also think of introducing 'forceage' option instead of weekly/maxsize<br>pair to ask logrotate to apply 'maxage' even without rotation. Still I think<br>in this way we can clash with virtlogd on managing log files.<br><br>I guess we can either make delete/rename in virtlogd/logrotate in a very specific<br>order to handle races or introduce file locks to cooperate nicely. But to me<br>it does not look the right way. It will complicate logrotate because it will<br>need to cooperate with another log files manager.<br><br>I would add a new timer/service to cleanup log files. The service can be a very<br>simple shell script. It will need to cooperate with virtlogd too and we<br><div class="gmail_default" style="font-size:large"><span style="font-size:16px">can use file locks on log files for this purpose.</span></div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
A completely different, perhaps complementary, approach would be<br>
to offer a flag to virDomainDestroy VIR_DOMAIN_DESTROY_REMOVE_LOGS<br>
that libguestfs could pass, on the basis that having these logs<br>
persist is essentially a waste of time for transient VMs like<br>
these. It could omit this VIR_DOMAIN_DESTROY_REMOVE_LOGS flag if<br>
asked to run in a debugging mode perhaps.<br><br></blockquote><div><br></div>Yes this will make the log directory much cleaner. Even if we cleanup log<br>files on time basis we will still have a lot of not very meaningful logs<br><div>from guestfs in the log directory without this part.</div><div><br></div><div class="gmail_default" style="font-size:large">Nikolay</div></div></div>