Re: [Xen-users] Xen 4.2.2 /etc/init.d/xendomains save and restore of domains does not work

[Andreas Greve <andreas.greve@xxxxxxxxxx>]

Ok   my actual first target is to fix what I have and thats at the 
moment the stable version 4.2.2 ( in that  i am a little bit self 
centered ;-) )  For that I have to live  with parsing sxp and json in 
shell and sed best as I can. (I don't like it but bash and sed are nice 
swiss army knifes)
I know nearly nothing concrete about xl internals and sorry very short 
at time. So I couldn't read source code or things like that to become 
familiarly with the internals now.
But some idea from the point of an adminstrating end-user I have.

I think putting the logic for the handling in to an compiled is not a 
good idea
( a horrible example was the introduction of the mountall monster of the 
ubuntu distro. When it is working
it is ok. But they had an bug in it to deal with network mounts and 
because it is an binary you have no chance to fix and they need years to 
fix it. The elder ubuntu versions works with the classic script files 
and there you have a chance to adapt the logic to your personal needs or 
to correct a bug using only vi and your brain )
My future wish is to start and stop domains in an fixed order because 
they depends on each other in some way. If the starting logic is hard 
coded in xl I have no chance to implement such things for myself.
I would prefer at tool perhaps xl I can give simple questions and get 
short shell purchasable answers
examples

xl query <domid>|<domname> <attribute> and the answer is a single value 
or fails if domid is not running
xl query gnomedag domid  ---> produce     1 or ''

xl queryall <attribute>  returns a list <domainame> <value>\n<domainame> 
value ....
perhaps getattribute is a better token for query

As a replacement for the create --dryrun ....
xl queryconf <configfile> <attribute> and the answer is a single value

An other nice to have  will be to query for an attribute list with the 
answer <value1> <value2> <value3>
respectively <domainame> <value1> <value2> ...\n<domainame> <value1> 
<value2> ...
The attribute should not be limited to configuration attributes. I wish 
to query dynamic values like domain state, cpu usage, disk usage and 
other things like that too.
Please excuse if the above is jolty worded.


Andreas

On 07/02/13 12:20, Ian Murray wrote:
> ----- Original Message -----
> > From: Ian Campbell<Ian.Campbell@xxxxxxxxxx>
> > To: Ian Murray<murrayie@xxxxxxxxxxx>
> > Cc: "greve-ml@xxxxxxxxxx"<greve-ml@xxxxxxxxxx>; xen-users<xen-users@xxxxxxxxxxxxx>; 
> > "andreas.greve@xxxxxxxxxx"<andreas.greve@xxxxxxxxxx>
> > Sent: Tuesday, 2 July 2013, 10:44
> > Subject: Re: [Xen-users] Xen 4.2.2 /etc/init.d/xendomains save and restore
>   of domains does not work
> > On Tue, 2013-07-02 at 10:40 +0100, Ian Murray wrote:
> > >   >  Even better would be to just do away with this madness of parsing JSON
> > >   >  or SXP in shell (keeping it only for xm compatibility) and add proper
> > xl
> > >   >  commands to save and restore all domains to/from a given directory.
> > >
> > >   Xendomains does quite a bit of high level stuff.... it's a
> > >   "convenience" script IMHO which not only deals with suspending
> > and
> > >   restoring but also starting the auto domains and dealing with things
> > >   that appear in both (i.e. the skipping of auto start stuff that has
> > >   just been restored). From a design point of view, is it the right
> > >   thing to do to move all that logic in xl? ... or keep it in a seperate
> > >   tool (but definitely re-written.)
> > Probably one to RFC on the devel list before committing lots of code
> > too, but I think its the sort of thing we could accept.
> I think a discussion about what xendomains is supposed to do (especially 
> dealing with the more obscure stuff like zombies and system requests) would be 
> a decent place to start I think that would shape the technical response.
>
> > Doing it in xl would be convenient, but a separate tool might also be
> > workable. The main point is "don't parse JSON in shell"!
> I think everyone would agree with that.
>
> > You could also consider implementing a more shell friendly output mode
> > though, which just produces FOO-separated lines of text with the name
> > and domid in them...
> I think state would be needed as well.
>
>
> > Ian.
> I

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users