Mailing List Archive

In tools/python/xen/xend/XendDomain.py you'll see that reap is called
by onVirq which in turn is a handler registered for xend.virq.
xend.virq is an event-channel used by xend for notifications. It is
set up in tools/python/xen/xend/server/channel.py. In -testing reap
appears to be called as soon as a domain crashes, meaning that
everything is working as it should. In -unstable a guest doesn't get
reaped until 'xm list' gets called awakening xend to the fact that it
has work to do.

What you might try to do is create a perl binding for the bits of the
xc library that you need or, if SWIG cooperates, the entire thing.
From there it appears you can set up an event channel notification for
"VIRQ_DOM_EXC = 4 # (DOM0) Exceptional event for some domain."

Oh and I'm not the expert, Mike Wray is. I just gleaned this from
glancing at the code just now. All I did for coredump was add a call
to reap in the crashed path. I guess if you're *really* lazy, you can
have xend send /var/tmp/myscript.pid a signal whenever it reaps a
domain. Although I doubt a patch for this would be accepted :-)

-Kip

On 4/29/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:
> > I've just finished a simple Perl script that brings out a
> > whole domain from a directory (with a small config file and
> > some <device>.gz files), create Logical Volumes with each
> > device, starts the domain, wait for the domain to shutdown,
> > push back into the *.gz the content of the LVs and remove
> > them. This is quite handy to launch any test machine stored
> > on the NFS server on one of our Xenified hosts.
>
> Nice.
>
> > My problem is the overhead of checking for the domain to shut
> > down as I intend to use the domUs not only for functional
> > testing but also to have a good guess of the performance we
> > can get on real hardware (with only one domU / real host).
>
> We should introduce a call-out for domain exits. Kip's looking core
> dumps, so I guess he's addressing this.
>
> > After xm create, this script regularly calls :
> > xm domid "domainname"
> > The problem is that this check eats a small chunk of CPU
> > time: it takes
> > 0.2 - 0.3s of real CPU time on each call. I've looked into
> > /proc/xen hoping to find the list of domains stored here,
> > allowing a simple file read or stat to give me the
> > information I need, but it seems there's nothing like this.
>
> There's a bunch of improvements to xend waiting to be posted which will
> likely help. There's certainly no good reason to be using CPU unless you
> have console output active or something.
> Ian
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>

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

> Hmm, it might actually make sense for applications to be able to
> register with xend for asynchronous notification of various classes of
> events. Although the hack I suggested probably shouldn't go in,
> something like it might be desirable.

Unless it went whilst I wasn't looking, Xend serves out event notifications on
at HTTP port - that might do what Lionel wants.

Cheers,
Mark

>
> -Kip
>
> > -Kip
> >
> > On 4/29/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:
> > > > I've just finished a simple Perl script that brings out a
> > > > whole domain from a directory (with a small config file and
> > > > some <device>.gz files), create Logical Volumes with each
> > > > device, starts the domain, wait for the domain to shutdown,
> > > > push back into the *.gz the content of the LVs and remove
> > > > them. This is quite handy to launch any test machine stored
> > > > on the NFS server on one of our Xenified hosts.
> > >
> > > Nice.
> > >
> > > > My problem is the overhead of checking for the domain to shut
> > > > down as I intend to use the domUs not only for functional
> > > > testing but also to have a good guess of the performance we
> > > > can get on real hardware (with only one domU / real host).
> > >
> > > We should introduce a call-out for domain exits. Kip's looking core
> > > dumps, so I guess he's addressing this.
> > >
> > > > After xm create, this script regularly calls :
> > > > xm domid "domainname"
> > > > The problem is that this check eats a small chunk of CPU
> > > > time: it takes
> > > > 0.2 - 0.3s of real CPU time on each call. I've looked into
> > > > /proc/xen hoping to find the list of domains stored here,
> > > > allowing a simple file read or stat to give me the
> > > > information I need, but it seems there's nothing like this.
> > >
> > > There's a bunch of improvements to xend waiting to be posted which will
> > > likely help. There's certainly no good reason to be using CPU unless
> > > you have console output active or something.
> > > Ian
> > >
> > > _______________________________________________
> > > Xen-users mailing list
> > > Xen-users@lists.xensource.com
> > > http://lists.xensource.com/xen-users
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users

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

> to reap in the crashed path. I guess if you're *really* lazy, you can
> have xend send /var/tmp/myscript.pid a signal whenever it reaps a
> domain. Although I doubt a patch for this would be accepted :-)

Hmm, it might actually make sense for applications to be able to
register with xend for asynchronous notification of various classes of
events. Although the hack I suggested probably shouldn't go in,
something like it might be desirable.

-Kip







>
> -Kip
>
> On 4/29/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:
> > > I've just finished a simple Perl script that brings out a
> > > whole domain from a directory (with a small config file and
> > > some <device>.gz files), create Logical Volumes with each
> > > device, starts the domain, wait for the domain to shutdown,
> > > push back into the *.gz the content of the LVs and remove
> > > them. This is quite handy to launch any test machine stored
> > > on the NFS server on one of our Xenified hosts.
> >
> > Nice.
> >
> > > My problem is the overhead of checking for the domain to shut
> > > down as I intend to use the domUs not only for functional
> > > testing but also to have a good guess of the performance we
> > > can get on real hardware (with only one domU / real host).
> >
> > We should introduce a call-out for domain exits. Kip's looking core
> > dumps, so I guess he's addressing this.
> >
> > > After xm create, this script regularly calls :
> > > xm domid "domainname"
> > > The problem is that this check eats a small chunk of CPU
> > > time: it takes
> > > 0.2 - 0.3s of real CPU time on each call. I've looked into
> > > /proc/xen hoping to find the list of domains stored here,
> > > allowing a simple file read or stat to give me the
> > > information I need, but it seems there's nothing like this.
> >
> > There's a bunch of improvements to xend waiting to be posted which will
> > likely help. There's certainly no good reason to be using CPU unless you
> > have console output active or something.
> > Ian
> >
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@lists.xensource.com
> > http://lists.xensource.com/xen-users
> >
>

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

Kip Macy wrote:

>In tools/python/xen/xend/XendDomain.py you'll see that reap is called
>by onVirq which in turn is a handler registered for xend.virq.
>xend.virq is an event-channel used by xend for notifications. It is
>set up in tools/python/xen/xend/server/channel.py. In -testing reap
>appears to be called as soon as a domain crashes, meaning that
>everything is working as it should. In -unstable a guest doesn't get
>reaped until 'xm list' gets called awakening xend to the fact that it
>has work to do.
>
>
There's a bug under bugzilla (#7) about this. It appears xcs is not
delivering VIRQs properly.

The DOM_EXC virq won't be delivered for every possible shutdown case
either. It's delivered for a crash or for a shutdown (a domain
initiated shutdown) but not for a domain destroy.

I've found the best way to detect shutdown reliably is with a polling
loop. There's code in xenctld to do just this (and I believe Mike Wray
is doing this too in the new Xend).

I've done performance testing with querying every 2 seconds and the
overhead is trivial.

As Mark mentioned, there is an event socket for Xend. Be warned though
that right now, those event are probably not very reliable.

If you're looking for a cheap solution that can be done with the shell,
I'd suggesting grabbing VM-Tools and using the vm-list command to query
the flags of a domain. It will have significantly less overhead than xm
list.

Regards,
Anthony Liguori

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