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

Re: [Xen-devel] Control tools work

To: <christian.limpach@xxxxxxxxx>
Subject: Re: [Xen-devel] Control tools work
From: "Charles Coffing" <ccoffing@xxxxxxxxxx>
Date: Tue, 31 May 2005 15:29:45 -0600
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 31 May 2005 21:29:16 +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
Christian,

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 don't necessarily want to revive the old Python debate, but this does 
complicate things.

Thanks,
Charles


>>>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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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