Bug 1062615 - utc_diff not updated according to a change in VM settings
Summary: utc_diff not updated according to a change in VM settings
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-webadmin
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.4.0
Assignee: Martin Betak
QA Contact: Lukas Svaty
URL:
Whiteboard: virt
Depends On:
Blocks: 956741 1024889
TreeView+ depends on / blocked
 
Reported: 2014-02-07 13:44 UTC by Markus Stockhausen
Modified: 2014-03-31 12:28 UTC (History)
15 users (show)

Fixed In Version: ovirt-3.4.0-rc
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-03-31 12:28:39 UTC
oVirt Team: ---


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 24403 0 None MERGED engine: Correct utc_diff handling Never
oVirt gerrit 25062 0 None MERGED engine: Correct utc_diff handling Never

Description Markus Stockhausen 2014-02-07 13:44:26 UTC
Description of problem:

Changing the timezone in a windows 7 VM does not update the utc_diff data in the ovirt database.

Version-Release number of selected component (if applicable):

Ovirt 3.3.2 EL6
Fedora 19 hypervisor node

How reproducible:

100%

Steps to Reproduce:
1. Power off Windows 7 VM
2. Check utc_diff value in database:

select a.vm_name,b.utc_diff,a.vm_guid from vm_static a, vm_dynamic b where a.vm_guid=b.vm_guid;

     vm_name      | utc_diff |               vm_guid
------------------+----------+--------------------------------------
 Win7x64_Master   |        0 | ce64f528-9981-4ec6-a172-9d70a00a34cd

3. Start VM

4. Check VDSM start log:

Thread-9324::DEBUG::2014-02-07 14:14:20,084::BindingXMLRPC::981::vds::(wrapper) 
return vmCreate with {'status': {'message': 'Done', 'code': 0}, 'vmList': {'status': 
'WaitForLaunch', 'acpiEnable': 'true', 'emulatedMachine': 'pc-1.0', 'vmId': 
'ce64f528-9981-4ec6-a172-9d70a00a34cd', 'pid': '0', 'memGuaranteedSize': 2048, 
'timeOffset': '0', 'keyboardLayout': 'de', 'displayPort': '-1', ...

5. Change timezone in VM.

6. Check RTC events in VDSM.log

libvirtEventLoop::DEBUG::2014-02-07 14:30:21,955::vm::2276::vm.Vm::(_rtcUpdate) vmId=`ce64f528-9981-4ec6-a172-9d70a00a34cd`::new rtc offset 3501


7. Check time difference with vdsClient

[root@colovn04 vdsm]# vdsClient -s 0 getAllVmStats | grep -i time
        timeOffset = 3501

8. shutdown VM

9. Check utc_diff value in database:

select a.vm_name,b.utc_diff,a.vm_guid from vm_static a, vm_dynamic b where a.vm_guid=b.vm_guid;

     vm_name      | utc_diff |               vm_guid
------------------+----------+--------------------------------------
 Win7x64_Master   |        0 | ce64f528-9981-4ec6-a172-9d70a00a34cd


Actual results:

time_diff is still 0

Expected results:

time_diff should be 3501

Comment 1 Markus Stockhausen 2014-02-07 15:17:08 UTC
Memo for myself: VDSM correctly reports timeOffset after machine shutdown through vdsm/vm.py:

        if self.lastStatus == 'Down':
            stats = {}
            stats['exitCode'] = self.conf['exitCode']
            stats['status'] = self.lastStatus
            stats['exitMessage'] = self.conf['exitMessage']
            if 'timeOffset' in self.conf:
                stats['timeOffset'] = self.conf['timeOffset']
            return stats

log shows:

return vmGetStats with {'status': {'message': 'Done', 'code': 0}, 'statsList': [{'status': 'Down', 'hash': '653642269994103461', 'exitMessage': 'User shut down', 'vmId': 'ce64f528-9981-4ec6-a172-9d70a00a34cd', 'timeOffset': '3501', 'exitCode': 0}]}

engine does not evaluate the field...?

Comment 2 Michal Skrivanek 2014-02-12 15:32:56 UTC
the bug was introduced during osinfo implementation. 
The updates from VDSM are not reflected in the VmDynamic field, but that's actually not important for the bug behavior. The field is supposed to be overwritten/generated from the timezone selection(offset) in General tab in Edit VM dialog. On each run the right offset should be calculated…the updates from VDSM are not relevant for the start, only to observe(and eventually display) while the VM is running and the time is changed(or drifted away) inside the guest. But this information is not exposed ATM, it's just an internal db field

Comment 3 Michal Skrivanek 2014-02-12 15:47:12 UTC
workaround is to clean up the field in the db while the VM is down

Comment 4 Markus Stockhausen 2014-02-12 15:56:52 UTC
Maybe there is some kind of misunderstanding.

The page where I can set the timezone calls itself "inital run". So to say settings that are applied when the machine starts the first time. Subsequent starts will not get them.

The desired behaviour from your description is something like "startup". parameters that are set with each boot. 

Maybe because of this I anticipated it should go the other way round. Should i file an aditional bug/rfe to rename that page?

Comment 5 Markus Stockhausen 2014-02-12 15:58:57 UTC
Nevertheless I hope to see a bugfix. Until then I will modify the database when required.

Comment 6 Michal Skrivanek 2014-02-14 13:56:37 UTC
(In reply to Markus Stockhausen from comment #4)

regardless the bugfix which is on the way -

there are 2 timezone fields: 
one in System tab in the New VM dialog - this is for each run, should be changeable for Windows guests and UTC for Linux
another under Initial Run, in vminit(sysprep/cloud-init) section, which is for initialization of the VM for the first time. Supposed to be used only once and then not changeable

Comment 7 Sandro Bonazzola 2014-02-24 08:20:20 UTC
This bug is blocking 3.4.0 final release. ETA for fixing it?

Comment 8 Michal Skrivanek 2014-02-24 14:52:37 UTC
does it deserve a 3.3.z backport, is it broken in 3.3 as well (since osinfo has been introduced there)

Comment 9 Martin Betak 2014-02-26 10:22:50 UTC
Merged u/s as 89830d623e7d27b43306495c1c0d1a61d6afcf1f. Backport to 3.4 on the way.

Comment 10 Sandro Bonazzola 2014-03-03 14:40:05 UTC
This BZ should be fixed in oVirt 3.4.0 RC

Comment 11 Lukas Svaty 2014-03-18 19:35:51 UTC
verified in av3

Comment 12 Sandro Bonazzola 2014-03-31 12:28:39 UTC
this is an automated message: moving to Closed CURRENT RELEASE since oVirt 3.4.0 has been released


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