Inter-domain communication for XAPI: Difference between revisions

From Xen
Jump to navigationJump to search
(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…")
 
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

  1. storage driver domains
  2. network driver domains
  3. qemu stub domain(s)
  4. ... various other helper domains (e.g. possibly a domain running pygrub)

The XCP toolstack already has several pieces including:

  1. xapi: handling resource pools
  2. squeezed: applying ballooning policy
  3. xenopsd: (new) "babysitting" running VMs on a host
  4. perfmon: monitors alerts based on performance measurements

We currently use a set of ad-hoc protocols for inter-process communication including

  1. XMLRPC
  2. xenstore "rpc"
  3. JSONRPC

We desire to standardise on a particular messaging/RPC system which

  1. is available everywhere and very easy to use from many different source languages
  2. 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

  1. a message broker which can buffer messages and start receiving services on demand
  2. an IDL supporting both basic types (string, int etc) and structured types (arrays, structs)
  3. languages including: C, python, ocaml
  4. 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:

  1. xapi: running in a domU, handling XenAPI calls from clients
  2. xenopsd: running in dom0, performing start/shutdown/... on running VMs
  3. storage: running in a domU i.e. a storage driver domain