David - what happens When you do the same flows in the UI ?

Michael - can you please check the API side ?

(In reply to comment #4)
> Michael - can you please check the API side ?

what to check? we only map to BE entity, and afaiu this is backend issue so it should be the same in all clients.

Created attachment 644650 [details]
engine log

engine log is attached, vdsm log is not relevant as you can reproduce the bug on newly-created VM without actually running it.

(In reply to comment #3)
> David - what happens When you do the same flows in the UI ?
the dialog freezes as I already stated in Description.

I suspect stable device addresses because both monitor addition and native usb addition to the VM means that a PCI device has to be added to the VM.

David

David - I'll need some help with reproducing that. I tried to reproduce it from the UI with the latest build and si24.1 - with no success (it worked)
the dialog doesn't freeze and the usb remains native with 2 monitors ..

Arik,
* API path is 100 % reproducible
* portals do sometimes work for me, too, but more often, they do not:
  * even though General tab says "USB Policy: Native", "Edit VM" 
    dialog says "Disabled"
  * first time I tried now, the page has frozen after I just switched
    USB without even touching of the monitors settings...

Created attachment 654054 [details]
mapping usb configuration from rest api to backend values on update request

My findings are as follow:

usb configuration is represented in the backend by an enum of 3 values: DISABLED\LEGACY\NATIVE, and in the rest api it is represented in the following structure in the xml file:
<usb>
  <enabled>true/false</enabled>
  <policy>legacy</native>
<usb>

When a creation request is received via rest api the mapping between the above representations includes the following logic: if the usb tag is null, map it to DISABLED value in the backend enum.

In the scenario David described above, we get from the rest api an XML in which the display tag is the only tag that is not null (because it contains the monitors), and specifically the usb tag is null. the problem is that in this case we use the same mapping that is being used on creation request (although it's an update request), thus the usb is mapped to DISABLED in the backend enum.

I suggest to define a different mapping for usb configuration on update VM request via rest api, in which null usb tag will be mapped to the existing usb configuration in the backend (no change will be made in the backend). that should fix the bug.

When I started to implement the different mapping for usb configuration on update requests via rest api, I found that there are values which I'm not sure how to map. attachment 654054 [details] contains a table of the proposed mapping - cells that contain '?' are those that I'm not sure about.

Simon - could you please define the desired mapping in those cases?

Targeting 3.2
We will reconsider if we get customer issues reports.

Omer has completed spreadsheet.

Created attachment 658167 [details]
spreadsheet with actions to take on all scenarios

http://gerrit.ovirt.org/#/c/9792/

Andrew - the new mapping for the update vm call says to raise an error if usb configuration with enable=true and no explicit type (legacy/native) is received. I saw that for the create vm call there's a different approach for that case: the usb type is set according to the cluster version (if the version>=3.1 then it is set to native, and to legacy otherwise).
can we use the same logic for the update vm in that case instead of raising an error?

http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=f673ddb66a0fdaaaf8902fe9dacc6d0e55178eb1

*** Bug 891567 has been marked as a duplicate of this bug. ***

OK, sf4, native is kept while changing number of monitors (AP,UP,api).

3.2 has been released

3.2 has been released

3.2 has been released

3.2 has been released

3.2 has been released