Description of problem: Can't edit anything while a VM is running. This includes trivial fields such as "Description". The error received is: Failed updating the properties of the VM. This may be caused either by: 1. The values selected are not appropriate for the VM; or 2. Its values cannot be updated while the VM is in UP state (Please shut down the VM in order to modify properties such as CPU or cluster) Log contents : 2013-03-05 17:46:31,366 INFO [org.ovirt.engine.core.bll.UpdateVmCommand] (http-/0.0.0.0:8443-1) [3958fdc5] Lock Acquired to object EngineLock [exclusiveLocks= key: csa2 value: VM_NAME, sharedLocks= ] 2013-03-05 17:46:31,366 WARN [org.ovirt.engine.core.compat.backendcompat.PropertyInfo] (http-/0.0.0.0:8443-1) Unable to get value of property: isQuotaDefault for class org.ovirt.engine.core.common.businessentities.VmStatic 2013-03-05 17:46:31,366 WARN [org.ovirt.engine.core.compat.backendcompat.PropertyInfo] (http-/0.0.0.0:8443-1) Unable to get value of property: isQuotaDefault for class org.ovirt.engine.core.common.businessentities.VmStatic 2013-03-05 17:46:31,366 WARN [org.ovirt.engine.core.compat.backendcompat.PropertyInfo] (http-/0.0.0.0:8443-1) Unable to get value of property: managedDeviceMap for class org.ovirt.engine.core.common.businessentities.VmStatic 2013-03-05 17:46:31,366 WARN [org.ovirt.engine.core.compat.backendcompat.PropertyInfo] (http-/0.0.0.0:8443-1) Unable to get value of property: managedDeviceMap for class org.ovirt.engine.core.common.businessentities.VmStatic [He is NOT updating cpu_per_socket, he's updating Description] 2013-03-05 17:46:31,366 ERROR [org.ovirt.engine.core.utils.ObjectIdentityChecker] (http-/0.0.0.0:8443-1) [3958fdc5] Field cpu_per_socket can not be updated when status is Up 2013-03-05 17:46:31,366 WARN [org.ovirt.engine.core.utils.ObjectIdentityChecker] (http-/0.0.0.0:8443-1) [3958fdc5] ObjectIdentityChecker.IsUpdateValid:: Not updatable field 'cpu_per_socket' was updated 2013-03-05 17:46:31,366 WARN [org.ovirt.engine.core.bll.UpdateVmCommand] (http-/0.0.0.0:8443-1) [3958fdc5] CanDoAction of action UpdateVm failed. Reasons:VAR__ACTION__UPDATE,VAR__TYPE__VM,VM_CANNOT_UPDATE_ILLEGAL_FIELD 2013-03-05 17:46:31,367 INFO [org.ovirt.engine.core.bll.UpdateVmCommand] (http-/0.0.0.0:8443-1) [3958fdc5] Lock freed to object EngineLock [exclusiveLocks= key: csa2 value: VM_NAME, sharedLocks= ]
problem here is that for some reason 'cpu_per_socket' field is identified as changed, and its not allowed to be changed for a running vm. need to check if UI send different value or some bug in the backend
I didn't manage to reproduce it neither on the upstream nor 3.2 downstream Anitha, can you please provide more information: 1. whether it is 100% reproducible for all VMs or only for specific ones 2. if you have access to the environment in which it reproduces, can you check what is the value of cpu_per_socket field in the DB and what appears in the UI (in the DB it's a field of vm_static table)
u/s patch: http://gerrit.ovirt.org/#/c/13197/
another u/s patch: http://gerrit.ovirt.org/#/c/13307/
>> when i create new vm on a rhevm which was upgraded from 3.0 to 3.1, the >> timezone is automatically selected = it has a value. >what timezone was shown back in 3.0? it is not possible to create a windows vm without timezone set in 3.0! so VMs without timezone set were modified directly in the DB. * 3.0 query rhevm=# select vm_name,description,os,time_zone from vm_static where vm_name like 'w2k3-0%' order by vm_name; vm_name | description | os | time_zone ---------+-----------------------------+----+------------------- w2k3-01 | running since 3.0, TZ set | 3 | GMT Standard Time w2k3-02 | running since 3.0, TZ unset | 3 | w2k3-03 | started on 3.2, TZ set | 3 | GMT Standard Time w2k3-04 | started on 3.2, TZ unset | 3 | (4 rows) * checking in admin portal after upgrade 3.0 -> 3.1 -> 3.2 (sf15): - w2k3-01 (running) has set timezone in Admin Portal, changing description was OK, after saving it is visible 'GMT Standard Time' - w2k3-02 (running) has empty timezone in Admin Portal, changing description was OK, after saving it is still empty - w2k3-03 has empty timezone, started, tried modify description and got 'Error while executing action' popup new try, now timezone is not empty but 'GMT Standard Time' greyed, changing description worked now - w2k3-04 has empty timezone, started, tried modify description and it was successful * 3.2 post edit query engine=# select vm_name,description,os,time_zone from vm_static where vm_name like 'w2k3-0%' order by vm_name; vm_name | description | os | time_zone ---------+-------------------------------+----+------------------- w2k3-01 | X running since 3.0, TZ set | 3 | GMT Standard Time w2k3-02 | X running since 3.0, TZ unset | 3 | w2k3-03 | X started on 3.2, TZ set | 3 | GMT Standard Time w2k3-04 | X started on 3.2, TZ unset | 3 | (4 rows) >> i had a VM running on 3.0, then I upgrade rhevm to 3.1 (the VM was still >> running), after upgrade I could not update description of this running VM. >> when i stopped the vm, started it again, i could modify description. is this >> behaviour ok? >no, I don't see a reason why it shouldn't be possible to modify the >description without restart the VM, but it might be another bug. can you say >what was the error and attach an engine log? I was using wrong version of rhevm, now in 3.2 (sf15) please see above behaviour for 'w2k3-03'.
Created attachment 745649 [details] rhevm logs (3.0 -> 3.1 -> 3.2)
Created attachment 750893 [details] TZ sometimes is set, sometimes is not set
Changing back to ASSIGNED as there are conditions under which one still cannot update description. Agreed by assignee.
seems it was happening on 3.1 VM only. Tried again with reported on latest 3.2 setup on 3.2 VMs and didn't reproduce it. putting 3.2.z until we manage to reproduce it
jiri, can you please try again? There were some patches refactoring the TZ code and it may work now:) Otherwise we have no clue why and how it was happening. Actually even in 3.2.1 it may work now despite the target release of this bug
>- w2k3-03 has empty timezone, started, tried modify description and got 'Error > while executing action' popup > new try, now timezone is not empty but 'GMT Standard Time' greyed, > changing description worked now I cannot reproduce this behaviour in sf17.6. So this kind of issue seems to be corrected. Here is full description of steps I did: 01 - (running since 3.0) TZ grey, list does not work, closing dialog, TZ is gray and GMT Standard Time, changing description, OK button reopening vm dialog, TZ is grey, no value visible, clicking OK button shows: ~~~ Error while executing action: w2k3-01: Failed updating the properties of the VM. This may be caused either by: 1. The values selected are not appropriate for the VM; or 2. Its values cannot be updated while the VM is in UP state (Please shut down the VM in order to modify properties such as CPU or cluster). ~~~ reopening again vm dialog, TZ is grey and set to GMT Standard Time, OK button, successful closing /* so again it is based on the fact, that TZ value is sometimes loaded and sometimes now */ 02 - (running since 3.0) TZ grey, closing dialog, TZ still gray, updating description works all the time OK 03 - TZ set to GMT Standart Time, update of description works ok after started, TZ is gray and set to GMT Standart Time, updating of description works OK 04 - TZ while, list available, TZ not set, chaning description works oK started, TZ gray, list not available, TZ unset, changing description works OK And info about TZ set for running qemu-kvm instances: # ps ax | grep '[q]emu-kvm' | sed 's/ /\n/g;' | egrep "^w2k|^base" w2k3-04 base=2013-06-24T06:46:12,driftfix=slew w2k3-03 base=2013-06-24T11:24:44,driftfix=slew w2k3-01 base=2013-06-24T08:40:40,driftfix=slew w2k3-02 base=2013-06-24T08:40:40,driftfix=slew See w2k3-04 (it had manually removed TZ from vm_static). # egrep "<name>|adjustment" /var/log/vdsm/vdsm.log <name>w2k3-03</name> <clock adjustment="3600" offset="variable"> <name>w2k3-04</name> <clock adjustment="-14400" offset="variable">
Now tested with sf18.1 (recommended by mskrivanek@). Be aware that w2k3-02 and w2k3-04 had manually set TZ in the database to NULL. ~~~ 01 - TZ white - GMT Standart Time, list available, changing TZ and clicking OK makes following error (cannot be change while running): Error while executing action: w2k3-01: Failed updating the properties of the VM. This may be caused either by: 1. The values selected are not appropriate for the VM; or 2. Its values cannot be updated while the VM is in UP state (Please shut down the VM in order to modify properties such as CPU or cluster). ? should TZ be in white when it is running? changing description works OK, TZ is always loaded and visible as described above 02 - TZ is white and set to 'default: (GMT) GMT Standard Time, clicking OK button (description cannot be updated) causes following error: Error while executing action: w2k3-02: Failed updating the properties of the VM. This may be caused either by: 1. The values selected are not appropriate for the VM; or 2. Its values cannot be updated while the VM is in UP state (Please shut down the VM in order to modify properties such as CPU or cluster). !but be aware TZ value was manually set to NULL in the DB! 03 - TZ white and set to GMT Standard Time, list available, changing description ok but changing TZ is not supported Error while executing action: w2k3-03: Failed updating the properties of the VM. This may be caused either by: 1. The values selected are not appropriate for the VM; or 2. Its values cannot be updated while the VM is in UP state (Please shut down the VM in order to modify properties such as CPU or cluster). 04 - TZ white and set to 'default: (GMT) Standard Time', no updates of VM properties allowed Error while executing action: w2k3-04: Failed updating the properties of the VM. This may be caused either by: 1. The values selected are not appropriate for the VM; or 2. Its values cannot be updated while the VM is in UP state (Please shut down the VM in order to modify properties such as CPU or cluster). ~~ # ps ax | grep '[q]emu-kvm' | sed 's/ /\n/g;' | egrep "^w2k|^base" w2k3-01 base=2013-06-25T10:49:13,driftfix=slew w2k3-02 base=2013-06-25T10:49:13,driftfix=slew w2k3-03 base=2013-06-25T13:01:27,driftfix=slew w2k3-04 base=2013-06-25T13:01:43,driftfix=slew [root@slot-8 ~]# egrep "<name>|adjustment" /var/log/vdsm/vdsm.log <name>w2k3-01</name> <clock adjustment="0" offset="variable"> <name>w2k3-02</name> <clock adjustment="0" offset="variable"> <name>w2k3-03</name> <clock adjustment="3600" offset="variable"> <name>w2k3-04</name> <clock adjustment="3600" offset="variable"> Summary: * TZ is set correctly for qemu-kvm instances. If TZ value is NULL it would be set to default (GMT Standard Time). This is difference from sf17.6, see #39. * Now UI loads TZ and displays it 'white'. If TZ is NULL it displays 'default: (GMT) Standard Time'. But now then NULL is replaces with 'default', this prevents any changes of VM properties. * TZ is now always white, TZ list is available, but TZ change cannot be done when the VM is running. Shouldn't this be gray then?
The overriding default TZ value (when a VM has TZ value not set in the DB) should not prevent update of VM properties. When such VM is stopped, VM properties can be updated. I also tried to compare various TZ values in UI: * TZ value empty - automatically set to GMT, VM properties cannot be updated * TZ value set to 'foobar' - set to 'default:null' when down (BZ974985), after started, TZ value is empty and VM properties cannot be updated * TZ value empty and DefaultWindowsTimeZone=foobar - set to 'default:null' when down, after started, TZ value is still 'default:null' and VM properties _can_ be updated * TZ value set to 'foobar' and DefaultWindowsTimeZone=foobar - TZ value 'empty' when down, TZ still 'empty' when up and VM properties cannot be updated * TZ value empty and DefaultWindowsTimeZone="Samoa Standard Time" - TZ value 'default:null' when down, TZ value has 'default:null' when up, VM properties _can_ be updated. qemu-kvm proces it set to GMT. Also it is usual that values which cannot be changed when a VM is running are displayed in gray text boxes (like 'Total Virtual CPUs'), in sf18.1 TZ value has always white colour and TZ list is available, this could be seen as confusing.
ok is9, i could update description of vms running since 3.0, tried same steps as in #39.
This bug is currently attached to errata RHEA-2013:15231. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag. Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information: * Cause: What actions or circumstances cause this bug to present. * Consequence: What happens when the bug presents. * Fix: What was done to fix the bug. * Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore') Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug. For further details on the Cause, Consequence, Fix, Result format please refer to: https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes Thanks in advance.
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. http://rhn.redhat.com/errata/RHSA-2014-0038.html