[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Libvir] Re: support for hvm guests

Anthony Liguori wrote:

Jim Fehlig wrote:

Daniel Veillard wrote:

On Wed, May 03, 2006 at 09:43:36AM -0600, Jim Fehlig wrote:
Currently I can get info on hvm domains but unable to create them. The create request is sent to xend but then blocks reading from xend in xend_req(). No problem creating the domain using xm. I have looked at the config coming into xend and it is identical between xm and virsh/libvirt. Need to poke around xend and see why there is no response to the virsh/libvirt create request for hvm domains.

 Hum, basically to debug this kind of things I spend my time in
/var/log/xend.log especially since it prints what it received at creation
time, you can at least check the informations coming from libvirt and
from xm look alike.
 Unfortunately I won't be able to help you, first because I'm about to
take vacations for 3 weeks :-), second because I don't have one of those
new Intel CPUs, but I am sure others will give an hand if needed.

Well, I have found the problem but not a fix :-). When posting the create op to xend, the libvirt code currently waits for a response from xend (xend_req() is called after posting in xend_post()). For hvm guests, xend does not respond and libvirt blocks indefinitely on read. If I skip over the call to xend_req() for the create operation, wait_for_devices() and subsequently unpause() are called and the hvm guest is launched.

What do you mean by Xend does not respond?

OK, let me try this again after some experimentation today. First, I'm using CVS libvirt and it does not use xmlrpc but the "old" S-expression over http - so I take a different code path to domain_create(). I set a breakpoint (pdb.set_trace()) in domain_create() and attempted to launch the hvm guest with xm and virsh/libvirt. The stack trace from xm is

(Pdb) bt
-> self.run()
-> self.__target(*self.__args, **self.__kwargs)
-> self.finish_request(request, client_address)
-> self.RequestHandlerClass(request, client_address, self)
-> self.handle()
-> self.handle_one_request()
-> method()
-> response = self.server._marshaled_dispatch(
-> response = self._dispatch(method, params)
-> return func(*params)
-> info = XendDomain.instance().domain_create(config)
> /usr/lib/python2.4/site-packages/xen/xend/XendDomain.py(227)domain_create()
-> self.domains_lock.acquire()

and the stack trace using virsh/libvirt:

(Pdb) bt
-> self.run()
-> self.__target(*self.__args, **self.__kwargs)
-> self.processRequest(sock, addr)
-> rp.process()
-> res = req.process()
-> return self.render(resource)
-> val = resource.render(self)
-> return meth(req)
-> return self.perform(req)
-> return op_method(op, req)
-> dominfo = self.xd.domain_create(config)
> /usr/lib/python2.4/site-packages/xen/xend/XendDomain.py(227)domain_create()
-> self.domains_lock.acquire()

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.

Thanks for the help :-).

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]