From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wensheng Wang" Subject: Re: Getting domain information in xen 3.0.4-1 Date: Tue, 3 Apr 2007 03:10:56 -0500 Message-ID: <7b22037d0704030110o6a97665fhbecc068f41bf37cc@mail.gmail.com> References: <460D6500.5000403@goirand.fr> <20070402124217.GC28728@leeni.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20070402124217.GC28728@leeni.uk.xensource.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ewan Mellor Cc: xen-devel@lists.xensource.com, Thomas Goirand List-Id: xen-devel@lists.xenproject.org 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 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@lists.xensource.com > http://lists.xensource.com/xen-devel >