Bug 922609 - Cannot edit description field of running VMs - Need to stop and restart the guest for a new description to be effected.
Summary: Cannot edit description field of running VMs - Need to stop and restart the g...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.1.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 3.3.0
Assignee: Arik
QA Contact: Jiri Belka
URL:
Whiteboard: virt
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-18 04:46 UTC by Anitha Udgiri
Modified: 2018-12-03 18:29 UTC (History)
11 users (show)

Fixed In Version: is3
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-21 17:15:41 UTC
oVirt Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
rhevm logs (3.0 -> 3.1 -> 3.2) (287.13 KB, application/x-tar)
2013-05-09 12:14 UTC, Jiri Belka
no flags Details
TZ sometimes is set, sometimes is not set (1.94 MB, video/ogg)
2013-05-21 08:51 UTC, Jiri Belka
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2014:0038 0 normal SHIPPED_LIVE Important: Red Hat Enterprise Virtualization Manager 3.3.0 update 2014-01-21 22:03:06 UTC
oVirt gerrit 13197 0 None None None Never
oVirt gerrit 13307 0 None None None Never

Description Anitha Udgiri 2013-03-18 04:46:34 UTC
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= ]

Comment 3 Omer Frenkel 2013-03-18 12:54:00 UTC
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

Comment 4 Arik 2013-03-18 16:02:43 UTC
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)

Comment 11 Arik 2013-03-20 11:24:17 UTC
u/s patch: http://gerrit.ovirt.org/#/c/13197/

Comment 14 Arik 2013-03-24 15:12:58 UTC
another u/s patch: http://gerrit.ovirt.org/#/c/13307/

Comment 28 Jiri Belka 2013-05-09 12:12:31 UTC
>> 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'.

Comment 29 Jiri Belka 2013-05-09 12:14:28 UTC
Created attachment 745649 [details]
rhevm logs (3.0 -> 3.1 -> 3.2)

Comment 33 Jiri Belka 2013-05-21 08:51:14 UTC
Created attachment 750893 [details]
TZ sometimes is set, sometimes is not set

Comment 34 Jiri Belka 2013-05-21 08:52:55 UTC
Changing back to ASSIGNED as there are conditions under which one still cannot update description. Agreed by assignee.

Comment 35 Michal Skrivanek 2013-05-21 14:20:08 UTC
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

Comment 38 Michal Skrivanek 2013-06-24 07:28:58 UTC
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

Comment 39 Jiri Belka 2013-06-24 11:04:36 UTC
>- 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">

Comment 40 Jiri Belka 2013-06-25 12:19:27 UTC
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?

Comment 41 Jiri Belka 2013-06-25 13:31:16 UTC
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.

Comment 42 Jiri Belka 2013-08-08 13:35:22 UTC
ok is9, i could update description of vms running since 3.0, tried same steps as in #39.

Comment 46 Charlie 2013-11-28 00:18:14 UTC
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.

Comment 48 errata-xmlrpc 2014-01-21 17:15:41 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.

http://rhn.redhat.com/errata/RHSA-2014-0038.html


Note You need to log in before you can comment on or make changes to this bug.