Re: [Xen-devel] Getting domain information in xen 3.0.4-1

["Wensheng Wang" <wenshengwang@xxxxxxxxx>]

You can do this:
import sys
sys.path.append('/usr/lib/python')
from xen.xend import XendDomain

inst=XendDomain.instance()
domain = inst.domain_lookup_nr("domu_name") #domain_lookup_by_name_nr in 3.0.3


do a dir(domain) to find out what you can use, e.g. getName(),
getMemoryMaximum() etc.

Wensheng Wang





On 4/2/07, Ewan Mellor <ewan@xxxxxxxxxxxxx> wrote:
> On Sat, Mar 31, 2007 at 03:29:04AM +0800, Thomas Goirand wrote:
>
> > Hi here!
> >
> > As you may know, we did dtc-xen, that you can find here (and in Debian SID):
> >
> > http://www.gplhost.com/software-dtc-xen.html
> >
> > This is a soap server in Python with HTTPS and auth so it's possible to
> > control Xen from the outside. In our case, we use it inside our control
> > panel to start / shutdown / destroy a VPS.
> >
> > The problem is that the internals of the xen lib in /usr/lib/python/xen
> > changed, and that our software cannot get the information it used to
> > fetch. The result is that our control panel cannot tell if a VPS is
> > running or not with that newer version of Xen, which is rather bad.
> >
> > Here is what we used to do:
> >
> > import xen.xm.main as xenxm
> > try:
> >       if xen_version == 3:
> >               info = xenxm.server.xend.domain(vpsname)
> >               return info
> >       else:
> >               info = xenxm.server.xend_domain(vpsname)
> >               return info
> >
> > The part after the else is for Xen2, of course, and when the method does
> > return, the object "info" is serialised to the network, then our nusoap
> > php client gets it in a php array/key object. Everything was fine...
> > until the release of Xen 3.0.4-1!
> >
> > The problem is that if I try this:
> > print xenxm.server.xend.domain( 'xen01' )
> >
> > python returns: object has no attribute 'xend'
> >
> > and if I try this:
> > print xenxm.server.xend_domain( 'xen01' )
> >
> > python returns: object has no attribute 'xend_domain'
> >
> > I did a diff between xen 3.0.3 and 3.0.4, and it really seems that the
> > method changed from xend.domain() back to xend_domain() like how it was
> > in xen 2.
> >
> > So I have 2 questions: 1st, how do I get it running under any conditions
> > again, like expected? Am-I missing something obvious here? How do I get
> > access to the xen_domain() that still seems to be in the python lib?
> >
> > 2nd question: how comes the lib in /usr/lib/python/xen is changing from
> > 3.0.3 to 3.0.4? Isn't that supposed to be accessed by anybody that wants
> > to do some programming with Xen?
>
> Firstly, no, that's not meant to be your programming interface!  You are
> delving into the internals of xm, the command line interface, and pulling an
> internal variable (server) and expecting that to be the thing that you want.
> This certainly isn't supported, and it wouldn't be surprising if it broke at
> any time.
>
> That said, I don't think that it's the cause of your problem.  It sounds to me
> like something more fundamental is at fault -- that xenxm.server object that
> you are dereferencing is a "magic" object, and so the xend.domain() call is
> actually being proxied through as a call to Xend.  It's possible that your
> server is at fault, rather than your client.
>
> Do you have anything interesting in your server-side logs
> (/var/log/xen/xend.log)?
>
> What do you get if you print str(xenxm.server)?
>
> Do you have other calls on xenxm.server that do work?  Easy ones would be
> xend.node.log() or xend.node.info().
>
> > Please help us, we got 3 new Xen servers in production recently, they
> > are up-and-running with Xen 3.0.4, and I really don't want to do some
> > ugly code that would fork another process with something like "xm list
> > xen01". Also, I'd like to correct our package before Etch is out, and
> > it's waiting for this fix before it's uploaded again...
> >
> > Last: as far as I could see, the Xen API is still not ready, right?
>
> It will be released as Xen-API 1.0 in Xen 3.0.5, which will happen in the next
> couple of weeks.
>
> Ewan.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel