Very good idea! 2015-01-21 15:12 GMT+03:00 Daniel P. Berrange <berrange@xxxxxxxxxx>: > 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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list -- Vasiliy Tolstov, e-mail: v.tolstov@xxxxxxxxx jabber: vase@xxxxxxxxx -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list