Control Tools
We are in the process of a full redesign of the Xen control tool and control interface structure. The most significant change planned is a replacement of the control interface and control message protocol with a hierarchical state store (XenStore) that will be used both for control communications and as a single point of management state in a Xen system.
This page provides an overview of the key components in the new design, and will (hopefully) reflect the evolution over the immediate future as XenStore begins to be incorporated into the unstable tree.
A fork of xen-unstable contains the new control code, and is available via CVS from HP, managed by Mike Wray. Instructions for anonymous read-only access are here: XenControlToolsCvs.
XenStore
XenStore is a hierarchical, persistent data store supporting transactional updates, and path-based change notification. It will run a a privileged domain within a Xen host and store all state used by the control tools. With the new tools, XenStore will be the single interface through which control information is passed between domains.
Unlike the current control message protocols, which require per-device message types, XenStore will act as a common substrate upon which control information pertaining to a domain can be exchanged. Having a clear persistent record of domain state will be especially useful in managing migration of Virtual machines, where the control tools will need to understand all of the resources that a VM is using.
Development of the store is currently being undertaken by Rusty Russel. The XenStore source is available via rsync, through a slightly confusing handle:
rsync -av ozlabs.org::rusty/xenstore .
A current interest in developing the new tools above the store is how the hierarchical namespace should be organized. We are in the process of preparing detailed scenarios that illustrate how guests and control tools will interact with each other through the store. These will be added to this page over the next week.
XenBus
XenBus is a per-guest driver that will provide an API for interactions with XenStore, and general inter-domain communication primitives. In the current drivers, considerable repeated code is spent on control interface setup and messaging, XenBus will unify a lot of this code.
XenBus will:
Provide an API for reading, writing, and registering notifications in XenStore.
- Provide functions for creating device channels (shared memory + event channel) between domains.
Design Documents
Several design documents were written during the redesign discussions over the past few months. Until I am able to attach these directly to this wiki page, these documents may be found using the following links:
Xen Control Tools Design Plan - Andrew Warfield, Keir Fraser, and Christian Limpach
Control Registry - Mike Wray
Control Examples - Mike Wray
