Bug 1062615

Summary: utc_diff not updated according to a change in VM settings
Product: [Retired] oVirt Reporter: Markus Stockhausen <mst>
Component: ovirt-engine-webadminAssignee: Martin Betak <mbetak>
Status: CLOSED CURRENTRELEASE QA Contact: Lukas Svaty <lsvaty>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: acathrow, bazulay, bzrh.bobd, danken, ecohen, fromani, fw, gklein, iheim, mbetak, mgoldboi, michal.skrivanek, sbonazzo, ydossow, yeylon
Target Milestone: ---   
Target Release: 3.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: virt
Fixed In Version: ovirt-3.4.0-rc Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-03-31 12:28:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 956741, 1024889    

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:


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