Description of problem: In New/Edit VM dialog, if some vNICs are added/removed first and then 'Optimized For' drop-down is changed from Desktop to Server (and vice versa), then the vNIC info is reset back to the previous state. Desktop/server VM type has nothing to do with vNIC settings, therefore the UI should not touch this area. Version-Release number of selected component (if applicable): ovirt-engine-3.5.0-0.0.master.20140722232058.git8e1babc.el6.noarch (beta2) How reproducible: 100% Steps to Reproduce: 1. Open New VM dialog. Current state: No vNICs are assigned by defualt. 'Optimized For' has value 'Server' by default. 2. Assign 2 vNICs to the ovirt network. 3. Change 'Optimized For' to 'Desktop'. Actual results: The change of value triggers a dialog refresh and after it all vNIC are gone. Expected results: There are still 2 vNICs assigned, as before the change of 'Optimized For' field. Additional info:
Looks like an issue with general flow in the dialog, I think due to changes related to instance type feature but difficult for me to track.
(In reply to Lior Vernia from comment #1) > Looks like an issue with general flow in the dialog, I think due to changes > related to instance type feature but difficult for me to track. I agree this is a bit more general issue, I found out that also other values in the dialog (like Memory Size, CPUs, etc.) are reset when changing not only the 'Optimized For', but also 'Operating System'. I went through the VM dialog and following VM parameter values are reset: /General/ vNICs /Cosnole/ Protocol USB Support Monitors Single PCI Smartcard Enabled Soundcard enabled VirtIO Console Device Enabled /Host/ Migration Options select Use custom migration /HA/ Highly Available Priority for Run/Migration queue radios Watchdog Model Watchdog Action /Resource Allocation/ Physical Memory Guaranteed Memory Balloon Device Enabled VirtIO-SCSI Enabled /Boot Options/ First Device Second Device
*** Bug 1133576 has been marked as a duplicate of this bug. ***
*** Bug 1056977 has been marked as a duplicate of this bug. ***
verified in vt3
oVirt 3.5 has been released and should include the fix for this issue.