Re: [Xen-devel] Control tools work

[Steven Hand <Steven.Hand@xxxxxxxxxxxx>]

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

The basic save/restore stuff is now simplified (in particular has no 
dependencies on a callback mechanism out of the library). To do e.g.
a non-live migrate you then effectively need to: 

   * work out what the config of the domain is
   - do a save
   - use the config to create an 'empty' domain
   - restore into this, and 
   * perform final configuration tweaks

The key thing is that the steps with '*' (at least) require config 
information which xen doesn't have. You can maintain this yourself
in your C++ app or, in the new tools world (in progress), get this
from 'xenstore'. 

There's no real short-cut around this, and it has very little to 
do with python. There is a real + desired separation of concerns
between config info that xen needs to know about (domain instance 
state) and config info that a 'user' might care about (VM state). 
This latter info is currently managed by xend (one of its primary 
functions) but could equally be managed by the vmtools daemon or
an arbitrary user app. However since in most scenarios we believe 
it's sane to keep all this consistent, having a single locus for 
such config info (viz. xenostore) makes a lot of sense. 

Hope this addresses your concerns, 

cheers,

S.


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