Inter-domain communication for XAPI: Difference between revisions
From Xen
Jump to navigationJump to search
Dave.scott (talk | contribs) (Created page with " In the future we will have # storage driver domains # network driver domains # qemu stub domain(s) # ... various other helper domains (e.g. possibly a domain running pygrub) Th…") |
Dave.scott (talk | contribs) No edit summary |
||
Line 1: | Line 1: | ||
In the future we will have |
In the future we will have |
||
# storage driver domains |
# storage driver domains |
||
Line 37: | Line 36: | ||
# xenopsd: running in dom0, performing start/shutdown/... on running VMs |
# xenopsd: running in dom0, performing start/shutdown/... on running VMs |
||
# storage: running in a domU i.e. a storage driver domain |
# storage: running in a domU i.e. a storage driver domain |
||
[[Category: XCP]] |
[[Category: XCP]] |
Revision as of 14:26, 11 January 2012
In the future we will have
- storage driver domains
- network driver domains
- qemu stub domain(s)
- ... various other helper domains (e.g. possibly a domain running pygrub)
The XCP toolstack already has several pieces including:
- xapi: handling resource pools
- squeezed: applying ballooning policy
- xenopsd: (new) "babysitting" running VMs on a host
- perfmon: monitors alerts based on performance measurements
We currently use a set of ad-hoc protocols for inter-process communication including
- XMLRPC
- xenstore "rpc"
- JSONRPC
We desire to standardise on a particular messaging/RPC system which
- is available everywhere and very easy to use from many different source languages
- promotes location-transparency (so we don't suffer when a service is moved from dom0 to a domU)
Proposal: DBUS
[DBUS|http://en.wikipedia.org/wiki/D-Bus] is a simple IPC system originally designed for graphical desktop environments. It supports
- a message broker which can buffer messages and start receiving services on demand
- an IDL supporting both basic types (string, int etc) and structured types (arrays, structs)
- languages including: C, python, ocaml
- location-transparency via a notion of a "well-known bus address" (like org.xen.foo) used to identify services
It is also the system used by XCI.
Concrete example
Consider a simplified XCP system containing the following services:
- xapi: running in a domU, handling XenAPI calls from clients
- xenopsd: running in dom0, performing start/shutdown/... on running VMs
- storage: running in a domU i.e. a storage driver domain