Hi Eric,
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).
Yes, the libvirt comes grom 0.10.2. I'm running the latest windows
binaries provided by spice-space.org:
C:\Program Files\VirtViewer\bin>virsh -V
Virsh command line tool of libvirt 0.10.2
See web site at http://libvirt.org/
Compiled with support for:
Hypervisors: PHYP ESX Test
Networking: Remote
Storage:
Miscellaneous: Debug
If someone provides newer windows binaries -- which aren't missing dlls,
like the ones at http://teuf.fedorapeople.org/virt-viewer-msi/ -- I will
test then.
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.
Please someone give me newer binaries I can test! ;-)
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.
That's precisely mingw advantage over cigwin: mingw binaries are native
windows binaries, using native windows semantics, not unix emulation.
They provide a better experience for windows users. Welcome to the
wonderful world of cross-platform developent! ;-)
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).
I understand that, but I'm trying to be useful as a (windows) tester. If
I could I'd try to help as a developer. cross-compiling is not for the
faint of heart, and learning the first steps require a significant
investment in time. :-(
Is there a how-to I can follow to generate binaries from the latest
sources? I do have Linux expertize, I use fedora on my personal
computer, but as C developer I can only run "configure; make; sudo make
install".
[]s, Fernando Lozano
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
