1. Proposed title of this feature request: Offer Display type choice between SPICE and VNC for RHEV compute resources 2. Who is the customer behind the request? This information will be provided as a private comment. 3. What is the nature and description of the request? With RHEV registered on Satellite 6.2.10 as a compute resource, SPICE is used as Display type. No questions asked, no other options offered. Customer uses VNC by default on their RHV infrastructure, but Satellite will always set new RHV guests to SPICE. Customer would like to be able to choose VNC instead of SPICE. For comparison purposes, libvirt compute resource allows the user to choose between VNC and SPICE. 4. Why does the customer need this? Customer uses VNC by default as Display type on RHV when spinning new VMs on this RHV. This is a requirement for their standard environment. 5. How would the customer like to achieve this? On the webUI, navigate to Infrastructure > Compute resources. Click "Edit" next to a RHEV compute resource and change Display type from SPICE to VNC. This is precisely what libvirt compute resources offer as of today. With hammer this would be accomplished the same way as libvirt offers this switch: # hammer compute-resource update --id <ID> --display-type VNC 6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. Both webUI and hammer can be tested by the customer. Customer has a sandbox environment where they can test new things before going to production. 7. Is there already an existing RFE upstream or in Red Hat Bugzilla? This looks like an extension of this 5 year old upstream RFE: http://projects.theforeman.org/issues/1637 8. Does the customer have any specific timeline dependencies and which release would they like to target? As soon as possible but this is not critical. This is significantly convenient. While this new setting is not available the customer must go to RHEV and set the display type of each individual guest to VNC when the guest is provisioned. 9. Is the sales team involved in this request and do they have any additional input? No. 10. List any affected packages or components. Foreman, hammer, RHEV compute resources. 11. Would the customer be able to assist in testing this functionality if implemented? Yes.
*** Bug 1610463 has been marked as a duplicate of this bug. ***
What is the reason the customer prefer using VNC and not SPICE? SPICE is a better protocol, it delivers a high quality user experience, keeps CPU consumption low, and supports high quality video streaming. That's The Reason it's the default graphic protocol in Ovirt, Also, we can't implement in foreman any feature that exists in Ovirt, So unless we have a good reason for adding the option to change the graphics protocol in foreman I suggest we should close this bug.
(In reply to Shira Maximov from comment #4) > What is the reason the customer prefer using VNC and not SPICE? > SPICE is a better protocol, it delivers a high quality user experience, > keeps CPU consumption low, and supports high quality video streaming. > > That's The Reason it's the default graphic protocol in Ovirt, > Also, we can't implement in foreman any feature that exists in Ovirt, > So unless we have a good reason for adding the option to change the graphics > protocol in foreman I suggest we should close this bug. Customers in more secure environments do not have access/permissions to install additional software like virt-viewer on their workstation. This is required in order to connect to a SPICE session since the HTML5 SPICE client has been deprecated. RHV/oVirt provides a noVNC option for VMs that use a VNC console which solves this problem. RHV supports both SPICE and VNC so it would be useful to have that choice when provisioning with Satellite.
if we change the default graphic console to SPICE+VNC, would it solve the issue?
(In reply to Shira Maximov from comment #6) > if we change the default graphic console to SPICE+VNC, would it solve the > issue? Yes, that would solve the issue.
Created redmine issue https://projects.theforeman.org/issues/24532 from this bug
Does the customer want to be able to open the console from ovirt with VNC or from foreman?
(In reply to Shira Maximov from comment #9) > Does the customer want to be able to open the console from ovirt with VNC or > from foreman? The customer is only interested in opening the VNC console from oVirt.
After looking a bit, the VNC+SPICE allows you to open VNC and then SPICE without restarting the VM (and vice versa). This means that the customer will still need to choose VNC in the console options in order to connect for VNC. Are you sure that this option is good for the customer?
(In reply to Shira Maximov from comment #11) > After looking a bit, the VNC+SPICE allows you to open VNC and then SPICE > without restarting the VM (and vice versa). > This means that the customer will still need to choose VNC in the console > options in order to connect for VNC. > > Are you sure that this option is good for the customer? Yes, because it gives the customer the choice of console type they wish to use. Additionally, the console choice will be remembered so the customer will only need to choose once.
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/24532 has been resolved.
Verified with Sat 6.7 snap 10. Successfully created RHEV CR with default display type set, both through Hammer and through WebUI. When creating a new host, the default display type is pre-filled. It is not possible to set keyboard layout through Hammer, however, it's not a regression (the functionality is new) and it's out of scope of this BZ. I'll report a separate BZ about it. When trying SPICE console, I hit same-origin policy in Firefox but the same happened in Sat 6.5. VNC console works.
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://access.redhat.com/errata/RHSA-2020:1454