Description of problem: Installing the RHEV 3.3 version of Remote Viewer using the ActiveX cab installation (Console Settings: "Browser plugin") causes the console.vv files to not be automatically associated with the Remote Viewer application. Version-Release number of selected component (if applicable): rhevm-spice-client-x86-msi-3.3-5.el6_4.noarch rhevm-spice-client-x64-msi-3.3-5.el6_4.noarch How reproducible: Very Steps to Reproduce: 1. Launch a fresh copy of Windows 7 with no previous Remote Viewers installed 2. Connect to a RHEV 3.3 beta instance using Internet Explorer 3. Select "Browser plugin" in the Console Options 4. Connect to the console and accept the ActiveX spice.cab installation dialogs 5. After IE reloads the page, attempt to connect to the console again 6. Verify the console launches using the "Browser plugin" method 7. Close that console and change the Console Options to "Native" 8. Click the Console button again 9. When the Open/Save box appears, click Open. Actual results: Windows does not know which application to use to open .vv files Expected results: Windows should be auto-associated with .vv files when Remote Viewer is installed via .cab Additional info: Installing Remote Viewer via .msi correctly associates the .vv files.
This scenario is not supported. ActiveX/CAB or MSI/vv.
(In reply to Marc-Andre Lureau from comment #1) > This scenario is not supported. > > ActiveX/CAB > > or > > MSI/vv. But, don't we want people who originally started with the CAB to eventually transition over to using the vv files? Having the CAB installer associate this file type for the user would be useful, or, at the very least, we should make note of it in our documentation. Perhaps bug 1039217?
I think I don't understand. Please clarify. Afaik, we were using MSI installation when accessing console from the Admin Portal on Windows; and CAB - in all the other cases. How does this work now? And how does it make this scenario unsupported. Thank you.
(In reply to Marina from comment #3) > I think I don't understand. > Please clarify. > Afaik, we were using MSI installation when accessing console from the Admin > Portal on Windows; and CAB - in all the other cases. How does this work now? > And how does it make this scenario unsupported. If you install remote-viewer with CAB, you get user installation and ActiveX support. If you install admin MSI, you get all-user remote-viewer and .vv file association. Associating .vv file with user installed CAB will increase the complexity and make transitioning unnecessarily harder to MSI. If you use CAB install, you are already using IE and thus should stick to ActiveX. There is no reason to switch to vv in this case. If you dont use IE (or disable ActiveX), you will need the MSI & vv. Please explain the rationale of other cases.
Marina, When remote-viewer is installed via CAB/ActiveX, it is installed with IE and works with ActiveX enabled. There is thus no good reason to register .vv file support. If you need/want .vv file support, you are running with ActiveX disabled, and thus will need to install virt-viewer via MSI. Thus there is no reason to register .vv file association with CAB/ActiveX installation. Doing so would increase complexity for no good reason.
Thank you for the explanations. Let's see if I understand correctly. So, do you say that ActiveX would know to open the remote-viewer(rv)(for both spice and vnc traffic) without associating the vv file? And that's why there is no need to associate the vv file with it? And the only time the vv file would be used is when we choose native in console option. But for IE this is not the default and not the recommended option. And since so, we are not going to implement the request on this bug. As well, there is no difference in running the rv via the browser plugin or the native option. Both would result in opening the same rv with the required protocol. So that there is no benefit for the end user to switch to Native method, if he is using browser plugin. If this is all correct, I would agree to have this bug closed. Marc-Andre, please confirm.
(In reply to Marina from comment #6) > Thank you for the explanations. Let's see if I understand correctly. > > So, do you say that ActiveX would know to open the remote-viewer(rv)(for > both spice and vnc traffic) without associating the vv file? And that's why > there is no need to associate the vv file with it? ActiveX works only with spice. If you want VNC support, you can't use ActiveX, you need to use native/mime/.vv file. You will have to install the MSI since CAB/ActiveX is disabled. > And the only time the vv file would be used is when we choose native in > console option. But for IE this is not the default and not the recommended > option. > And since so, we are not going to implement the request on this bug. If you use native/.vv you still have to install remote-viewer, and the supported method in this case is with MSI installer. > As well, there is no difference in running the rv via the browser plugin or > the native option. Both would result in opening the same rv with the > required protocol. So that there is no benefit for the end user to switch to > Native method, if he is using browser plugin. There are many benefits in using native option and MSI: - better installation, removal and update method, especially for domain administrators - vnc support - works with ActiveX disabled (default in some IE version) - works with other browsers (firefox, chrome..) - arguably easier to debug (no IPC controller but readable .vv file, can switch to older/newer client easily, installed in common path...) - do not need to run IE as admin to install USB clerk - ActiveX could sometime hang or crash IE, not the native method
Great. One last question (hopefully) to confirm on this: > If you use native/.vv you still have to install remote-viewer, and the > supported method in this case is with MSI installer. When selecting native on the console options on IE, would it run the MSI or not? If it would, I would completely agree with having this bug closed wonfix.
(In reply to Marina from comment #8) > Great. > One last question (hopefully) to confirm on this: > When selecting native on the console options on IE, would it run the MSI or > not? > If it would, I would completely agree with having this bug closed wonfix. If you select Native, all that your browser is presented with is a console.vv file. If you do not already have the .MSI Remote Viewer installed, all you will see is this text file. Basically, with the .MSI, the user has to manually install it or their admin needs to install it for them via Active Directory policy. There's no automatic install or upgrade like we have now with the CAB.
Ok. I finally got an environment and tested it. Indeed, when Native is selected, there is no MSI installing the rv for me, and of course, it is not associating the vv file with anything. So - where is the MSI doing this for me?
There is a separate bug for this: https://bugzilla.redhat.com/show_bug.cgi?id=997418 And it is not spice at this moment, but RHEV-M.
After talking to the spice team I agree to have this closed, as well as having BZ#997418 not being implemented yet (or at least not urgent to be implemented). And this is because: - customers using default setting will continue using those default setting and all will be good for them. (default setting will open browser plugin, without vv file at all). - for advanced customers willing to try the features of the native client, we should make a KCS, explaining how to get the MSI, how to uninstall activeX and that's all, I believe. (The files should be available on rhev-m machine under /usr/share/spice (assuming rhevm-spice-client rpms are installed on that specific RHEV-M machine). - in future version, we will completely switch to native viewer in all possible versions. David, is this correct? Do we have bugs for this so that we can attach it to the KCS we will create? And what is the timeline? 3.4?