Bug 864961 - Default VM display type overrides current VM display type in REST API
Default VM display type overrides current VM display type in REST API
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-restapi (Show other bugs)
3.1.0
Unspecified Unspecified
unspecified Severity medium
: ---
: 3.2.0
Assigned To: Ravi Nori
Ido Begun
virt
: Reopened
Depends On:
Blocks: 915537
  Show dependency treegraph
 
Reported: 2012-10-10 09:40 EDT by Ido Begun
Modified: 2013-08-09 01:40 EDT (History)
10 users (show)

See Also:
Fixed In Version: sf1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-11 05:19:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Logs (474.94 KB, application/x-gzip)
2012-10-10 10:33 EDT, Ido Begun
no flags Details

  None (edit)
Description Ido Begun 2012-10-10 09:40:26 EDT
Description of problem:
Similar to: https://bugzilla.redhat.com/show_bug.cgi?id=804385


Version-Release number of selected component (if applicable):
SI20

How reproducible:
100%

Steps to Reproduce:
1. Create a VM with VNC as default display type
2. Use 'run once' to run VM with spice as display type
3. Check display type under <display> section in REST API
  
Actual results:
Display type is VNC

Expected results:
Display type should be spice

Additional info:
Comment 1 Haim 2012-10-10 10:05:30 EDT
logs?
Comment 2 Ido Begun 2012-10-10 10:33:40 EDT
Created attachment 624920 [details]
Logs

Relevant data appears at the end of logs.
Comment 3 Simon Grinberg 2012-10-11 07:48:05 EDT
Why is this a bug?
VM properties did not change, the display type is still VNC. 

Run Once only overrides the current startup configuration which is not listed since it's transient. When you get a VM object you are supposed to get the configuration, so you may properly be able to edit it. 

I think the solution may be and RFE (if not exists) to extend the API to retrieve run once parameters, if the VMs was started using run once.
Comment 4 Simon Grinberg 2012-10-14 05:07:06 EDT
Oded. per comment #3, please find out if there is another way to get this info, or convert this to an RFE to retrieve the run-once properties of a running VM.
Comment 5 Michael Pasternak 2012-10-14 06:58:17 EDT
(In reply to comment #4)
> Oded. per comment #3, please find out if there is another way to get this
> info, or convert this to an RFE to retrieve the run-once properties of a
> running VM.

the meaning of the run-once command is: do-not-store, 
if you want to persist vm config, update vm.

also such RFE won't be feasible. as it will break run-once concept.
Comment 6 Oded Ramraz 2012-10-14 07:42:49 EDT
When I run the VM from UI using run once and choosing X display type , I see it with X display type under VM's tab , even when it defined with Y as default display type.
Shouldn't the behavior be the same in API / CLI ?
Comment 7 Michael Pasternak 2012-10-14 07:45:39 EDT
(In reply to comment #6)
> When I run the VM from UI using run once and choosing X display type , I see
> it with X display type under VM's tab , even when it defined with Y as
> default display type.
> Shouldn't the behavior be the same in API / CLI ?

if vm running yes, if it's down, no, what was the state of the vm?
Comment 8 Ido Begun 2012-10-14 08:09:40 EDT
(In reply to comment #7)
> (In reply to comment #6)
> > When I run the VM from UI using run once and choosing X display type , I see
> > it with X display type under VM's tab , even when it defined with Y as
> > default display type.
> > Shouldn't the behavior be the same in API / CLI ?
> 
> if vm running yes, if it's down, no, what was the state of the vm?

When defining the VM with default display type=VNC, then running the VM using run-once with display type=spice, we get different values in UI and API (while VM is running):
In UI - display type = spice
In API - display type = VNC
Comment 9 Michal Skrivanek 2012-10-15 09:27:12 EDT
> When defining the VM with default display type=VNC, then running the VM
> using run-once with display type=spice, we get different values in UI and
> API (while VM is running):
> In UI - display type = spice
> In API - display type = VNC
then I suppose GUI should be changed to rather show the permanent value, just so you won't overwrite it accidentally while editing VM when it's run via Run Once.

sounds like a minor bug
Comment 10 Oded Ramraz 2012-10-15 09:34:03 EDT
(In reply to comment #9)
> > When defining the VM with default display type=VNC, then running the VM
> > using run-once with display type=spice, we get different values in UI and
> > API (while VM is running):
> > In UI - display type = spice
> > In API - display type = VNC
> then I suppose GUI should be changed to rather show the permanent value,
> just so you won't overwrite it accidentally while editing VM when it's run
> via Run Once.
> 
> sounds like a minor bug

It is not minor issue since those details are important and cannot retrieved easily,  they also don't appear in the events logs.
Comment 11 Michal Skrivanek 2012-10-15 09:37:18 EDT
> > sounds like a minor bug
> 
> It is not minor issue since those details are important and cannot retrieved
> easily,  they also don't appear in the events logs.

don't understand.
run time details are in the Vm status tab (the bottom one).
These values should not be presented anywhere else, since it's only "run once" - comment #5.
Or do you have anything else in mind?
Comment 12 Ravi Nori 2012-10-25 09:51:58 EDT
Link : http://gerrit.ovirt.org/#/c/8822/

Commit Hash: bab798835a194b4890f406bc30e72ebcf4ee70f3
Comment 13 Ido Begun 2013-01-08 02:16:13 EST
OK - SF3

Display type now shows the correct value when using 'run once', and default display type is shown after VM powers off, as expected.
Comment 14 Itamar Heim 2013-06-11 05:19:46 EDT
3.2 has been released
Comment 15 Itamar Heim 2013-06-11 05:43:10 EDT
3.2 has been released

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