[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging
Here is what we have gathered so far: 1. Virtlogd is not the right answer to XSA-180 because it is inherently designed to work within libvirt. 2. Syslog is not suitable because it doesn't provide a fd for QEMU to write to. 3. Logrotate is not suitable because it only rotates periodically. 4. Syslog + logrotate combo is not suitable because (see above). We can, however, just make recommendation that system administrators can easily set up and call it a day. There are suggestions that we can recommend conserver or sympathy, but I haven't seen a concrete viable proposal yet. What I hope is that we can have a document in tree in the end. Another way is to invent our own "virtlogd" -- it could be a new daemon, it could be xenconsoled. The major concern is that we're adding a critical component to the system and it may not scale well. We can make a compromise by using non-blocking fd to make the new component less critical and doesn't hinder scalability. Another way is to alter libxl API and ask the application to pass in a fd for logging. The major concern is that this is not suitable in the context of a security issue. My ultimate goal is to remove the custom patch we have in QEMU tree so that we don't create a problem for distro maintainers. So I'm fine with any solution really. Wei. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |