Jim Fehlig wrote:
Anthony Liguori wrote:
[snip]
Continuing in the debugger I find that all routines complete up to
process() in httpserver.py line 110 (note that my line numbers may be
skewed a little due to insertion of debug code). After executing the
statement "res = req.process()", I take the else clause of "if
isinstance(res, ThreadRequest):" - which calls req.finish() which in
turn closes the connection. So no response is sent to libvirt, which
is blocked waiting to read something from xend.
As mentioned before, if I ignore reading a response from xend on the
create op and go directly to wait_for_devices and unpause then the
guest is launched as expected. BTW, I do get responses from xend on
wait_for_devices and unpause ops.
The path is a normal domain_create(). The path within Xend is
server/XMLRPCServer.py but that's a very thin wrapper around a direct
call to XendDomain.py:domain_create(). domain_create() should always
return. If it's not, there's a bug in Xend I think.
Not in the case of libvirt - see above.
Can you give me a very concrete test case for this? The exact
parameters being passed to domain_create() (it should just be an
S-Expression config).
Sent in a previous post.
I will look into this more tomorrow - have other fires that need
attention now.
Tomorrow ended up being several days later :-). I looked at this again
today and must say that this is a frustrating bug - feeling like some
CS101 student.
So I was wrong in stating that xend does not respond to the create op
issued by libvirt. I get the expected response from xend but the
connection is not closed upon completing the request, thus I set in some
read loop in libvirt waiting for eof. I stepped through the request
processing code in xend for create op for both paravirtualized and hvm
guests and all seems fine, i.e. request is processed, finished, socket
closed, etc. in httpserver.py. Looking at a packet trace shows
connection is terminated for paravirt case (which breaks out of the read
loop in libvirt) but not so for hvm case.
Don't think I want to waste anymore time with this bug since the http /
sexp interface is going away - which brings me to a question. Why is
libvirt still using this interface and not xmlrpc? Perhaps my time
would be better spent moving libvirt to this interface. I would like to
submit the hvm patch for libvirt but can't reliably test it at this point.
Regards,
Jim