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

[George Dunlap <george.dunlap@citrix.com>]

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.

 -George



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