Re: XSA-180 follow-up: repurpose xenconsoled for logging

[Wei Liu <wei.liu2@citrix.com>]

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.

Wei.

> This seems OK to me, but I don't feel like  I have enough experience
> with xenstore protocols to know where the traps are.
> 
>  -George

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