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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

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)?

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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel