Re: [Spice-devel] aSPICE and oVirt proxy
On Sat, Aug 24, 2013 at 01:38:50AM +0200, Marc-André Lureau wrote: > > > 3) Do you think it is feasible to isolate the code which deals with oVirt > > proxy handling in virt-viewer and use that in aSPICE? > > > > The isolation from libgovirt should be enough for implementing a different > client easily. Yes, there is not a lot of oVirt-related logic in virt-viewer, most of the work is done in libgovirt. Christophe pgpDZ34AEwNQl.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Where to put certificates for remote-viewer on windows
Hi, I downloaded the latest virt-viewer installer for windows from fedorahosted.org (0.5.7) and wish to use spice+tls to access VM consoles from a Fedora machine. I know my certificates are properly configured on the server side because I can connect from another Fedora machine using both remote-viewer and virsh. But on Windows it won't work. Virt-viewer was installed on the default location, so I guessed I had to put cacert.pem on: "C:\Program Files (x86)\VirtViewer\etc\pki\CA" and the client certificates on: "C:\Program Files (x86)\VirtViewer\etc\pki\libvirt" with the private key file on the "private" subdir. When I try to connect to the host using virsh.exe included on viet-viewer install I get the error: virsh # connect qemu://kvmserv/system error: Failed to connect to the hypervisor error: Cannot read CA certificate '/usr/i686-w64-mingw32/sys-root/mingw/etc/pki/ CA/cacert.pem': No such file or directory virsh # connect qemu+tls://kvmserv/system error: Failed to connect to the hypervisor error: Cannot read CA certificate '/usr/i686-w64-mingw32/sys-root/mingw/etc/pki/ CA/cacert.pem': No such file or directory kvmserv is resolvabe to the correct IP using ping on the windows machine, and it is the same hostname I use on the fedora machine to get a sucesfull connection. I also tried some "obvious" alternatives to "C:\Program Files (x86)\VirtViewer\etc\pki" for the certificates like "C:\mingw\etc\pki" and "C:\usr\x86_64-w64-mingw32\sys-root\mingw\etc\pki", none worked. Any ideas? Or to use remote-viewer / virsh from a Windows machine I need to allow insecure conections (no TLS) to the libvirtd and spice TCP ports? []s, Fernando Lozano ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Feature requests for virt-viewer windows port
Hi there, I apreciate very much the hard work from red hat/fedora developers on this, spice looks amazing (defintely much better than vnc) but when you have easy to use graphical admin tools for proprietary hypervisors (and the now open-sourced XenServer) managing a KVM/RHEV host is very hard. At least, the virt-viewer (remote-viewer) port should either embed a ssh client or use an external putty under the covers (like Xming does), and work with both ssh keys and password auth directly from the connection dialog (which today is non-existant, just "type a URL") And it should be able to get the spice TCP port from libvirtd, instead of having the user find and provide the correct port on the host for the desired guest. It should be smart enough to setup a ssh tunnel if needed or ask for tls certificates if it can't find them. []s, Fernando Lozano ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Feature requests for virt-viewer windows port
> Hi there, > > I apreciate very much the hard work from red hat/fedora developers on > this, spice looks amazing (defintely much better than vnc) but when you > have easy to use graphical admin tools for proprietary hypervisors (and > the now open-sourced XenServer) managing a KVM/RHEV host is very hard. > > At least, the virt-viewer (remote-viewer) port should either embed a ssh > client or use an external putty under the covers (like Xming does), and > work with both ssh keys and password auth directly from the connection > dialog (which today is non-existant, just "type a URL") Sounds like a good idea to have an ssh tunnel to the guest. It's totally doable without extending the current protocol by using a new char-dev channel. Actually we may want to record the number of the channel in the protocol, but that's it. Other then that it requires changes all over, but small, and has been discussed before, just needs someone to love it enough ;) > > And it should be able to get the spice TCP port from libvirtd, instead > of having the user find and provide the correct port on the host for the > desired guest. It should be smart enough to setup a ssh tunnel if needed > or ask for tls certificates if it can't find them. If your use case is libvirtd based, you can use virt-viewer directly, it does exactly the "connect to libvirt, get spice credentials, use them" part, i.e. virsh list IdName State 2 boxes-unknown-2running virt-viewer boxes-unknown-2 And uses the same code as remote-viewer (it's the same repository) and specifically uses spice-gtk. > > > []s, Fernando Lozano > > ___ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel > ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Feature requests for virt-viewer windows port
Hi Alon, At least, the virt-viewer (remote-viewer) port should either embed a ssh client or use an external putty under the covers (like Xming does), and work with both ssh keys and password auth directly from the connection dialog (which today is non-existant, just "type a URL") Sounds like a good idea to have an ssh tunnel to the guest. It's totally doable without extending the current protocol by using a new char-dev channel. Actually we may want to record the number of the channel in the protocol, but that's it. Other then that it requires changes all over, but small, and has been discussed before, just needs someone to love it enough ;) I was thinking about a tunnel to the host, not to the guest, for guest console access, without having to configure and start ssh tunnels manually, outside virt-viewer/remote-viewer. [that's right, if you want the guest console you connect to the host] Having virt-viewer / remote-viewer setup a tunnel for the guest would be very usefull to get a bash prompt (not a console GUI) and transfer files using SFTP. But for now I want just guest console access. And it should be able to get the spice TCP port from libvirtd, instead of having the user find and provide the correct port on the host for the desired guest. It should be smart enough to setup a ssh tunnel if needed or ask for tls certificates if it can't find them. If your use case is libvirtd based, you can use virt-viewer directly, The current windows port has only a barely usable remote-viewer. When I try to start virt-viewer, it complains missing libssp-0.dll. And I can't make spice+tls work. :-( Using TLS requires extra setup on the server side, I guess the easier path for windows users would be having remote-viewer or virt-viewer handle ssh tunnels. It looks like on Linux remote-viewer creates the ssh tunnel itself, but not on the windows port. []s, Fernando Lozano ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Feature requests for virt-viewer windows port
> Hi Alon, > >> At least, the virt-viewer (remote-viewer) port should either embed a ssh > >> client or use an external putty under the covers (like Xming does), and > >> work with both ssh keys and password auth directly from the connection > >> dialog (which today is non-existant, just "type a URL") > > Sounds like a good idea to have an ssh tunnel to the guest. It's totally > > doable without extending the current protocol by using a new char-dev > > channel. Actually we may want to record the number of the channel in the > > protocol, but that's it. Other then that it requires changes all over, but > > small, and has been discussed before, just needs someone to love it enough > > ;) > I was thinking about a tunnel to the host, not to the guest, for guest > console access, without having to configure and start ssh tunnels > manually, outside virt-viewer/remote-viewer. > > [that's right, if you want the guest console you connect to the host] > > Having virt-viewer / remote-viewer setup a tunnel for the guest would be > very usefull to get a bash prompt (not a console GUI) and transfer files > using SFTP. But for now I want just guest console access. So you want to access the guest or the host? If the guest, that's exactly what I meant, since spice doesn't have any other connection except to the host, i.e. the process running the spice-server (qemu/qemu-kvm). Didn't think about the SFTP use case, that's very interesting. > > >> And it should be able to get the spice TCP port from libvirtd, instead > >> of having the user find and provide the correct port on the host for the > >> desired guest. It should be smart enough to setup a ssh tunnel if needed > >> or ask for tls certificates if it can't find them. > > If your use case is libvirtd based, you can use virt-viewer directly, > The current windows port has only a barely usable remote-viewer. When I > try to start virt-viewer, it complains missing libssp-0.dll. > > And I can't make spice+tls work. :-( Using TLS requires extra setup on > the server side, I guess the easier path for windows users would be > having remote-viewer or virt-viewer handle ssh tunnels. > > It looks like on Linux remote-viewer creates the ssh tunnel itself, but > not on the windows port. Ah, I didn't realize on windows virt-viewer doesn't work. Well, that's something to fix I guess. I have no idea how much work that is :( > > > []s, Fernando Lozano > > ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Feature requests for virt-viewer windows port
Hi Alon, So you want to access the guest or the host? If the guest, that's exactly what I meant, since spice doesn't have any other connection except to the host, i.e. the process running the spice-server (qemu/qemu-kvm). I want access to the guest consoles, which means spice connections to the host. But I want those connections secured either by TLS or SSH. So far can get only plain insecure spice connections from a windows workstation to the kvm host. I'm happy running Linux on my desktop, but I am the only one here. Everyone else runs Windows, and I'm trying to find a setup that's acceptable to them. Ah, I didn't realize on windows virt-viewer doesn't work. Well, that's something to fix I guess. I have no idea how much work that is :( Today It looks like I need a Linux desktop to manage a KVM host or to access KVM guest consoles. Of course everything works fine using Xming and putty, but windows people doesn't like this. They want native windows tools that take care of all connection details, without need to start ssh tuneels by hand. :-( []s, Fernando Lozano ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] aSPICE and oVirt proxy
Hi Marc-Andre, Christophe, Thank you very much for your answers, it took me a little while to find the libgovirt code, but now I have it and will read it and remote-viewer's code to add the same functionality to aSPICE. Cheers, iordan On Mon, Aug 26, 2013 at 7:18 AM, Christophe Fergeau wrote: > On Sat, Aug 24, 2013 at 01:38:50AM +0200, Marc-André Lureau wrote: > > > > > 3) Do you think it is feasible to isolate the code which deals with > oVirt > > > proxy handling in virt-viewer and use that in aSPICE? > > > > > > > The isolation from libgovirt should be enough for implementing a > different > > client easily. > > Yes, there is not a lot of oVirt-related logic in virt-viewer, most of the > work is done in libgovirt. > > Christophe > -- The conscious mind has only one thread of execution. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] help
Hi, On 08/26/2013 02:43 AM, 天知道 wrote: Hi, When a video is playing, the client is turned on and off every two seconds. Then assert error appears in certain time given information on the stack。 What do you mean by "the client is turned on and off every two seconds"?. What are the server and client versions? Similar asserts to the one you describe have been fixed in Release 0.12.4 of the server. Cheers, Yonit. /detail log:/ ((null):10319): SpiceWorker-ERROR **: ../spice-common/common/ring.h:121:ring_next: assertion `pos->next != NULL && pos->prev != NULL' failed red_peer_receive: Connection reset by peer red_channel_client_disconnect: 0x7f3630764960 (channel 0x7f36304721c0 type 9 id 1) red_channel_client_disconnect: 0x7f3630764960 (channel 0x7f36304721c0 type 9 id 1) red_peer_receive: Connection reset by peer red_channel_client_disconnect: 0x7f36306b95a0 (channel 0x7f3630719b70 type 9 id 0) red_channel_client_disconnect: 0x7f36306b95a0 (channel 0x7f3630719b70 type 9 id 0) red_peer_receive: Connection reset by peer red_channel_client_disconnect: 0x7f36306a2010 (channel 0x7f36303eb050 type 1 id 0) main_channel_client_on_disconnect: rcc=0x7f36306a2010 red_client_destroy: destroy client with #channels 4 red_dispatcher_disconnect_cursor_peer: Thread 5 (Thread 0x7f3624e02700 (LWP 10395)): #0 0x7f362e05c054 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x7f362e057388 in _L_lock_854 () from /lib64/libpthread.so.0 #2 0x7f362e057257 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x7f362e71e000 in ?? () #4 0x7f362e71f5cb in ?? () #5 0x7f362e71fa29 in ?? () #6 0x7f362e72090d in ?? () #7 0x7f362e055851 in start_thread () from /lib64/libpthread.so.0 #8 0x7f362bf1267d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7f361700 (LWP 10398)): #0 0x7f362e05c054 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x7f362e057388 in _L_lock_854 () from /lib64/libpthread.so.0 #2 0x7f362e057257 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x7f362e71e000 in ?? () #4 0x7f362e71f5cb in ?? () #5 0x7f362e71fa29 in ?? () #6 0x7f362e72090d in ?? () #7 0x7f362e055851 in start_thread () from /lib64/libpthread.so.0 #8 0x7f362bf1267d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7f35efbfd700 (LWP 10407)): #0 0x7f362e05c54d in read () from /lib64/libpthread.so.0 #1 0x7f362c6aec10 in read () at /usr/include/bits/unistd.h:45 #2 spice_backtrace_gstack () at backtrace.c:100 #3 0x7f362c6b6d40 in spice_logv (log_domain=0x7f362c732f9e "SpiceWorker", log_level=SPICE_LOG_LEVEL_ERROR, strloc=0x7f362c72d8c0 "../spice-common/common/ring.h:121", function=0x7f362c735049 "ring_next", format=0x7f362c72dd58 "assertion `%s' failed", args=0x7f35efbfc8b0) at log.c:108 #4 0x7f362c6b6e7a in spice_log (log_domain=, log_level=, strloc=, function=, format=) at log.c:123 #5 0x7f362c67a62c in ring_next (ring=0x7f35e821d0e0, pos=0x7f35e8dbf410) at ../spice-common/common/ring.h:121 #6 0x7f362c692d0c in red_pipes_add_drawable (worker=0x7f35e80008c0, ring_is_empty=0x7f35efbfcc1c, max_pipe_size=50) at red_worker.c:1458 #7 red_process_drawable (worker=0x7f35e80008c0, ring_is_empty=0x7f35efbfcc1c, max_pipe_size=50) at red_worker.c:3994 #8 red_process_commands (worker=0x7f35e80008c0, ring_is_empty=0x7f35efbfcc1c, max_pipe_size=50) at red_worker.c:4932 #9 0x7f362c69558e in red_worker_main (arg=) at red_worker.c:11899 #10 0x7f362e055851 in start_thread () from /lib64/libpthread.so.0 #11 0x7f362bf1267d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7f362679e700 (LWP 15333)): #0 0x7f362e0597bb in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7f362e73d3c7 in ?? () #2 0x7f362e055851 in start_thread () from /lib64/libpthread.so.0 #3 0x7f362bf1267d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7f362e674940 (LWP 10319)): #0 0x7f362e05c54d in read () from /lib64/libpthread.so.0 #1 0x7f362c6749c3 in read (fd=19, buf=0x7fffba11542c "6\177", size=4, block=) at /usr/include/bits/unistd.h:45 #2 read_safe (fd=19, buf=0x7fffba11542c "6\177", size=4, block=) at dispatcher.c:76 #3 0x7f362c674bf6 in dispatcher_send_message (dispatcher=0x7f36306dc9e8, message_type=11, payload=0x7fffba115460) at dispatcher.c:188 #4 0x7f362c67564d in red_dispatcher_disconnect_cursor_peer (rcc=0x7f35e82b02c0) at red_dispatcher.c:201 #5 0x7f362c674335 in red_client_destroy (client=0x7f3630517150) at red_channel.c:1725 #6 0x7f362c69ea9b in reds_client_disconnect (client=0x7f3630517150) at reds.c:731 #7 0x7f362c670221 in red_peer_handle_incoming (rcc=0x7f36306a2010) at red_channel.c:285 #8 red_channel_client_receive (rcc=0x7f36306a2010) at red_channel.c:294 #9 0x7f362c670b3c in red_channel_client_event (fd=, event=, data=0x7f36306a2010) at red_channel.c:1207 #10 0x7f362e6fb3df in ?? () #11 0x7f362e71daca in ?? () #12 0x7f362e6
Re: [Spice-devel] [virt-tools-list] Where to put certificates for remote-viewer on windows [SOLVED, PARTIALLY]
Hi there,
I partially solved my question. Describing it here so others can find on
the mailing list archives.
That is, I solved only for remote-viewer on Windows. virt-viewer and
virsh still cannot connect using TLS.
I downloaded the latest virt-viewer installer for windows from
fedorahosted.org (0.5.7) and wish to use spice+tls to access VM
consoles from a Fedora machine. I know my certificates are properly
configured on the server side because I can connect from another
Fedora machine using both remote-viewer and virsh.
But on Windows it won't work. Virt-viewer was installed on the default
location, so I guessed I had to put cacert.pem on:
"C:\Program Files (x86)\VirtViewer\etc\pki\CA"
and the client certificates on:
"C:\Program Files (x86)\VirtViewer\etc\pki\libvirt"
Connections to libvirtd and to a spice server use different TLS setups.
I was mistaken beliving it was ok on my Linux machines, the fact was
they were connecting using TLS to libvirtd but then using an insecure
spice connection to the guest consoles. The same setup solved both Linux
and windows issues regarding spice, but those info is not easy to find.
The CA certificate configured on the kvm host (saved as
"/etc/pki/CA/cacert.pem") has to be copied to
$HOME/.spicec/spice_trusstore.pem. A symbolic link also works fine.
On Windows, you have to copy the CA cert "spice_trustore.pem" to
"C:\Users\\.spicec". Note Windows Explorer will refuse to
create a folder name starting with a dot, so you'll have to use the
Windows Command Prompt.
Then you can use connection URLs like "spice://kvmhost?tls-port=5901"
and be assured you'll use only TLS connections to the spice display
(checked using netstat on both Linux server and Windows client).
When I try to connect to the host using virsh.exe included on
viet-viewer install I get the error:
virsh # connect qemu://kvmserv/system
error: Failed to connect to the hypervisor
error: Cannot read CA certificate
'/usr/i686-w64-mingw32/sys-root/mingw/etc/pki/
CA/cacert.pem': No such file or directory
virsh # connect qemu+tls://kvmserv/system
error: Failed to connect to the hypervisor
error: Cannot read CA certificate
'/usr/i686-w64-mingw32/sys-root/mingw/etc/pki/
CA/cacert.pem': No such file or directory
I still can't find where to put certificates for virsh on Windows to
work. :-( I tried creating a ".pki\libvirt" folder on the "home" dir
("c:\users\") as a $HOME/.pki/libvirt works for linux
clients. This worked for ".spicec" and remote-viewer for windows, but
not for virsh and virt-viewer for Windows. I still get the same error
from virsh for Windows. If I had strace for Windows!
PS: virt-viewer on WIndows complained about a missing DDL. I got one from:
http://qemu.weilnetz.de/w32/dll/libssp-0.dll
And thus virt-viewer stopped complaining. But it can't connect to
libvirtd on the host yet. I assume by the same reason virsh can't: they
cannot find the certificates. But virt-viewer only tells "unable to
connect to libvirtd with URI..."
[]s, Fernando Lozano
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH] Remove incorrect option context from spicy-stats
The argument given to g_option_context_new() was apparently copy/pasted from
spicy-screenshot and therefore inaccurate for spicy-stats. Since the actual
description of the program (from _set_summary()) is displayed on the next line
anyway, simply make the context NULL.
---
gtk/spicy-stats.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gtk/spicy-stats.c b/gtk/spicy-stats.c
index 331e5e2..f176ead 100644
--- a/gtk/spicy-stats.c
+++ b/gtk/spicy-stats.c
@@ -95,7 +95,7 @@ int main(int argc, char *argv[])
textdomain(GETTEXT_PACKAGE);
/* parse opts */
-context = g_option_context_new(_(" - make screen shots"));
+context = g_option_context_new(NULL);
g_option_context_set_summary(context, _("A Spice client used for testing
and measurements."));
g_option_context_set_description(context, _("Report bugs to "
PACKAGE_BUGREPORT "."));
g_option_context_set_main_group(context, spice_cmdline_get_option_group());
--
1.8.3.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
