Hi Christophe,
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.
I gave you links to RPMs containing the missing dlls (rpm2cpio foo.dll | cpio -id will unpack them on linux) in https://www.redhat.com/archives/virt-tools-list/2013-September/msg00037.html, did you try adding these dlls in the place the installer put the other ones to see if this helps?
The first missing DLL was libvirt-lxc-0.dll. After I put it on the virt-viewer install dir, I got the error:
C:\Program Files\VirtViewer\bin>virsh -c qemu+tcp://kvmhost/system error: failed to connect to the hypervisor error: authentication failed: unsupported authentication type 1
Nice, there wan't other missing DLLs. :-)
It looks like the windows port can't do SASL auth over TCP. So I changed libvirtd.conf to allow unauthenticated connections over TCP.
It worked!!!!!
Quickly changed libvirtd.conf to allow only TLS connections, not to let my host insecure. Then tried again:
C:\Program Files\VirtViewer\bin>virsh -c qemu+tls://kvmhost/system
It worked!!!
Thanks a lot for your help, and I'm eager to try the next release you are about to build.
PS: Would it be hard to add SASL support to the windows port? It's much easier to setup than TLS.
[]s, Fernando Lozano
Hi,
My first tests using virsh from http://teuf.fedorapeople.org/virt-viewer-msi/ were based on the 64-bit (x86_64) binaries. I'll try the 32-bit binaries and report on the results.
After having success with a few comands using virsh, I decided to try virt-viewer.
It reported missing libssp-0.dll, so I copied as per previous intructions by Christophe. Now when I try:
C:\Program Files\VirtViewer\bin>virt-viewer -c qemu+tls://kvmhost/system guest1
It locks up. No output, no error, no remote-viewer window. :-( As both virsh and remote-viewer were woking now, I kinda expected virt-viewer should work, or at least give an error we could debug.
Changing the connection URL to:
C:\Program Files\VirtViewer\bin>virt-viewer -c qemu+tcp://kvmhost/system guest1
Which would give an "unsupported authentication type 1" on virsh, but locks up virt-viewer the same way as using TLS. It looks like virt-viewer is locking up *before* connecting to libvirtd to find the remote display config for "guest1".
Adding --debug to virt-viewer with tls shows:
(virt-viewer.exe:23376): virt-viewer-DEBUG: Insert window 0 0000000000A240A0 (virt-viewer.exe:23376): virt-viewer-DEBUG: fullscreen display 0: 0 (virt-viewer.exe:23376): virt-viewer-DEBUG: connecting ... (virt-viewer.exe:23376): virt-viewer-DEBUG: Opening connection to libvirt with U RI qemu+tls://kvmhost/system (virt-viewer.exe:23376): virt-viewer-DEBUG: Add handle 3 1 0000000003684A90
If I try --debug but using a qemu+tcp URL, I get the same output (with different memory addresses, of course)
Attached is another virt-maanger try (using qemu+tls, which should work for libvirt) but with LIBVIRT_DEBUG=debug.
This log shows that libvirt has connected and was authenticated (the RPC_TLS_CONTEXT_SESSION_ALLOW entry means that, right?). How strange. So I also attached also a debug log for the qemu+tcp url.
Hope this helps making virt-viewer work on windows.
[]s, Fernando Lozano
[]s, Fernando Lozano
Hi,
My first tests using virsh from http://teuf.fedorapeople.org/virt-viewer-msi/ were based on the 64-bit (x86_64) binaries. I'll try the 32-bit binaries and report on the results.
The 32-bit binaries needed the same DLLs (of course the 32-bit ones) and gave the same results: virsh works with TLS and TCP (noauth), virt-viewer locks up.
Remote-viewer was woking before and continues working. I have not tried alternative authentications schemes for spice, just TLS and the fixed (shared) password.
[]s, Fernando Lozano
Hi Fernando,
Could you please not cross post this thread on the Fedora users's list. Only your messages get to the list, there is no way to follow the discussion. Also this seems completely off-topic on the users's list. Please read the mailing list guidelines.
Thanks,