Re: Control tools work

[Christian Limpach <christian.limpach@gmail.com>]

On 5/31/05, Charles Coffing <ccoffing@novell.com> wrote:
> 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.

Well, the non-xend specific code needed to do a relocation is in
libxc[1] and I believe IBM's vm-tools also use this code.  This code
only saves/restores the low-level virtual machine image, it doesn't
even know about checkpointing/relocation, i.e. how the data gets on or
off the disk or to a different machine or how to configure the devices
needed by the virtual machine on the machine where the virtual machine
is restored.  All this configuration management and setup work needs
to be done by a tool like xend or a toolset like vm-tools.

xend currently handles storage and management of configuration
information and configuration of devices according to this information
and on top provides a client/server interface to control it all[2]. 
In a next step, we're going to move the storage and configuration
parts into what we call 'xenstore'.  With xenstore it will be even
easier to write simple command line tools or interface from C or C++
libraries, all the gory details of device setup will be hidden.  We
hope that with this seperation xend will be reduced to an even more
reasonable size and that there won't be a need for alternate toolsets,
or that these would at least use xenstore.

    christian

[1] I think I'll make the control pipe and error/progress reporting
filehandles function call arguments to make it easier to use
xc_linux_{save,restore} when you link libxc into your application. 
Although I really think you want to run these in a seperate process to
isolate them from your main application.  If there's real demand we
could bring back something like ioctxt to give you callbacks for
control/error/progress.
[2] and juggling around console data.