|Summary:||PRD35 - [RFE] Allow to edit VM properties that need VM to be down to apply, just mark it as such and apply on VM shutdown|
|Product:||Red Hat Enterprise Virtualization Manager||Reporter:||David Jaša <djasa>|
|Component:||ovirt-engine||Assignee:||Omer Frenkel <ofrenkel>|
|Status:||CLOSED ERRATA||QA Contact:||Ilanit Stein <istein>|
|Version:||3.2.0||CC:||asegundo, bsettle, gklein, iheim, lbopf, lpeer, mavital, michal.skrivanek, ofrenkel, pbandark, pdwyer, perobins, pstehlik, rbalakri, Rhev-m-bugs, sbonazzo, sherold, yeylon|
|Target Milestone:||---||Keywords:||FutureFeature, Triaged|
|Fixed In Version:||3.5 beta2||Doc Type:||Enhancement|
Previously, only certain virtual machine properties could be updated while the virtual machine was running. Other properties could only be updated while the virtual machine was down. Now, all properties can be updated on a running virtual machine, but those that cannot be applied immediately will be saved and applied the next time the virtual machine is shut down.
|:||1072313 (view as bug list)||Environment:|
|Last Closed:||2015-02-11 17:52:36 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||1072313|
|Bug Blocks:||1022041, 1047522, 1142923, 1156165|
Description David Jaša 2013-03-16 14:11:35 UTC
Description of problem: It's quite inconvenient not to be able to edit all VM properties anytime. The old way of being to able to edit the VM properties anytime and applying some of them on VM shutdown is the best behaviour from administrator POV. The only thing that may be missing is a note to user (admin) that the changes will be applied later. Version-Release number of selected component (if applicable): sf10 / rhevm-backend-3.2.0-10.14.beta1.el6ev.noarch How reproducible: always Steps to Reproduce: 1. run a VM 2. change number of monitors of a VM while running 3. Actual results: "operation failed" error due to VM running Expected results: update the VM properties in the database and the next time the VM is run, use them Additional info:
Comment 1 David Jaša 2013-03-16 14:13:17 UTC
This bug is distinct from bug 858610 because that bug handles properties that do not require VM being down in order to apply.
Comment 2 Libor Spevak 2013-04-16 09:15:59 UTC
Can you confirm, Yair, please, have you been thinking about a way, how to save VM configuration parameters even if the VM is running? (e.g. as virt-manager application does) My proposal is: 1. Identify parameters which can be saved (e.g. to vm_static table) when the VM is running and other parameters, which are valid after shutdown only - number of monitors, ... 2. Create new table VM_STATIC_UPDATE acting as queue for changes, for parameters, which will be valid after VM shutdown 3. Enable to save VM parameters, but if there are changed parameters, which are valid when the VM is not running, show warning only about it. 3. After the VM is identified as DOWN (or other not running status), e.g. in method: VdsUpdateRunTimeInfo.proceedDownVms() 4. move new values from vm_static_update -> vm_static (generally, this supports more updates to VM and the change is persistent, only preference of changes must be taken into mind)
Comment 4 Michal Skrivanek 2013-06-13 07:28:32 UTC
should be an enhancement on top on Instance Types feature which won't fully make it for 3.3
Comment 5 Omer Frenkel 2013-06-19 14:00:34 UTC
some more details on what is planned, no patches available yet: when vm is run, new snapshot will be taken, for configutation only, this will be special "running snapshot". when vm is edited while running, changes will be saved to the snapshot. this way when frontend get a vm object from db, it always reflect the 'real' state of the vm. (general subtab of vm in ui, for example). when vm goes down, all information from the snapshot will be saved to the vm table, to be used on next run. the "next run configuration" will be available when querying the snapshot, as querying any other snapshot.
Comment 7 Scott Herold 2014-01-14 21:01:41 UTC
*** Bug 838477 has been marked as a duplicate of this bug. ***
Comment 8 Michal Skrivanek 2014-01-31 12:14:15 UTC
*** Bug 1031624 has been marked as a duplicate of this bug. ***
Comment 10 Michal Skrivanek 2014-02-28 10:00:15 UTC
*** Bug 1067513 has been marked as a duplicate of this bug. ***
Comment 11 Michal Skrivanek 2014-03-04 11:12:31 UTC
*** Bug 971967 has been marked as a duplicate of this bug. ***
Comment 13 Ilanit Stein 2014-08-11 13:47:29 UTC
I've tested this RFE: https://tcms.engineering.redhat.com/run/163767/?from_plan=14398#caserun_6503662 These bugs were opened, but none of them is critical: bug 1128433, 1128435, 1128436, 1128437, 1128442, 1128443, 1128444, 1128446, 1128453, 1128456.
Comment 14 Ilanit Stein 2014-10-27 07:42:21 UTC
Verified on vt5 & vt6. The feature work, but still we have some minor open issues (bug listed at comment #13).
Comment 16 errata-xmlrpc 2015-02-11 17:52:36 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0158.html