Bug 1025454 - User is forced to install spicex/virt-viewer twice when upgrading from 3.2
User is forced to install spicex/virt-viewer twice when upgrading from 3.2
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: spice-activex-win (Show other bugs)
3.3.0
Unspecified Unspecified
unspecified Severity medium
: ---
: 3.3.0
Assigned To: Uri Lublin
SPICE QE bug list
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-31 14:20 EDT by Marian Krcmarik
Modified: 2015-08-27 09:58 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-27 09:58:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Marian Krcmarik 2013-10-31 14:20:45 EDT
Description of problem:
When upgrading spicex and virt-viewer from 3.2 version to latest 3.3 version an user is asked to go through the installation twice.
The process is following:
1. Click on console button -> User portal prompts user to install spicex plugin.
2. User portal is reload -> Click on console button, user is prompted to Install virt-viewer.
3. Once the installation is done and user clicks on the console button again the process repeats.
4. Click on console button -> User portal prompts user to install spicex plugin.
5. User portal is reload -> Click on console button, user is prompted to Install virt-viewer.
6. Click on console button The remote-viewer is opened successfully.

Version-Release number of selected component (if applicable):
rhevm-spice-client-x*-cab-3.3-5 (includes spicex-win-3.3-5 and mingw-virt-viewer-0.5.6-8 on RHEVM3.3 is19/20.
Windows 7 guest.

How reproducible:
always

Steps to Reproduce:
1. Connect from clean Windows 7 client to RHEVM3.2 managed VM, to get 3.2 spicex/virt-viewer installed.
2. Do the same with 3.3 RHEVM.

Actual results:
Installation process within spicex/virt-viewer upgrade is being done twice.

Expected results:
Only one installation required.

Additional info:
Comment 3 Marc-Andre Lureau 2013-12-12 09:52:59 EST
Marian, can you check that all instanced of IE were closed, and that the activex wasn't loaded already? I think ListDLLs can do that (http://technet.microsoft.com/en-us/sysinternals/bb896656.aspx)

The installation is triggered by IE when the currently installed activex isn't new enough. The activex update can fail when the dll is already in use. This isn't new.
Comment 4 Marian Krcmarik 2013-12-16 11:40:56 EST
(In reply to Marc-Andre Lureau from comment #3)
> Marian, can you check that all instanced of IE were closed, and that the
> activex wasn't loaded already? I think ListDLLs can do that
> (http://technet.microsoft.com/en-us/sysinternals/bb896656.aspx)
> 
> The installation is triggered by IE when the currently installed activex
> isn't new enough. The activex update can fail when the dll is already in
> use. This isn't new.

Maybe It's the case, It happens when I open i.e. console from RHEVM3.2, close the tab, open a new tab while keeping IE running and trying to open console from RHEVM3.3, first installation/upgrade is not successful. So most likely a case we cannot or even are not able to support
Comment 5 Marc-Andre Lureau 2013-12-16 11:56:15 EST
(In reply to Marian Krcmarik from comment #4)
> Maybe It's the case, It happens when I open i.e. console from RHEVM3.2,
> close the tab, open a new tab while keeping IE running and trying to open
> console from RHEVM3.3, first installation/upgrade is not successful. So most
> likely a case we cannot or even are not able to support

I think it's possible to handle this when using activex/cab install mechanism only. It will save and register the dll in a different path. So in theory, this could be improved by moving back the dll from the NSIS installer to the .inf file.

But tbh, I don't see the point of doing that as it will go into even more complicated scenarios (new client installed with old activex still in place etc) That .inf installation mechanism should just really die.

Note You need to log in before you can comment on or make changes to this bug.