Difference between revisions of "Xenopsd"

From Xen
m
Line 13: Line 13:
 
# 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.
 
# 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.
 
# xenopsd should not require xapi to be running (although it will require a storage service to be available in order to attach new disks)
 
# xenopsd should not require xapi to be running (although it will require a storage service to be available in order to attach new disks)
# xenopsd should support simulation-based testing, through having a mock interface (a simulator backend as well as a real backend)
+
# xenopsd should support simulation-based testing, through having a "simulator" backend as well as a real "xen" backend.
# xenopsd should support a level-triggered (rather than edge-triggered) event system, to allow clients (ie 'xapi') to resynchronise as quickly as possible
+
# 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).
# xenopsd should 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)
+
# 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)
 
   
   

Revision as of 21:00, 30 December 2011

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

Xenopsd-internals.svg

Code status