thr3ads.net - Xen devel - [Xen-devel] Getting domain information in xen 3.0.4-1 [Mar 2007]

If this information is useful, please help other people find it:
Share via:

Thomas Goirand

2007-Mar-30 19:29 UTC

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

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?

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?

Thomas Goirand

P.S: I know it''s not very polite to say so, but please add my email as
cc: as I''m not willing to read all the list and subscribe, even if I
often read the archive.

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

Ewan Mellor

2007-Apr-02 12:42 UTC

head link

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

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

Thomas Goirand

2007-Apr-02 13:37 UTC

head link

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

Ewan Mellor wrote:> On Sat, Mar 31, 2007 at 03:29:04AM +0800, Thomas Goirand wrote:
> 
>> 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 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''
>
> 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.
Yes, but as the XenAPI is not released yet... no choice! And spawning a
new process for every command is quite a bad idea. So even if it breaks,
SOMETIMES, then it''s still better.
> 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.
I have found the solution in fact! :)
It took me quite a long time to do it, but now I have found it. The
following code DO work:

#!/usr/bin/env python

import sys
sys.path.append( ''/usr/lib/python'' )
from xen.xend.XendClient import server
print server.xend.domain(''xen01'')
>> 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.
Great. I''d love to have something for the long therms using this API.
Where can I found the feature list? GPLHost would be one of the big
users of this API if it has the things we need!

Thomas Goirand

P.S: For those that are interested in it, I''ll try to send the patched
version of dtc-xen to Debian SID asap.

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

Wensheng Wang

2007-Apr-03 08:10 UTC

head link

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

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@xensource.com> 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
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Xen devel - Mar 2007 - Getting domain information in xen 3.0.4-1

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

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

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

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