Michal: yes it should be grayed out but this change 7bf5df627c1748b8851b5cc48c62e44b5cf49f17 incorrectly greys it "if and only if the VM is linux" so a running windows VM has this listbox enabled (white).

*** Bug 996183 has been marked as a duplicate of this bug. ***

*** Bug 974985 has been marked as a duplicate of this bug. ***

*** Bug 1000853 has been marked as a duplicate of this bug. ***

*** Bug 1002616 has been marked as a duplicate of this bug. ***

Since bug 1002616 has been closed as a duplicate of this bug please take into account that Windows domain should not be populated in the database when importing Linux VMs exported from RHEV 2.2, please see bug 1002616 for more details.

Imported a VM from 3.2 env. DB on 3.3 (is17) shows:

select vm_name,time_zone from vm_static where vm_name ilike '%test-tz%' and time_zone is not NULL;
 vm_name | time_zone 
---------+-----------
 test-tz | 
(1 row)

After starting this imported VM while clicking on 'OK' button in VM properties:

-%-
Error while executing action:

test-tz:

    There was an attempt to change VM values while the VM is not down. Please shut down the VM in order to modify these properties.
-%-

2013-10-02 14:19:21,942 ERROR [org.ovirt.engine.core.utils.ObjectIdentityChecker] (ajp-/127.0.0.1:8702-21) Field timeZone can not be updated when status is Up
2013-10-02 14:19:21,942 WARN  [org.ovirt.engine.core.utils.ObjectIdentityChecker] (ajp-/127.0.0.1:8702-21) ObjectIdentityChecker.IsUpdateValid:: Not updatable field 'timeZone' was updated

mbetak@ said that import should replace empty string in 'time_zone' with NULL as well.

Verified in rhevm-3.2.4-0.44.el6ev.noarch (sf21).

Verification steps:
1) In older RHEVM 3.2 (3.2.0 aka sf17.5 in this case) create new VM with Windows OS type.
2) In DB, simulate the old behavior via seting the time_zone to empty string :
{{{
# psql -U engine engine
engine=> \pset null <NULL>
engine=> UPDATE vm_static SET time_zone = '' where vm_name = 'my-win7-sf17_5';
UPDATE 1
engine=> SELECT vm_guid, vm_name, time_zone from vm_static;
               vm_guid                |    vm_name     | time_zone 
--------------------------------------+----------------+-----------
 00000000-0000-0000-0000-000000000000 | Blank          | <NULL>
 993f9143-1a45-4f69-a739-34be9f62f049 | my-win7        | 
}}}
3) Run the VM in webadmin and try to edit for example the description -> you should get an error pop-up. Stop the VM.
4) Upgrade to RHEVM 3.2.4 (sf21)
5) Repeat step 3 -> now it should be possible to change the description.
6) Check the time_zone value in DB:
{{{
# psql -U engine engine
engine=> \pset null <NULL>
engine=> SELECT vm_guid, vm_name, time_zone from vm_static;
               vm_guid                |    vm_name     | time_zone 
--------------------------------------+----------------+-----------
 00000000-0000-0000-0000-000000000000 | Blank          | <NULL>
 993f9143-1a45-4f69-a739-34be9f62f049 | my-win7        | <NULL>
}}}

