With QEMU there are a couple of areas where QEMU ends up logging data to a file on the host. - stdout/err - connected to /var/log/libvirt/qemu/$GUEST.log - serial/parallel/console when used with type=file The stdout/err is typically very small, typically only getting data when an error occurs in QEMU resulting in it existing. In the past there was the chance of it getting lots of data - eg spice used to write tonnes of data on stderr during normal operation, so a guest OS could cause large data to be saved to the host log file. This is harder todo now, but still theoretically possible. The serial/parallel/console log files can be arbitrarily sized and under complete control of the guest OS - it can write whatever it wants with no limits. In both these cases we would prefer to be able to limit the amount of data a guest can write to the host file, so we have a finite cap on disk usage. You might suggest using logrotate, but that only runs periodically so between invocations of logrotate the log files can still grow to arbitrary size. This is inherant problem in doing the log rotation out of band / asynchronously OpenStack has a further problem it would like to solve. It wants to record all guest serial port data to a log file, as it has an API for a client user to read historically captured data from the serial port. This is done using type=file chardev At the same time it wants to expose an interactive console for client users to interact with the guest. This is done using type=unix or type=pty chardevs. The obvious problem is that a single serial/parallel/console device can only be connected to one chardev backend at a time. A very long time ago (5-6 years?) I submitted patches to allow multiple chardev backends in QEMU but they were rejected. Downstream projects like OpenStack have considered setting up console log handling service themselves, but my view is that this is a problem that all users of libvirt face, so libvirt should provide a standard solution to it. This avoids each downstream app reinventing the wheel. So I'm intending to create a standalone virtlogd daemon to address this problem. Similarly to virtlockd, it will be able to re-exec itelf so that upgrades can be done with no interruption to logging, and libvirtd will talk to it over a simple RPC protocol. - For stdout/stderr - libvirtd will ask virtlogd will provide a pipe FD that can be connected to the guest stdout/err, in the sme way libvirtd provides a file FD today. - virtlogd will read from this pipe and write the data to /var/log/libvirt/qemu/$GUEST.log - virtlogd will either truncate or rotate the $GUEST.log file when it reaches a declared certain size limit. - For serial/parallel/console - libvirtd will ask virtlogd to setup a pair of UNIX domain sockets listening on /var/run/virtlogd/qemu/$GUEST.guest /var/run/virtlogd/qemu/$GUEST.client - libvirtd will ask virtlogd to (optionally) write the data to a file /var/log/virtlogd/qemu/$GUEST.log (Or /var/log/libvirt/qemu/$GUEST-$DEVICE.log perhaps, where $DEVICE is the <alias> string from the console, serial or parallel device ?) - QEMU will be told to connect to this $GUEST.guest socket with the type=unix chardev backend - The virDomainOpenConsole API will connect to the $GUEST.client socket - virtlogd will read data from $GUEST.guest socket and write it to $GUEST.client and optionally $GUEST.log too - virtlogd will read data from $GUEST.client socket and write it to $GUEST.guest socket - virtlogd will either truncate or rotate the $GUEST.log file when it reaches a declared certain size limit. So at the end of this we will have strictly size limited log files which can rotated at the size threshold, and the ability to have interactive console sessions and file logging at the same time. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list