I just upgraded to F19. I have:
And when I open a guest console via virt-manager, if it has a dot in the name, it remains a gray screen and doesn't go any further. If guest name doesn't contain the dot, it works.
It happens because I have a local proxy, and when guest name has a dot, it tries to connect via proxy:
1370548338.179 0 ::1 TCP_DENIED/403 3535 CONNECT 127.0.0.1:5901 - HIER_NONE/- text/html
1370548338.180 0 127.0.0.1 TCP_DENIED/403 3537 CONNECT 127.0.0.1:5901 - HIER_NONE/- text/html
Instead of whatever it should be doing.
When it doesn't have a dot, it doesn't access the proxy.
Using http_proxy= virt-manager works around the issue.
Well.. not so sure about guest name anymore:
Installed another guest, named Fedora2, and same issue: can't open console via virt-manager when http_proxy environment var is configured, even though no proxy request is done.
Fedora2 is not a dns resolvable in here, just in case.
Guest name that works: sf00000000 (where 0 are actual numbers)
Please provide virt-manager --debug when reproducing, something weird must be going on.
Also 'sudo virsh dumpxml $vmname' of the working VM and the non working VMs
Shame on me for not noticing this difference before. --debug allowed me to spot it:
My guests that work, are using VNC. My guests that aren't working, are using Spice, and spice requests are issued through proxy, while vnc ones aren't:
2013-06-13 15:20:51,865 (console:1138): Starting connect process for proto=spice trans=None connhost=localhost connuser=None connport=None gaddr=127.0.0.1 gport=5902 gsocket=N
2013-06-13 15:20:51,866 (console:561): spice uri: spice://127.0.0.1?port=5902
(virt-manager:11263): GSpice-WARNING **: HTTP proxy connection failed: 403 Forbidden
2013-06-13 15:21:07,640 (console:413): VNC connection to 127.0.0.1:5902
2013-06-13 15:21:07,927 (console:1053): Viewer connected
And I failed to notice that Forbidden logged in my proxy log, ugh.
Allowed Spice through the proxy and it worked.
Is it really intended to run Spice through the proxy?? If yes, I think we are done here, thanks.
Yeah I think that's expected behavior. If anything VNC not acknowledging proxy settings is the bug. Closing
Hey Cole, but shouldn't we display a better error message, in case of spice/proxy thing? Like we do when connect() fail. I mean, relying on --debug or proxy logs (not always available to one who needs it) to catch this is too internal.
(In reply to Marcelo Ricardo Leitner from comment #5)
> Hey Cole, but shouldn't we display a better error message, in case of
> spice/proxy thing? Like we do when connect() fail. I mean, relying on
> --debug or proxy logs (not always available to one who needs it) to catch
> this is too internal.
Agreed it would be nice if we had a way to get this error programmatically in clients, but I don't think spice-gtk gives us a way to do that. Reassigning.
Did you set the SPICE_PROXY variable? I wonder why the spice http proxy is involved here.
Regarding error handling, spice-gtk does provide some (although it would need to be impreved, yes), and virt-viewer shows a dialog on connection error. It seems to work in this case too, when proxy fails.
There is a channel-event signal, and the event in this case is SPICE_CHANNEL_ERROR_CONNECT
(In reply to Marc-Andre Lureau from comment #7)
> Did you set the SPICE_PROXY variable? I wonder why the spice http proxy is
> involved here.
$ export | grep -i proxy
declare -x ftp_proxy="http://localhost:3128/"
declare -x http_proxy="http://localhost:3128/"
That was my surprise too, why it was using it.
Thanks for the pointer Marc-Andre. virt-manager catches spice connection errors now:
Author: Cole Robinson <email@example.com>
Date: Sun Sep 1 13:25:37 2013 -0400
console: Catch spice connection errors (bz #971558)
Just closing as UPSTREAM, this will hit Fedora when we rebase