(In reply to Pavel Novotny from comment #15)
> Verified in rhevm-3.2.4-0.44.el6ev.noarch (sf21).
> 
> Verification steps:
> 1) In older RHEVM 3.2 (3.2.0 aka sf17.5 in this case) create new VM with
> Windows OS type.
> 2) In DB, simulate the old behavior via seting the time_zone to empty string
> :
> {{{
> # psql -U engine engine
> engine=> \pset null <NULL>
> engine=> UPDATE vm_static SET time_zone = '' where vm_name =
> 'my-win7-sf17_5';
> UPDATE 1
> engine=> SELECT vm_guid, vm_name, time_zone from vm_static;
>                vm_guid                |    vm_name     | time_zone 
> --------------------------------------+----------------+-----------
>  00000000-0000-0000-0000-000000000000 | Blank          | <NULL>
>  993f9143-1a45-4f69-a739-34be9f62f049 | my-win7        | 
> }}}
> 3) Run the VM in webadmin and try to edit for example the description -> you
> should get an error pop-up. Stop the VM.
> 4) Upgrade to RHEVM 3.2.4 (sf21)
> 5) Repeat step 3 -> now it should be possible to change the description.
> 6) Check the time_zone value in DB:
> {{{
> # psql -U engine engine
> engine=> \pset null <NULL>
> engine=> SELECT vm_guid, vm_name, time_zone from vm_static;
>                vm_guid                |    vm_name     | time_zone 
> --------------------------------------+----------------+-----------
>  00000000-0000-0000-0000-000000000000 | Blank          | <NULL>
>  993f9143-1a45-4f69-a739-34be9f62f049 | my-win7        | <NULL>
> }}}


Replied to wrong BZ, ^^^ this belongs to bug 1000034. Moving back to ON_QA.

FailedQA in rhevm-3.3.0-0.25.beta1.el6ev.noarch (is18).

The SQL upgrade script that handles the time zone fileld coversion to null is present but it's not executed during the RHEVM upgrade process:
{{{
# cat /usr/share/ovirt-engine/dbscripts/upgrade/03_03_0780_convert_empty_timezone_to_null.sql
-- update VMs from old engine version that used
-- empty string to represent 'default' time_zome
update vm_static
set time_zone = NULL
where time_zone = '';
# egrep -i 'set\s*time_zone'  /var/log/ovirt-engine/setup/ovirt-engine-setup-20131021151317.log || echo "nothing"
nothing
}}}

After update from is17 to is18 the VM's time_zone value is still an empty string:
{{{
# psql -U engine engine
engine=> \pset null <NULL>
Null display is "<NULL>".
engine=> SELECT vm_guid, vm_name, time_zone from vm_static order by 2;
               vm_guid                | vm_name  | time_zone 
--------------------------------------+----------+-----------
 00000000-0000-0000-0000-000000000000 | Blank    | <NULL>
 419407cd-a466-4199-a8ae-e04f1676990f | no_tz-vm | 
(2 rows)
}}}

Correction - after discussion with @mbetak, the SQL upgrade script is executed only during RHEVM update from older version than 3.3 (i.e., 3.2.x, 3.1, ...) to 3.3 version. 
Therefore the verification process in comment 17 is irrelevant as there were used two testing builds, both RHEVM 3.3.0.

Moving back to ON_QA.

Verified in rhevm-3.3.0-0.27.beta1.el6ev.noarch (is19).

Verification steps:
1) In RHEVM 3.2 (3.2.0 aka sf17.5 in this case) create new VM with Windows OS type.
2) In DB, simulate the old behavior via seting the time_zone to empty string :
{{{
# psql -U engine engine
engine=> \pset null <NULL>
engine=> UPDATE vm_static SET time_zone = '' where vm_name = 'my-vm';
UPDATE 1
engine=> SELECT vm_guid, vm_name, time_zone from vm_static;
               vm_guid                |    vm_name     | time_zone 
--------------------------------------+----------------+-----------
 00000000-0000-0000-0000-000000000000 | Blank          | <NULL>
 46bcdafc-8b44-4082-afbb-6ac9aaa5a48d | my-vm          | 
}}}
3) Upgrade to RHEVM 3.3 (is19)
4) Check the time_zone value in DB:
{{{
# psql -U engine engine
engine=> \pset null <NULL>
engine=> SELECT vm_guid, vm_name, time_zone from vm_static;
               vm_guid                |    vm_name     | time_zone 
--------------------------------------+----------------+-----------
 00000000-0000-0000-0000-000000000000 | Blank          | <NULL>
 46bcdafc-8b44-4082-afbb-6ac9aaa5a48d | my-vm          | <NULL>
}}}

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