The Xen Store
The Xen Store Daemon provides a simple tree-like database to which we can read and write values. The Xen Store code is mainly under tools\xenstore.
It replaces the XCS, which was a daemon handling control messages.
The physical xenstore resides in one file: /var/lib/xenstored/tdb.
Both user space ("tools" in Xen terminology) and kernel code can write to the XenStore.The kernel code writes to the XenStore by using XenBus.
The python scripts (under tools/python) uses lowlevel/xs.c to read/write to the XenStore.
The Xen Store Daemon is started in xenstored_core.c. It creates a device file ("/dev/xen/evtchn") in case such a device file does not exists and it opens it. (see : domain_init() ,file tools/xenstore/xenstored_domain.c).
It opens 2 TCP sockets (UNIX sockets). One of these sockets is a Read-Only socket, and it resides under /var/run/xenstored/socket_ro. The second is /var/run/xenstored/socket.
Connections on these sockets are represented by the connection struct.
A connection can be in one of three states:
BLOCKED (blocked by a transaction)
BUSY (doing some action)
OK (completed it's transaction)
struct connection is declared in xenstore/xenstored_core.h; When a socket is ReadOnly,the "can_write" member of it is false.
Then we start an endless loop in which we can get input/output from three sources: the two sockets and the event channel, mentioned above.
Events, which are received in the event channel,are handled by handle_event() method (file xenstored_domain.c).
There are six executables under tools/xenstore, five of which are in fact made from the same module, which is xenstore_client.c, each time built with a different DEFINE passed. (See the Makefile). The sixth tool is built from xsls.c
These executables are : xenstore-exists, xenstore-list, xenstore-read, xenstore-rm, xenstore-write and xsls.
You can use these executable for accessing xenstore. For example: to view the list of fields of domain 0 which has a path "local/domain/0", you run:
xenstore-list /local/domain/0
and a typical result can be the following list:
cpu
memory
name
console
vm
domid
backend
The xsls command is very useful and recursively shows the contents of a specified XenStore path. Essentially it does a xenstore-list and then a xenstore-read for each returned field, displaying the fields and their values and then repeating this recursively on each sub-path. For example: to view information about all VIFs backends hosted in domain 0 you may use the following command.
xenstore-ls /local/domain/0/backend/vif
and a typical result may be:
14 = "" 0 = "" bridge = "xenbr0" domain = "vm1" handle = "0" script = "/etc/xen/scripts/vif-bridge" state = "4" frontend = "/local/domain/14/device/vif/0" mac = "aa:00:00:22:fe:9f" frontend-id = "14" hotplug-status = "connected"15 = "" 0 = "" mac = "aa:00:00:6e:d8:46" state = "4" handle = "0" script = "/etc/xen/scripts/vif-bridge" frontend-id = "15" domain = "vm2" frontend = "/local/domain/15/device/vif/0" hotplug-status = "connected"
(The xenstored must be running for these six executables to run; If xenstored is not running, then running theses executables will usually hang. The Xend daemon can be stopped).
An instance of struct node is the elementary unit of the XenStore. (struct node is defined in xenstored_core.h). The actual writing to the XenStore is done by write_node() method of xenstored_core.c.
xen_start_info structure has a member named :store_evtchn. (declared in public/xen.h as u16). This is the event channel for store communication.