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/
Home Products Support Community News


Re: [Xen-devel] Control tools work

To: Charles Coffing <ccoffing@xxxxxxxxxx>
Subject: Re: [Xen-devel] Control tools work
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Thu, 02 Jun 2005 20:01:38 -0500
Cc: christian.limpach@xxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 03 Jun 2005 01:01:14 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <s29c82f6.031@xxxxxxxxxxxxxxxxxxxxxxxxx>
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>
References: <s29c82f6.031@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
Charles Coffing wrote:


I've done a pull and now see the functionality in XendCheckpoint.py; thanks for 
the heads-up.

But how do you see things outside of xm & xend accessing this functionality?  In 
particular, I'm thinking of a CIMOM provider written in C++.  Forking/exec-ing an "xm 
migrate" command is less than ideal, for several reasons (progress reporting, error 
reporting without having to grok text, overhead on a busy server, ...)  In my ideal world, 
this level of functionality would be in C or C++ libraries, so you can put whatever you want 
on top of it, be it Python commands or C++ CIMOM code or anything else.
I'm quite happy with the direction the lower level infrastructure is going in. Once the store gets straightened out, the control channel multiplexing daemon becomes less interesting (which is the biggest barrier to tools entry today).

Christian's latest modifications to the xc_save/restore code were fantastic and we were able to start using it quickly. I'd still like to see some of the libxc interfaces refactored a bit (for instance, I'd like xc_domain_create to do a bit less so better error conditions can be obtained) but I think we're going to try to start helping to improve the existing error paths first.

I've always thought of VM-Tools as a mechanism to determine what aspects of Xen needs more work to support additional management tools.

Your point about OS-agnostic interfaces is a good one--there's a bit of a combinatorial domain creation problem as we support more types of domains on more types of architecture (and even if we ever support things other than Linux for dom0).


Anthony Liguori

I don't necessarily want to revive the old Python debate, but this does 
complicate things.


christian.limpach@xxxxxxxxx 05/31/05 3:07 pm >>>
On 5/31/05, Charles Coffing <ccoffing@xxxxxxxxxx> wrote:
1. Providing a higher-level consistent API for domain actions (create, save, migrate, restore, pause, etc).

I'm no longer convinced there is a much higher API to have. Except for create and migrate, all the actions you list are already single functions in libxc, migrate is save | restore. It might be useful to group several functions together for create, but it's not quite clear how/where device configuration fits in there.
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.

Please note that xfrd does no longer exist in -unstable. Also we don't use libxutil anymore. Xend handles the first half of a relocation itself and then runs the xc_save or xc_restore helper programs to do the second part. During the first part of a relocation, the xend domain configuration is exchanged and the format of this part is specific to xend. The xc_save and xc_restore helpers are merely wrappers for the xc_linux_save and xc_linux_restore functions and use pipes to communicate with xend and write/read the virtual machine image to/from a file handle or socket. christian

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

Xen-devel mailing list

Xen-devel mailing list

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