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