On 09/17/2013 11:27 AM, Fernando Lozano wrote: > Hi, > > Still hoping someone takes my test results and fix the windows port. ;-) > > I configured my host to accept remote tcp libvirtd connections, once > with sasl security and the seccond time without any security. Both > setups were validated by a linux client, who could connect using virsh > and virt-manager without problem. Bu then the windows port fails with > the same error message it displayed when using TLS certificates: > > C:\Program Files\VirtViewer\bin>virsh -c qemu+tcp://kvmhost/system > error: Unable to set close-on-exec flag: Success > error: failed to connect to the hypervisor What version of libvirt again? This error is not possible on the latest libvirt.git. That error message is printed ONLY by virnetsocket.c, after a failed call to virSetCloseExec(); but looking at src/util/virutil.c, virSetCloseExec() _always_ returns 0 for mingw. Looking further, it looks like commit fcfa4bfb in Oct 2012 was what changed things to always return 0 (instead of always failing); that commit is in v1.0.0, but not in v0.10.2. If your build of virsh comes from libvirt 0.10.2, that would explain your failure scenario, and it's just a simple matter of building a newer libvirt. At any rate, I've just now backported that particular commit to the v0.10.2-maint branch, so it will be included in the v0.10.2.8 build (hopefully out soon, because it fixes several CVEs). > > It looks there is a basic network client code error on the windows port, > as using different authentication schemes do not make a difference. :-( Rather, it is yet another case of Microsoft's environment being so woefully non-compliant with POSIX, and a case of our code assuming POSIX semantics and failing when the assumption didn't work. In this case, it was pretty easy to work around the assumption. > > If someone wants, I can generate libvirt debug logs and Proccess Monitor > logs for those cases, but I guess they'd show more or less the same > things as the TLS test I already sent. Process Monitor is only useful if you make system calls; but libvirt is choking even before attempting the system calls because mingw is just such a hostile programming environment to programs that assume POSIX. Gnulib has helped a lot, and often times, it is just a matter of someone running under gdb to see where an assumption went wrong to make a quick patch to fix an issue. Where it gets tricky is that it is hard to find developers willing to do volunteer work on issues for a platform where you typically have to pay money before you can even use it. Also, the fact that you are using a pre-built version of a relatively old libvirt, instead of building your own from the latest sources, makes it hard to know what OTHER issues may have been fixed in the meantime (when given a choice, developers prefer to debug issues in the latest source, rather than trying to figure out which patches to backport to older branches). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel