the "display -> type" value of the VM in the REST API seem to map to different properties based on the VM status. see http://i.imgur.com/Mn1RITW.png: When the VM is Up, the "display -> type" value in the REST API matches the 'Display' value in the GUI. But when the VM is Down, the "display -> type" value in the REST API matches the 'Graphics Protocol' value in the GUI and does not necessarily match the'Display' value (e.g. in case we invoked 'Run Once' on the VM with a different Console value). This is confusing. Maybe need to have two properties in the REST API to match the two displayed values in the GUI: 'Display' (which, IIUC, is the 'run-time' value) and 'Graphics Protocol' (which, IIUC, is the 'configured'/persisted value). [If there are plans to refactor the entire VM-display area in the code, feel free to block this BZ on the relevant refactor BZ / close this BZ as duplicate / ...]
it behaves like this: - web admin's subtab's "graphics protocol" shows the list of devices statically set for VM (regardless of the state of the VM as currently runs). e.g. if in edit VM set to SPICE it will show SPICE (btw it reads it from VmDevices) - web admin's main tab's "display" shows the data as returned from VDSM (e.g. the content of VM Dynamic). So if using run once changed from SPICE to VNC this will show the VNC instead of SPICE - the REST's "display" shows the dynamic data if present (e.g. if the VM is running) and falls back to show the static data if not. So, I think that: - the REST shows it correctly (e.g. if the VM is running than shows what is there in fact and if not than what is configured) - maintab shows only the dynamic value (same as for example for memory usage) and shows "None" if not running) so I'd say it is correct - subtab shows the static value which is AFAIK also correct and in line with the rest of the UI The only problem I see is with the naming (once called Display once Graphics protocol which does not signify that it is the same but once from dynamic configuration and once from static). Franta have proposed the name "Graphics" to be used in the main tab instead of "Display" which is certainly better but I'm not sure about it. @Einav: would that be a sufficient fix for you? Or can you suggest a better name?
the renaming will definitely take care of the confusion, however I am still uncomfortable with having different pieces of information in the API and in the UI. isn't the "graphics protocol" (static) data important for REST API users as well, even when the VM is running? moreover: If tomorrow we will move the GUI to work over the REST API, we will not have the relevant data to bind to the GUI - what will we do then? I am 'needinfo'ing Juan for his take on this issue, but IMO: If the "graphics protocol" (static) data is / may be important to have, even while the VM is running - it should be available in the REST API. If it is not important - it should not be available at all, i.e. it should be hidden in the GUI.
Users of the RESTAPI will probably want to get the information about the graphics capabilities of a VM for two reasons: 1. To use it in order to actually connect to one of the graphics devices of the VM when it is running. 2. To check or modify the characteristics of the graphics devices that will be used by default the next time the VM is started. I think that both are important. We have this same situation with CDROMS, for example, and in that case we are using a "current" matrix parameter to differentiate these two situations: # Get the CDROMs that the VM is currently using: GET /api/vms/{vm:id}/cdroms;current # Get the CDROMS that the VM will use by default next time it is started: GET /api/vms/{vm:id}/cdroms In both cases the representation of the entity is the same, the difference is the content. We can do the same for graphics devices, but only with the new representation of graphics devices to be introduced in 3.6, we can't change how "display" currently behaves. I have to say that I think that there shouldn't be these two "current" and "persistent" states, as it makes things confusing for users of the API. It would be better to require users to edit the VM before running it, instead of having a "run once" functionality.
the 43077 adds the support for ;current=true/false for the graphics devices to the REST the 38004 does the rename in webadmin now it should be consistent and the REST should be complete.
Closing old bugs. In case still happens, pls reopen.