Description of problem: In Opaque, I recently started setting the proxy property of SpiceSession from the console file, as is done in remote-viewer, in order to support installations where the nodes are not "visible" from the point of view of the client that use spice-proxy: http://www.ovirt.org/Features/Spice_Proxy However, then I remembered that I have not seen the proxy property being available through the oVirt/RHEV API. I looked at the latest remote-viewer code, and I looked through the oVirt/RHEV API documentation, and indeed, I see no way to get proxy information other than through the console.vv file. This means that both Opaque and remote-viewer cannot connect to VMs behind a proxy unless a console.vv file is used, which also means that since console.vv files are currently unobtainable through the User Portal on mobile devices, mobile devices effectively cannot at all connect to such VMs if the user is not an Administrator using the Admin Portal. We would need to expose the proxy parameter through the API, probably in the VM display parameter in order to allow Opaque and remote-viewer to connect to such VMs without going through the web interface and using a console.vv file. Version-Release number of selected component (if applicable): oVirt 3.3 was tested and shows the issue, but it is probably present in all past and current versions too. How reproducible: 100% Steps to Reproduce: 1. Browsing through the API shows no information about spice-proxy. 2. Looking through the API documentation finds no information about it. Actual results: Information about spice proxy unavailable through the API. Information about the parameter not available in the API documentation. Expected results: The opposite to the actual results :).
its actually not present in previous versions, since its a new feature in 3.3, which seems to have missed adding the api part for this.
Thank you for making this a high-priority item, Itamar!
Currently, in the backend, we have a global "SpiceProxyDefault" configuration parameter, but it isn't accessible via the API. Also, recently we introduced the capability to override this at the cluster and VM pool levels. This is already supported in the API. For example, for a cluster: <cluster id="..." href="..."> <name>Default</name> ... <display> <proxy>the_proxy_address</proxy> </display> </cluster> You can take advantage of this for a workaround: assign a proxy to the cluster or VM pool level, and then, in the Opaque code, find the cluster or VM pool corresponding to the VM, and get the proxy address from there. I know that this isn't ideal. What I would suggest as a definitive solution is to populate the "cluster.display.proxy" even if it isn't overridden: taking the value from the global configuration parameter. We should probably do the same for VMs: populate the already existing "vm.display.proxy" element from the cluster or from the global configuration parameter. This is similar to what we do for permissions. This logic to calculate the proxy address should be part of the backend, not of the API, so that the GUI benefits from it as well.
Hi Juan, Thanks for detailing a possible workaround. I'll wait to see if there is a use-case for it. It would be great if you eventually populate vm.display.proxy. Thanks! iordan
this may get revisited when UI will use REST as we may need to expose all system config values anyway. Then it makes more sense to just expose the VM property and do not "resolve" the address
Hi Michal, Does that mean that you will not be fixing this issue or you will still fix it but revisit it later on? Thanks! iordan
comment #3 is a good suggestion, should not be that hard to add. weshould expose the token for rwebsockets too
What was the change introduced so that the bug went into ON_QA? Does this mean that in 3.5.0 the proxy parameter is now exposed through api?
The change introduced is that the proxy settings are propagated from the global settomg or from the cluster to each VM, so if you request a VM you will get something like this: GET /api/vms/{vm_id} <vm id="..."> <display> <type>spice</type> <monitors>1</monitors> <proxy>http://myproxy.exampl.com:8080</proxy> <-- This is proxy address ... </display> </vm> So you no longer need the workaround described in comment 3, you can just get the "proxy" element from the VM itself.
oVirt 3.5.1 has been released. If problems still persist, please make note of it in this bug report.