From: Wei Liu <wei.liu2@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
Wei Liu <wei.liu2@citrix.com>,
David Vrabel <david.vrabel@citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: XSA-180 follow-up: repurpose xenconsoled for logging
Date: Tue, 21 Jun 2016 15:46:07 +0100 [thread overview]
Message-ID: <20160621144607.GU1790@citrix.com> (raw)
In-Reply-To: <20160601140014.GH5160@citrix.com>
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@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-06-21 14:46 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-01 14:00 XSA-180 follow-up: repurpose xenconsoled for logging Wei Liu
2016-06-03 10:57 ` George Dunlap
2016-06-03 13:30 ` Wei Liu
2016-06-03 14:10 ` George Dunlap
2016-06-03 14:21 ` Wei Liu
2016-06-03 16:57 ` Ian Jackson
2016-06-06 15:56 ` Wei Liu
2016-06-03 17:38 ` Andrew Cooper
2016-06-06 10:12 ` George Dunlap
2016-06-06 13:03 ` Andrew Cooper
2016-06-06 15:48 ` Wei Liu
2016-06-07 9:57 ` George Dunlap
2016-06-07 10:18 ` Wei Liu
2016-06-06 20:47 ` Doug Goldstein
2016-06-07 11:43 ` Wei Liu
2016-06-21 14:46 ` Wei Liu [this message]
2016-06-21 15:10 ` Juergen Gross
2016-06-21 15:23 ` Ian Jackson
2016-06-21 15:11 ` Ian Jackson
2016-06-21 15:53 ` George Dunlap
2016-06-21 16:04 ` Ian Jackson
2016-06-21 16:17 ` George Dunlap
2016-06-22 0:58 ` Jim Fehlig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160621144607.GU1790@citrix.com \
--to=wei.liu2@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=david.vrabel@citrix.com \
--cc=george.dunlap@eu.citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.