Description of problem: When changing the CPU profile on a running VM you get notified that the profile only takes effect after a VM restart. After klicking OK the VM gets the symbol assign which indicates that there is a configuration update which did not jet take effect. When checking the VM config again you see that the CPU profile is still the old one. Also a VM restart keeps the old profile. Doing the changes on a VM which is down work as expected. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. Create a second CPU profile 2. Create and start a VM 3. Edit the VM and set the new CPU profile 4. Restart the VM to make the new CPU profile effective 5. The VM still has the old CPU profile Actual results: There is way to edit the CPU profile on a running VM. The change just gets lost. It is not live updated and it is not persisted for later VM starts. Expected results: The CPU profile should be live updated on the running VM and saved to the database. Additional info:
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Should this be modified?
I think this causes this regression: https://bugzilla.redhat.com/show_bug.cgi?id=1361366
on top of that, looking at the patch it doesn't seem to me it's actually fixing the problem completely. profile is live refreshed when the VM is in "Up" status, yet it can be edited in all other states when VM is running(PoweringUp, etc) and such change is going to be ignored for that run
(In reply to Michal Skrivanek from comment #4) > on top of that, looking at the patch it doesn't seem to me it's actually > fixing the problem completely. profile is live refreshed when the VM is in > "Up" status, yet it can be edited in all other states when VM is > running(PoweringUp, etc) and such change is going to be ignored for that run Whenever the VM changes it state to UP, VmsMonitoring is triggering the right VDS event to refresh QoS on the VM.
Verified on rhevm-4.0.2.4-0.1.el7ev.noarch 1) Create two cluster profiles with CPU QoS 10 and 20 2) Attach CPU profile with QoS 10 to VM 3) Start VM 4) Check via virsh VM QoS: <metadata xmlns:ovirt="http://ovirt.org/vm/tune/1.0"> <ovirt:qos xmlns:ovirt="http://ovirt.org/vm/tune/1.0"> <ovirt:vcpuLimit>10</ovirt:vcpuLimit> </ovirt:qos> </metadata> 5) Change VM CPU profile with QoS 20 6) Check via virsh VM QoS: <metadata xmlns:ovirt="http://ovirt.org/vm/tune/1.0"> <ovirt:qos xmlns:ovirt="http://ovirt.org/vm/tune/1.0"> <ovirt:vcpuLimit>20</ovirt:vcpuLimit> </ovirt:qos> </metadata>