Re: [Xen-devel] Control tools work

[Anthony Liguori <aliguori@xxxxxxxxxx>]

Charles Coffing wrote:

> 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'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).
Regards,

Anthony Liguori

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

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