[libvirt] [RFC, PATCH] Re: xen:/// vs. xen://FQDN/ vs xen+unix:/// discrepancy

Philipp Hahn hahn at univention.de
Wed Mar 16 14:17:46 UTC 2011


Hello,

Am Freitag 23 Juli 2010 18:02:27 schrieb Philipp Hahn:
> Am Donnerstag 22 Juli 2010 14:51:22 schrieb Daniel P. Berrange:
> > > root at xen4# virsh -c xen://xen4.domain.name/ list
> > > root at xen4# virsh -c xen:/// list
> > > root at xen4# virsh -c xen+unix:/// list
...
> To me it looks like some connection between libvirtd / virsh and xen gets
> broken, so no data on running domains can be retrieved any more, until I
> restart libvirtd. After that everything is back to normal until the next
> hickup.

Today I encountered the bug again: "virsh list" was not showing any domain, 
while "virsh -c xen+unix:///" did show "Domain 0" and my other domain.

I attached gdb, "thread apply all bt" showed no thread still executing 
xenHypervisorInit(), but I found the following inconsistent state:
> in_init == 1
> hypervisor_version == -1
> sys_interface_version == -1
> dom_interface_version == -1

Notice in_init=1: Currently there are two error path, where that can happen:
1. ret = open(XEN_HYPERVISOR_SOCKET, O_RDWR);
2. if (VIR_ALLOC(ipt) < 0) {
In both cases in_init remains 1, which disables further useful logging:

> #define virXenError(code, ...)                                             \
> if (in_init == 0)                                                  \ 
> virReportErrorHelper(NULL, VIR_FROM_XEN, code, __FILE__,       \
> __FUNCTION__, __LINE__, __VA_ARGS__)
 
This leads me to the following question:
1. Why is error reporting deactivated during init?
Since in_init==1 is valid only during the call xenHypervisorInit(), explicitly 
using that macro there for logging seems very wrong.

2. xenHypervisorInit() also allocates three regexp_t structures, which are 
only freed when one of them can not be compiled, but they remain in memory 
when determin the Xen hypervisor version fails.
On the other hand these 3 structures are used in 
xenHypervisorMakeCapabilitiesInternal(). This isn't checked directly, but 
only indirectly, because in the error case no one will ever call it with a 
valid virConnectPtr.
Should the structures be freed in all error cases?

The attached patch is a first try at improving that situation.

> > To verify that libvirtd is actually openening the same drivers as virsh
> > you can edit /etc/libvirt/libvirtd.conf and set
> >
> >   log_filters="1:libvirt 1:xen"
> >   log_outputs="1:file:/var/log/libvirt/libvirtd.log"
>
> I've now enabled that and see if I can gather more data.

This didn't work because of the bug described above.

Sincerely
Philipp Hahn
-- 
Philipp Hahn           Open Source Software Engineer      hahn at univention.de
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20024_libvirt-hypervisor_version.diff
Type: text/x-diff
Size: 2620 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110316/d0579747/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110316/d0579747/attachment-0001.sig>


More information about the libvir-list mailing list