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

Re: [Xen-devel] [libvirt test] 55257: regressions - FAIL



On Mon, 2015-05-11 at 10:36 -0600, Jim Fehlig wrote:
[...]
> > The qemu log is sadly empty so I've no clue why this timed out.
> >   
> 
> I guess qemu didn't run at all...
> 
> > Perhaps there is something in 
> > http://logs.test-lab.xenproject.org/osstest/logs/55257/test-amd64-amd64-libvirt/merlot1---var-log-libvirt-libvirtd.log.gz
> > I can't make heads nor tail though.
> >   
> 
> Nothing interesting.  Only the unhelpful
> 
> 2015-05-11 12:42:17.451+0000: 4280: error : libxlDomainStart:1032 :
> internal error: libxenlight failed to create new domain
> 'debian.guest.osstest'

This happened again in
http://logs.test-lab.xenproject.org/osstest/logs/55349/test-amd64-amd64-libvirt/info.html

Is there anything we could tweak in osstest to produce more helpful
logging?

> Off topic, but I'd really like to improve reporting of libxl errors in
> libvirt.  Currently, when calls to libxl_foo fail, libvirt simply
> reports something like "libxenlight failed foo".  Users must resort to
> /var/log/libvirt/libxl/libxl-driver.log and
> /var/log/xen/qemu-dm-<domname>.log for details.  Perhaps a topic for the
> dev summit.

Indeed.

One thing we would like to do is to have more specific error codes so
that ERROR_FAIL is not returned everywhere. The xapi guys would like
this too. In general we are happy to have error codes which are used for
exactly one specific type of failure and to take patches to switch
things from ERROR_FAIL to use something more meaningful.

Other ideas:

A logger which, as well as logging, would cache the last N messages of a
certain priority or higher, in such a way that the caller could query
them and output them. If the priority was >= ERROR I think that would on
most failures get you the most relevant things.

I wonder if it would even be possible to buffer up all of the calls to a
given libxl_* entry point, in such a way that the messages associated
with exactly that call could be retrieved. If we could find a way to
integrate that with, say, the GC_INIT infrastructure then we would get
it for free almost everywhere (not sure how recursive calls to libxl_*
rather than libxl__* would be handled there).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.