[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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.


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



Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.