Description of problem: When user performs upgrade to 3.3.1 from 3.3.0 SPICE activeX download starts to fail. Version-Release number of selected component (if applicable): 3.3.1 How reproducible: 100 % reproducible on 3.3.1 and IE9, occasionally reproducible with other IEs as well Steps to Reproduce: 1. Have 3.3.0 with the ActiveX insalled on client 2. Upgrade to 3.3.1 3. Try connecting to VM using IE9 (a.k.a upgrade SPICE) Actual results: Failure. Server.log contains messages showing that client reset the connection. There is no network failure and tcpdump clearly shows client reset was sent during process of downloading the cabinet file Expected results: Should not fail Additional info: Server.log 2014-03-22 15:09:07,561 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/].[files]] (ajp-/127.0.0.1:8702-3) JBWEB000236: Servlet.service() for servlet files threw exception: java.io.IOException: Error sending file "/usr/share/ovirt-engine/files/spice/SpiceX.cab". at org.ovirt.engine.core.utils.servlet.ServletUtils.writeFileToStream(ServletUtils.java:135) [utils.jar:] at org.ovirt.engine.core.utils.servlet.ServletUtils.sendFile(ServletUtils.java:101) [utils.jar:] at org.ovirt.engine.core.FileServlet.doGet(FileServlet.java:99) [classes:] at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec.jar:1.0.2.Final-redhat-1] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec.jar:1.0.2.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb.jar:7.3.0.Final-redhat-2] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb.jar:7.3.0.Final-redhat-2] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) [jbossweb.jar:7.3.0.Final-redhat-2] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb.jar:7.3.0.Final-redhat-2] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web.jar:7.3.1.Final-redhat-4] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb.jar:7.3.0.Final-redhat-2] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb.jar:7.3.0.Final-redhat-2] at org.jboss.web.rewrite.RewriteValve.invoke(RewriteValve.java:466) [jbossweb.jar:7.3.0.Final-redhat-2] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb.jar:7.3.0.Final-redhat-2] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb.jar:7.3.0.Final-redhat-2] at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:488) [jbossweb.jar:7.3.0.Final-redhat-2] at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:420) [jbossweb.jar:7.3.0.Final-redhat-2] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb.jar:7.3.0.Final-redhat-2] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] Caused by: ClientAbortException: java.net.SocketException: Connection reset at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:403) [jbossweb.jar:7.3.0.Final-redhat-2] at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:450) [jbossweb.jar:7.3.0.Final-redhat-2] at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:351) [jbossweb.jar:7.3.0.Final-redhat-2] at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:426) [jbossweb.jar:7.3.0.Final-redhat-2] at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:415) [jbossweb.jar:7.3.0.Final-redhat-2] at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:89) [jbossweb.jar:7.3.0.Final-redhat-2] at org.ovirt.engine.core.utils.servlet.ServletUtils.writeFileToStream(ServletUtils.java:129) [utils.jar:] ... 18 more Caused by: java.net.SocketException: Connection reset at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:118) [rt.jar:1.7.0_51] at java.net.SocketOutputStream.write(SocketOutputStream.java:159) [rt.jar:1.7.0_51] at org.apache.coyote.ajp.AjpProcessor$SocketOutputBuffer.doWrite(AjpProcessor.java:1320) [jbossweb.jar:7.3.0.Final-redhat-2] at org.apache.coyote.Response.doWrite(Response.java:594) [jbossweb.jar:7.3.0.Final-redhat-2] at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:398) [jbossweb.jar:7.3.0.Final-redhat-2] ... 24 more TCPdump entry: 123 0.155948 172.30.65.190 146.106.39.37 TCP 60 54926 > https [RST, ACK] Seq=800 Ack=35225 Win=0 Len=0
I tried to reproduced with a fresh win7-Pro-N x86, after updating to IE9 (9.0.8.8112.16421) with default settings. I am serving OSpiceX_x86.htm with python -m SimpleHTTPServer on a second machine. I succesfully installed SpiceX version 5,0,3,3005, then 5,0,3,3011. So I can't reproduce so far. What are the versions of spice-client-msi or CAB version being tested? Does it fail with any upgrade starting from rhevm 3.3? Does it fail with any Win7 version or a particular version / arch? According to Marian in comment #13, it also fails with ie11, but do you get the same error?
Tim can you please find these out from the customer?
Hi Marc-Andre, I was also able to upgrade the plugin using dummy page. The problems appeared when I added simulated timeout before plugin is loaded. In that case I was able to reproduce this "dialog loop". Franta.
(In reply to Frantisek Kobzik from comment #27) > Hi Marc-Andre, > > I was also able to upgrade the plugin using dummy page. The problems > appeared when I added simulated timeout before plugin is loaded. In that > case I was able to reproduce this "dialog loop". What is "simulated timeout", what does it have to do with the CAB? if the upgrade works with a dummy page, there isn't much else we can do, right?
Moving to 3.4.3 as 3.4.2 already GA'ed.
Tested upgrading from spicex-win 3.3-8 (3.3.0) to spicex-win 3.3-11 (3.3.1) using test-html page, Windows 7 x64, Windows Explorer 9 x64. Works for me in the following 2 ways: 1. Before going to the page with the newer version close the page of the older one (the test html page). 2. If upgrade failed the first time, refresh/retry and it's installed successfully the second time. Could reproduce the problem with of CAB not installing with RHEV-M (3.3.2-0.50 and 3.4.2-0.2). Need to investigate more. Is it possible to install virt-viewer msi (as admin) on the client machine, and use "Native Client" (aka vv-files) in Spice Options on RHEV-M Portal ?
Actually both 3.3.0 and 3.3.1 come with spice cab 3.3-8 Only builds >= 3.3.2 contain spice cab 3.3-11
back to default assignee: According to Uri's tests both 3.3.0 and 3.3.1 have the same CAB. NOt sure we can do more, back to the rhevm to continue investigation.
I spent a lot of time on this issue again and I have no idea what could go wrong. I looked into windows event logs, tried simulating timeouts, tried adding my our engine fqdn into trusted sites, tried installing with various security features of ie enabled/disabled and still no luck with installing. I know windows more or less from user POV only and I ran out of ideas on what to do about this. I don't know why the feature works in 3.3.0 and not in later releases (3.3.1 differs from 3.3.0 in couple of patches). I was only able to update the plugin via 'run as admin' way.
found the culprit, seems it works in 3.3.4+ cab without the original workaround. Will post revert to it
this bug status was moved to MODIFIED before engine vt5 was built, hence moving to on_qa, if this was mistake and the fix isn't in, please contact rhev-integ
Can you provide some verification steps?
Totally correct verification consists of two steps: 1, Install 'old' plugin to your IE. That means: - installing latest RHEV 3.4 environment, - creating a SPICE VM in it, set 'Browser plugin' in 'Console options', - connect to this VM in _CLEAN_ Internet Explorer, - install active-x plugin, - verify plugin is installed ('Add-ons' menu in ie), check its version (should be 5.0.3.4004), 2, Verify upgrade: - upgrade to RHEV 3.5, - try to connect to the same VM (if the page refreshes, and the plugin is not upgraded, try connecting to console once more - this is not a bug, this is a feature :/ ). Expected results: - the plugin upgrades (version should be higher than before [it should correspond to engine file /usr/share/spice/SpiceVersionXXX.txt, where XXX is x64 or x86 depending on which IE you run).
activeX plugin successfully updated using 3.4 -> 3.5 engine moving to VERIFIED
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. https://rhn.redhat.com/errata/RHSA-2015-0158.html