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

[Fernando Lozano]

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