[virt-tools-list] [Spice-devel] More on virt-viewer for windows

[Eric Blake]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20130917/4bec18f6/attachment.sig>