Control tools work

["Charles Coffing" <ccoffing@novell.com>]

I've been looking at the next-generation of control tools, and see some areas that I think still need some work.  I'm working on some code that will be ready "soon", but I wanted to post and get feedback on my ideas now rather than later.  Here are the things I'm working on:

1.  Providing a higher-level consistent API for domain actions (create, save, migrate, restore, pause, etc).

2.  Making the tools/libraries agnostic w.r.t. the guest OS type.

3.  Pushing rate-limiting lower into the IO streams.

4.  Making xfrd's functionality available as a library.


I'll give you some of my motivation, for each of these items:

1.  Higher-level API:  This is listed as a task in Andrew/Keir/Christian's Xen Control Tools Design Plan.  This is also becoming important to support items #2 and #4.

2.  OS agnostic:  I can give some examples of where this is not the case (migrations assume Linux; rate limiting is only Linux, etc).  But beyond specific examples, making things OS agnostic forces some concepts to be clarified in the code.  High-level commands (such as "create") logically have a fixed sequence of steps, regardless of the OS type.  Those high-level logical steps should be separate from OS-specific implementation details.  Mixing the two creates maintenance and portability headaches.

3.  Rate limiting:  Rate limiting should be available to all IO streams, regardless of OS and regardless of the current action.  Currently it is only available for a Linux domain.  I'm pushing this down the stack, so that it is more transparent (but optional still).

4.  libxfrd:  Xend and xfrd are tied pretty tightly together via an SXP-based protocol.  Once xend is gone, either xfrd will need to be reworked or the xend replacement will need to adhere to this protocol.  Since we're moving towards multiple single-purpose tools (e.g., VM-tools), continuing to maintain this protocol would be awkward.  I would prefer to have xfrd's functionality available as a library, that any tool can link against.  I still see the receiving end of xfrd running as a daemon (a small daemon using the xfrd library, that is).  But commands that want to initiate xfrd-style sends can call the library directly.  Other advantages of this are that progress reports can be done via a simple C callback, and you can get finer-grained error reporting (rather than the current success/failure code).  Once you start looking at this within a larger management framework, these things become important.


I'm refactoring / rewriting / writing code in xutil, libxc, and xfrd (although it wouldn't be hard to slip libxen in there instead of libxc if that is the ultimate direction).  I hope to have something to show in a week or two.

Cheers,
Charles