From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Charles Coffing" Subject: Control tools work Date: Tue, 31 May 2005 11:57:16 -0600 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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