Description of problem: I have a (working) http_proxy. However it seems to confuse virt-viewer. When run with the http_proxy environment variable set, it prints out: $ virt-viewer rhel7betax64 -c qemu:///system ** (virt-viewer:20957): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-AFW8Zs1Bmc: Connection refused (virt-viewer:20957): GSpice-WARNING **: HTTP proxy connection failed: 403 Forbidden and a dialog box appears saying: "Unable to connect to the graphic server 127.0.0.1:5900" If I unset http_proxy then virt-viewer works fine. ie. This command is OK: $ http_proxy= virt-viewer rhel7betax64 -c qemu:///system ** (virt-viewer:20935): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-AFW8Zs1Bmc: Connection refused (virt-viewer:20935): GSpice-WARNING **: Warning no automount-inhibiting implementation available Version-Release number of selected component (if applicable): virt-viewer-0.5.7-1.fc20.x86_64 How reproducible: 100% Steps to Reproduce: 1. Set http_proxy to point to a proxy. 2. Run virt-viewer. Actual results: Fails unless http_proxy is unset.
Created attachment 835480 [details] Guest XML
$ echo $http_proxy http://cache.home.annexia.org:3128/
Could you attach the output of G_MESSAGES_DEBUG=all SPICE_DEBUG=1 virt-viewer --spice-debug rhel7betax64 -c qemu:///system when http_proxy is set?
Created attachment 835731 [details] spice debugging with http_proxy set (This is the one which fails)
Created attachment 835732 [details] spice debugging with http_proxy NOT set
Could it be a bug similar to rhbz#1021550? The connection is to 127.0.0.1:5900, I assume we should not be trying to use the proxy in this case?
If it's trying to connect to 127.0.0.1:5900 through the proxy, then that will fail. Why's it trying to use an HTTP proxy in any case?
This was added in http://lists.freedesktop.org/archives/spice-devel/2012-August/010606.html which does not really explain the 'why'. The use case is so that RHEV-like scenarios can proxy all SPICE connection to internal hosts through a single machine.
Still happens. Also this breaks the console button in RHEV-M. The tedious work-around is to download the console.vv file, then in a terminal, unset http_proxy & https_proxy and run: remote-viewer console.vv every single time .....
Doesn't look directly like a spice issue to me, since we don't use http_proxy variable. I don't get this behaviour on f21, could you try to break on getenv() condition name == "http_proxy" ?
I don't have any spice-using guests right now. Will need to try this later.
It's probably $libdir/gio/modules/libgiolibproxy.so from glib-networking which looks at the http_proxy env variable. It should be safe to temporarily move it some place else for a quick test when you get around to trying this again.
I set up a guest with spice: <video> <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1'/> <alias name='video0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> I'm using virt-viewer-1.0-2.fc21.x86_64, atk 2.14.0-1.fc21 cairo 1.13.1-0.4.git337ab1f.fc21 gdk-pixbuf2 2.31.1-1.fc21 glib2 2.42.1-1.fc21 gtk-vnc 0.5.3-6.fc21 libgovirt 0.3.2-1.fc21 libsoup 2.48.1-1.fc21 pango 1.36.8-1.fc21 rest 0.7.92-5.fc21 spice-gtk 0.27-3.fc21 I used the following break condition: (gdb) break getenv if strcmp($rdi,"http_proxy")==0 || strcmp($rdi,"https_proxy")==0 The following is the only stack trace where it hits this breakpoint: #0 0x00007ffff351bb00 in __GI_getenv (name=0x7fffd1413cc1 "http_proxy") at getenv.c:35 #1 0x00007fffd140fcb4 in envvar_config_extension::get_config(libproxy::url const&) () at /lib64/libproxy.so.1 #2 0x00007fffd1404886 in libproxy::proxy_factory::get_config(libproxy::url&, std::vector<libproxy::url, std::allocator<libproxy::url> >&, std::string&) () at /lib64/libproxy.so.1 #3 0x00007fffd14056ab in libproxy::proxy_factory::get_proxies(std::string) () at /lib64/libproxy.so.1 #4 0x00007fffd1405c9f in px_proxy_factory_get_proxies () at /lib64/libproxy.so.1 #5 0x00007fffd16523bd in get_libproxy_proxies () at /usr/lib64/gio/modules/libgiolibproxy.so #6 0x00007ffff43e9bc5 in g_task_thread_pool_thread (thread_data=0x85e690, pool_data=<optimized out>) at gtask.c:1215 #7 0x00007ffff3e4e148 in g_thread_pool_thread_proxy (data=<optimized out>) at gthreadpool.c:307 #8 0x00007ffff3e4d7b5 in g_thread_proxy (data=0x9a2230) at gthread.c:764 #9 0x00007ffff38a752a in start_thread (arg=0x7fffd0bff700) at pthread_create.c:310 #10 0x00007ffff35e379d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
sent a patch: http://lists.freedesktop.org/archives/spice-devel/2015-April/019577.html
Thanks. I tested this by applying the patch in comment 15 to the Fedora Rawhide spice-gtk package (spice-gtk3-0.28-2.fc23). I created a virtual machine with a spice graphical console: $ virt-builder rhel-7.1 $ virt-install --import --name=tmp-spice --ram=4096 --os-type=linux --os-variant=rhel7 --disk=rhel-7.1.img,format=raw Before installing the updated spice-gtk package, virt-viewer would fail with the http error outlined in this bug. After installing the updated spice-gtk package, virt-viewer was able to access the spice console, even though http_proxy and https_proxy environment variables were set. Therefore as a result of my testing I would say the patch fixes this bug.
f22 should have spice-gtk 0.29 with the fixes now