WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] Running scripts on domU create/shutdown?

To: Steve Kemp <steve@xxxxxxxxxxxx>
Subject: Re: [Xen-users] Running scripts on domU create/shutdown?
From: Tim Post <tim.post@xxxxxxxxxxxxxxx>
Date: Tue, 06 Mar 2007 10:45:54 +0800
Cc: xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 05 Mar 2007 18:45:37 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070305214528.GA17051@xxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Organization: Net Kinetics
References: <20070305214528.GA17051@xxxxxxxxxxxx>
Reply-to: tim.post@xxxxxxxxxxxxxxx
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
On Mon, 2007-03-05 at 21:45 +0000, Steve Kemp wrote:

>   So two questions:
> 
>     1.  Is there a simple method to get the domain name
>        from the ID, short of parsing "xm list N"?

Someone else suggested xenstore, you can also get this from libxenstat..
however xenstore would be your best bet if done in scripts. 

> 
>     2.  Would this kind of startup/shutdown hook be useful
>        to others, and if so would a patch be applied?  (I'm
>        happy to submit my code.)
> 

Positively. For a couple of reasons :

1 - Ideally any "interconnect" built around Xen is 100% transparent. By
transparent I mean it uses absolutely *no* blocking calls and non
blocking sockets to get its work done. The interconnect should not add
to the time it takes to distribute work in cpu seconds. 

This becomes easier if dom-0 was trained to let a central system know of
every event, so that an interconnect doesn't have to wait around to see
if a call indeed worked. It could, but it doesn't *have* to.

Lack of a reply by dom-0 in xx minutes indicates a problem. So see, in
this case, you really can document and use a negative. 

A good example of this - If you reboot a dom-u or shut one down, you
would have to make your script go into a loop watching xm list or syslog
to see when indeed the dom-u finally exited. Signaling on events fixes
that. Again, in this case a lack of a notification is meaningful.

2 - we have been working on a monitoring system that can handle 100k +
individual dom-0 machines. The only way to effectively do this is to put
some kind of triage in place so the most active servers get polled first
and distribute the monitoring tasks amongst a few guests.

Dom-0 signaling that there is activity helps tune this triage so idle
systems get polled last. 

Any time dom-0 can be made more proactive in the centralization process,
the better, imho. I'd be likely to use the patch even if it was
rejected.

> Steve

Best,
--Tim


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