Description of problem:
RHEVM sends to XPI SPICE plugin always SPICE proxy even one unchecks this options in Console Options.
# engine-config -g SpiceProxyDefault
SpiceProxyDefault: http://10.34.63.76:3128/ version: general
$ sudo tcpdump -i eth0 -tttt -nn dst port 3128
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
2014-01-07 15:53:49.352756 IP 10.34.131.48.49193 > 10.34.63.76.3128: Flags [S], seq 1570298935, win 14600, options [mss 1460,sackOK,TS val 63395998 ecr 0,nop,wscale 7], length 0o
$ sudo sed -n '/Jan 7 15:53:45/,$p' /var/log/messages | grep -i proxy
Jan 7 15:53:45 localhost spice: SPICE_PROXY=http://10.34.63.76:3128/
Jan 7 15:53:49 localhost spice: (remote-viewer:22936): GSpice-DEBUG: spice-session.c:1815 (with proxy http://10.34.63.76:3128)
Jan 7 15:53:49 localhost spice: (remote-viewer:22936): GSpice-DEBUG: spice-session.c:1760 proxy lookup ready
$ sed -n '/2014-01-07 15:53:45,940/,$p' .spicec/spice-xpi.log | grep -i proxy
$ sed -n '/2014-01-07 15:53:45,940/,$p' .spicec/spice-xpi.log | grep -i 3128
In attachment there is: engine.log, spice-xpi.log, messages having DEBUG from spice xpi/remote-viewer and screenshots...
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. define spice proxy with engine-config and restart
2. VM - console options: plugin/uncheck spice proxy and open console
it tries to use proxy
should not use proxy
Created attachment 846737 [details]
I found the reproducer is a little bit trickier:
1. Launch browser and log into User Portal.
2. Open VM Console options, uncheck the SPICE proxy & save.
3. Open VM console -> VM console is opened this time!
4. Open VM Console options, check the SPICE proxy, save and try to open VM console again -> error "Unable to connect to the graphic server (null)".
5. Repeat steps 2 and 3. -> from this time the error is always returned.
In the very same way this bug affects also RHEVM 3.3 (rhevm-3.3.0-0.43.el6ev.noarch - is30).
use case doesn't sound interesting enough for 3.5
moreover can't reproduce on dev setup yet
care to re-try? we couldn't reproduce and I'm not aware of any complaints from teh field…would close otherwise
I can still reproduce, proxy is not "reset" if it is unchecked in Console Options for browser plugin (xpi).
You should probably ask GSS who uses proxy and let them check.
we didn't reproduce back then, nor now.
if you happen to reproduce please specify exact steps and make sure it reproduces on another setup too
i can reproduce exactly as written in #2.
OK, finally reproduced and it seems as an issue in spice-xpi.
Hi, it seems that when enabling the spice proxy in spice-xpi there is no way to disable it again - only restarting the browser.
It reproduces on:
all are the default versions on RHEL 6.6
please note it does not reproduce on Fedora 20 (spice-xpi-2.8.90-1.fc20.x86_64, virt-viewer-0.6.0-1.fc20.x86_64)
I was able to reproduce it both using oVirt and using the test page available here: https://teuf.fedorapeople.org/plugins/test.html
The steps for test page:
- fill in the host/port
- it will work
- enable spice proxy and enter an incorrect value
- it will fail to connect since the proxy is not correct
- disable the spice proxy again and connect
- it will fail with the same error as when the proxy is enabled
after restarting the browser the spice proxy is disabled again and it is possible to connect again.
Is this a know issue? Since it seems to be fixed in more recent versions.
Created attachment 1002406 [details]
Unset SPICE_PROXY env var when proxy is not set
This does not seem to be fixed upstream, but is working because upstream no longer looks at the SPICE_PROXY environment variable (?)
This patch fixes the issue for me (RHEL6 scratch build at https://brewweb.devel.redhat.com/taskinfo?taskID=8855582 ), I'll need to send a proper patch upstream
I have tried the https://brewweb.devel.redhat.com/taskinfo?taskID=8855582 with my userportal and it works well - thanx!
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.