XSA-180 follow-up: repurpose xenconsoled for logging

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

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.

Clean up
--------

When doing per domain logging, libxenlight will remove all domain
specific xenstore paths when a guest is gone. Xenconsoled use that to
do clean up.

Libxenlight is responsible for deleting the pipe.

Global logging
--------------

Since we don't plan to provide new APIs now, we don't support global
logging because that would require us to provide a cleanup API that
libxenlight users can call.

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