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@lists.xen.org http://lists.xen.org/xen-devel
