Jim Fehlig wrote:
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.
The proper way to do the S-Expression RPC (or XML-RPC for that matter)
is to look at the Content-Length header in the response and read back
that much data (close()'ing the connection once you've gotten that
amount). We shouldn't wait for EOF to occur to stop reading.
There was a patch recently that changed the read() behavior to read in
larger amounts. It appears that when this was added, the behavior was
changed to expect EOF. Sorry, I should have looked at that patch more
carefully. If you revert xend_post to the older code, things should go
back to working.
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.
wrt XML-RPC, I think I'm to blame for that. I've not gotten around to
modifying the internals of libvirt to switch between
XML-RPC/S-Expression. I'd suggest just reverting the xend_post to the
older code so you can keep making progress.
Regards,
Anthony Liguori
Regards,
Jim