WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Control tools work

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Control tools work
From: "Charles Coffing" <ccoffing@xxxxxxxxxx>
Date: Tue, 31 May 2005 11:57:16 -0600
Delivery-date: Tue, 31 May 2005 17:57:27 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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

<Prev in Thread] Current Thread [Next in Thread>