Red Hat Bugzilla – Bug 993554
RFE: Provide a better way to handle transient guests, especially log files
Last modified: 2016-04-19 14:14:12 EDT
Description of problem:
$ ls ~/.cache/libvirt/qemu/log/guestfs-
Display all 20086 possibilities? (y or n)
$ du -sh ~/.cache/libvirt/qemu/log
$ ls -1 ~/.cache/libvirt/qemu/log | head
I think there are a couple of issues here:
Firstly these log files have a limited lifespan. Surely 2 weeks
should be long enough to keep them around, after which they should
be deleted. Can we put this directory under the control of
Secondly libguestfs wants to make transient guests, but doesn't
particularly need to name them. Libvirt itself could choose a
random name (or some other mechanism) if there is no <name>
specified in the XML.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run libguestfs for a while.
(In reply to Richard W.M. Jones from comment #0)
> Firstly these log files have a limited lifespan. Surely 2 weeks
> should be long enough to keep them around, after which they should
> be deleted. Can we put this directory under the control of
Personally I like that the log files are long lived, it's helped me with debugging many times. Update libvirt, next time I start the VM qemu doesn't start up, I can look at what changed in the qemu command line output which is occasionally the culprit. And often I don't run certain VMs for months at a time.
But I agree the proliferation of guestfs logs is annoying. libvirt 1.3.3 added a <log file="/var/log/libvirt/qemu/guestname-serial0.log" append="off"/> element to character device XML... maybe repurpose that XML syntax to allow the user to specify a custom logfile location? Then point it to a location private to libguestfs that can be easily cleaned up.
> Secondly libguestfs wants to make transient guests, but doesn't
> particularly need to name them. Libvirt itself could choose a
> random name (or some other mechanism) if there is no <name>
> specified in the XML.
Sounds interesting. I wouldn't go the full omission of <name> route, but maybe something like <name prefix="guestfs-"/> or some kind of magic like that which will generate a non-colliding name.
This should probably be split into distinct bug reports though, and both those will probably get better response on the mailing list