[Xen-devel] Control tools work

["Charles Coffing" <ccoffing@xxxxxxxxxx>]

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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel