| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Control tools work
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
|
|
|
| |
|
Home