|Review||create new issue|
Xapi accesses storage through “plugins” which currently use a protocol called “SMAPIv1”. This protocol has a number of problems:
the protocol has many missing features, and this leads to people using the XenAPI from within a plugin, which is racy, difficult to get right, unscalable and makes component testing impossible.
the protocol expects plugin authors to have a deep knowledge of the
Xen storage datapath (
blkback etc) and the storage.
the protocol is undocumented.
We shall create a new revision of the protocol (“SMAPIv3”) to address these problems.
The following diagram shows the new control plane:
Requests from xapi are filtered through the existing
layer which is responsible for managing the mapping between VM VBDs and
Each plugin is represented by a named queue, with APIs for
Legacy SMAPIv1 plugins will be processed via the existing
module. Newer SMAPIv3 plugins will be handled by a new
The SMAPIv3 APIs will be defined in an IDL format in a separate repo.
xapi-storage-script will run as a service and will
inotifyto monitor a well-known path in dom0
xapior the CLI are received, it will generate the SMAPIv3 .json message and fork the relevant script.
The IDL will support
It will be possible to view the contents of the queue associated with any plugin, and see whether
It will be possible to
The following diagram shows what a plugin would look like:
Please read the current SMAPIv3 documentation.