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
