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
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...?
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
workaround is to clean up the field in the db while the VM is down
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?
Nevertheless I hope to see a bugfix. Until then I will modify the database when required.
(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
This bug is blocking 3.4.0 final release. ETA for fixing it?
does it deserve a 3.3.z backport, is it broken in 3.3 as well (since osinfo has been introduced there)
Merged u/s as 89830d623e7d27b43306495c1c0d1a61d6afcf1f. Backport to 3.4 on the way.
This BZ should be fixed in oVirt 3.4.0 RC
verified in av3
this is an automated message: moving to Closed CURRENT RELEASE since oVirt 3.4.0 has been released