[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging
On Mon, Jun 06, 2016 at 03:47:37PM -0500, Doug Goldstein wrote: > On 6/6/16 5:12 AM, George Dunlap wrote: > > On 03/06/16 18:38, Andrew Cooper wrote: > >> On 01/06/16 15:00, Wei Liu wrote: > >>> Hi all > >>> > > <snip> > > > FWIW, the libvirt project has exactly the same problem, and they did the > > analog of what Wei is proposing -- they added a new daemon, virtlogd, to > > handle all the console and debug log rotation in a fashion resistant to > > DoSing. Without reading their discussion, it's reasonable to assume > > that using system logging was at least considered using system-level > > logging before deciding to write their own code. > > If I recall they use RPCs and the logs are generated as a best effort to > not block QEMU. > Does that mean it's more or less equivalent to O_NONBLOCK? Is that configurable? We might actually want to block in some cases. > > > > We already have a daemon to do logging of consoles; it just doesn't have > > any of the logrotate features that are needed to make it robust against > > DoS. There's no sense in having log rotation code in two places, so > > upgrading xenconsoled to do what virtlogd is doing makes more sense than > > say, either writing our own, or stealing virtlogd. > > What if we made xl / libxl really good at the limited scope of things it > should be good at and left the other bits to others. At this point it > seems like yet another feature that xl / libxl is gaining that matches > what libvirt does. Maybe an approach is something you appear to suggest > and just point people to virtlogd and ask the libvirt guys if they would > make it a separate package. Honestly it seems like xl could slim down > from a feature set perspective and focus on improving libxl / libvirt > interaction. That's something that the Xen community has been interested > in to better support OpenStack anyway. > To clarify: xenconsoled is not part of xl / libxl. I think it you're talking about xen toolstack in general. I think we can ask libvirt maintainers: 1. if it is possible to make virtlogd a separate package, 2. if they can maintain a stable interface. Then we can think about how to make sensible suggestions and provide a way for sysamdins to configure that. No matter what solution we end up with, the work to integrate that with xl / libxl is unavoidable. Wei. > Just my 2 cents. > > -- > Doug Goldstein > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |