Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, Jun 03, 2016 at 03:10:32PM +0100, George Dunlap wrote:
> On 03/06/16 14:30, Wei Liu wrote:
> > On Fri, Jun 03, 2016 at 11:57:14AM +0100, George Dunlap wrote:
> >> On 01/06/16 15:00, Wei Liu wrote:
> >>> Hi all
> >>>
> >>> During the discussion of XSA-180 Ian came up with the idea that we
> >>> repurpose xenconsoled to handle logging. I've done some research (and
> >>> some coding as well!).
> >>>
> >>> In my reply to George the other day:
> >>>
> >>>> I just read the code of virtlogd and xenconsoled.
> >>>>
> >>>> I think xenconsoled is missing at least things.
> >>>>
> >>>> From a higher level:
> >>>>
> >>>> 1. Abstraction of rotating file.
> >>>> 2. Abstraction of client.
> >>>> 3. IPC interface to libxl -- presumably we need to create a socket.
> >>>>
> >>>
> >>> I've done #1 and port existing code to use that -- would be useful in
> >>> general.
> >>>
> >>> #2 is not too hard because xenconsoled already has concept of a domain.
> >>> I suspect some refactoring will be fine.
> >>>
> >>> #3 requires a bit more thinking. Virtlogd has an RPC interface -- I'm
> >>> pretty sure we *don't* want that for xenconsoled. So I spent some time
> >>> this morning and write up a draft for a xenstore based protocol. See
> >>> below.
> >>>
> >>> Also there is an implication here: we put xenconsoled in a really
> >>> critical path. If for some reason it doesn't work all guests are
> >>> blocked. Do we really want to do this?
> >>>
> >>> Wei.
> >>>
> >>>
> >>> XXX DRAFT DRAFT DRAFT XXX
> >>>
> >>> Per domain logging via xenconsoled
> >>> ==================================
> >>>
> >>> As of Xen release XXX, xenconsoled is repurposed to handle logging for
> >>> QEMU. Libxenlight will arrange xenconsoled to create and handle the
> >>> log file. It's possible to expose API(s) so that the user of
> >>> libxenlight can leverage such ability, but it is not currently done.
> >>>
> >>> Xenstore path and nodes
> >>> -----------------------
> >>>
> >>> Libxenlight communicates with xenconsoled via a simple xenstore based
> >>> protocol.  All information for a specific domain is stored under
> >>> /libxl/$DOMID/logging. Each log file has its own unique id ($LOGFILEID).
> >>>
> >>> Several xenstore nodes are needed (placed under logging/$LOGFILEID).
> >>>
> >>>   pipe: the absolute path of the logging pipe
> >>>   file: the absolute path of the file to write to
> >>>   limit: the maximum length of the file before it gets rotated
> >>>   copies: the number of copies to keep
> >>>   state: xenconsoled writes "ready" to this node to indicate readiness
> >>>
> >>> Xenconsoled will sanitise both pipe and file fields. Pipe has to be
> >>> placed under XEN_RUN_DIR. File has to be placed under /var/log/xen
> >>> (XXX doesn't seem to be configurable at the moment, should introduce
> >>> XEN_LOG_DIR?).
> >>>
> >>> Libxenlight and xenconsoled interaction
> >>> ---------------------------------------
> >>>
> >>> Initiate logging
> >>> ----------------
> >>>
> >>> 1. Libxenlight:
> >>>   1. Generates a unique log file id $LOGFILEID
> >>>   2. Creates a pipe $PIPE
> >>>   3. Writes parameter to xenstore
> >>>   4. Wait for readiness indication
> >>> 2. Xenconsoled
> >>>   1. Watch global logging and per domain logging xenstore paths
> >>>   2. Gets notified, read parameters from xenstore
> >>>   3. Sanitise parameters
> >>>   4. Create log files
> >>>   5. Connect to the pipe provided
> >>>   6. Write "ready" to xenstore state node
> >>> 3. Libxenlight:
> >>>   1. Detects ready state from xenconsoled
> >>>   2. Open the pipe and return relevant handles to user
> >>>
> >>> In case of xenconsoled failure, libxenlight will time out and bail.
> >>
> >> ...and in the case of domain logging (i.e., qemu), it will either pipe
> >> it to /dev/null instead, or fail creation of the domain (whichever is
> >> the most sensible option given the requested configuration)?
> >>
> > 
> > Obtaining a logfile fd is a step prior to QEMU creation.  The creation
> > will fail because a critical component in the system is not available.
> > Another strategy is to warn but continue.
> 
> Right, this is what I meant.  If the user has explicitly asked for qemu
> to be logged somewhere, and that fails, then we should probably fail
> with an error.  But if the user hasn't asked for anything specific, and
> we're just doing the default "log to a file", then continuing the domain
> creation with a warning might be a better option.
> 

That's an option, but that requires changing user visible interface
which I explicitly avoided in this document.

Wei.

>  -George
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel