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
|
Home