Xenopsd

The xenops daemon

This is an attempt to improve the architecture of the XCP toolstack by splitting *domain management* into a separate service, known as the *xenops daemon*. This should have the following advantages:

1. it helps untangle the domain management code from the rest of xapi (which will focus on multi-host resource pool management)
2. it forces us to be explicit about the interface xapi needs, making the future libxl port more predictable and likely to succeed
3. it forces us to be explicit about the interface xenopsd needs, preventing (for example) the accidental insertion of a expensive RPC to a remote host through an internal xapi interface in a hot codepath. This is currently a very easy mistake to make and a better architecture would make it harder.

Design principles

1. xenopsd should ignore domains that it is not managing. This will allow (eg) domains started with 'xl' to safely co-exist
   1. xenopsd could therefore be told to manage one VM, like 'xenvm' (part of XCI)
   2. xenopsd could therefore be told to manage lots of VMs, like 'xapi' currently does
2. xenopsd should be capable of servicing all guest requests without making remote RPCs. This will allow (eg) VMs to reboot in an XCP resource pool even when the master is offline.
3. xenopsd should not require xapi to be running (although it will require a storage service to be available in order to attach new disks)
4. xenopsd should support simulation-based testing, through having a "simulator" backend as well as a real "xen" backend.
5. xenopsd should support a level-triggered (rather than edge-triggered) event system, to allow clients (ie 'xapi') to resynchronise as quickly as possible. It will be assumed that clients always want to 'diff' their current state against the 'tip' state and that they don't care about the exact sequence of historical changes (those are left for the audit log).
6. xenopsd should be able to handle operations on managed VMs concurrently (rather than serially) and avoid operations on one VM having dependencies on other VMs (eg VM_suspend should not depend on a dom0 VBD_plug)

Design overview