Univention Bugzilla – Bug 22033
Bei der Installation von Windows geht die immer 2h nach
Last modified: 2011-09-14 10:57:01 CEST
Während der Installation von Windows System wird auch die Zeitzone und die Uhrzeit abgefragt, dort geht die Uhr immer 2h nach. Auf dem Virt-Host (ucs2.4-2 KVM) ist die Zeit ok.
KVM stellt der Domain eine R(eal)-T(ime)-C(lock) zur Verfügung, die in UTC läuft. Windows allerdings geht davon aus, daß diese in der lokalen Zeitzone läuft, was bei der derzeitigen Sommerzeit (MEST) den Unterschied von 2 Stunden erklärt. Diese Einstellung kann geändert werden, siehe <http://libvirt.org/formatdomain.html#elementsTime>. Für Windows ist 'variable' vermutlich die beste Lösung, denn dann kann Windows damit machen, was es will.
Das ist doch etwas unschön, da die Uhrzeit jedes mal beim Starten der Instanz falsch ist (also eine/zwei Stunden nach geht).
Ein Test ergab, das "variable" nicht ganz so wie beschrieben funktioniert und eine von Hand gemachte Änderung in der Gast-VM den Reboot nicht überstehen. Von daher sollte am besten für Windows offset='localtime', und für Linux offset='utc' generiert werden. Bis zu einer Anpassung in UVMM kann das per "virsh edit" selber geändert werden und sollte danke Bug #20253 auch bei weiteren Änderungen per UVMM bestehen bleiben.
In den Profilen wird nun zusätzlich gespeichert, ob die RTC der virtualisierten Instanz auf die UTC- oder lokale Zeitzone gesetzt werden soll. UDM-Modul wurde entsprechend angepasst. Die Profile wurden aktualisiert: Windows verwendet "localtime", UCS "utc". UVMM-UMC Modul wurde in den erweiterten Einstellungen entsprechend ergänzt. Neue Instanzen werden den neuen Vorgaben entsprechend angelegt. Änderungen über UMC sind möglich und laden in dem XML-Beschreibung. Änderungen per "virsh edit" werden von UMC honoriert. svn23656 univention-virtual-machine-manager-schema_1.0.31-1.31.201104211119_ (2.4-3) univention-virtual-machine-manager-daemon_0.9.305-1.235.201104211120 (2.4-3) ChangeLog: \item Für Instanzen kann nun konfiguriert werden, ob die Realzeituhr in der lokalen Zeitzone oder in UTC läuft (\ucsBug{22033}). Für die QA: Die RTC kann in Linux per "hwclock --show" ausgelesen werden. Per "--localtime" bzw. "--utc" kann zusätzlich angegeben werden, in welcher Zeitzone die RTC läuft, damit bei der Anzeige diese Angabe dann richtig in die lokale Zeitzone umgerechnet werden kann.
Beim Upgrade trat noch das Problem auf, daß für den Zugriff auf das rtcoffset-Attribut eine neuere Version von univention-virtual-machine-manager-schema benötigt wird, die das Attribut in UDM verfügbar macht: Die Ausführung des Kommandos 'uvmm/domain/create' ist fehlgeschlagen: Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/univention/management/console/handlers/__init__.py", line 160, in execute func( object ) File "/usr/lib/python2.4/site-packages/univention/management/console/handlers/uvmm/__init__.py", line 1291, in uvmm_domain_create result = self.domain_wizard.action( object, ( node_uri, node_info ) ) File "/usr/lib/python2.4/site-packages/univention/management/console/handlers/uvmm/wizards.py", line 588, in action return umcd.IWizard.action( self, object ) File "/usr/lib/python2.4/site-packages/univention/management/console/dialog/wizard.py", line 199, in action return self.actions[ action ]( object ) File "/usr/lib/python2.4/site-packages/univention/management/console/handlers/uvmm/wizards.py", line 673, in next object.options['rtc_offset'] = self.profile['rtcoffset'] File "/usr/lib/python2.4/site-packages/univention/admin/handlers/__init__.py", line 259, in __getitem__ elif not key in self.__no_default and self.descriptions[key].editable: KeyError: 'rtcoffset' Hier waren die Abhängigkeiten zu schwach: Alt: u-v-m-m-d → u-v-m-m-schema (1.0.25) → p-u-d-m-uvmm Neu: u-v-m-m-d → u-v-m-m-schema (1.0.32-1) → p-u-d-m-uvmm (= ${s:V}) svn26089, svn26091, univention-virtual-machine-manager-daemon_0.9.319-2.254.201108151132 svn26090, univention-virtual-machine-manager-schema_1.0.32-1.35.201108151129 ChangeLog: keine weitere Änderung
Es scheinen für die XEN Profile "UCS 2.4" und "UCS 2.4 (64 Bit)" die Vorgabe für univentionVirtualMachineProfileRTCOffset zu fehlen. -> ldapsearch -x -b "cn=Profiles,cn=Virtual Machine Manager,dc=test,dc=qa" \ univentionVirtualMachineProfileRTCOffset cn ... # UCS 2.4, xen, Profiles, Virtual Machine Manager, test.qa dn: cn=UCS 2.4,cn=xen,cn=Profiles,cn=Virtual Machine Manager,dc=test,dc=qa cn: UCS 2.4 # UCS 2.4 (64 Bit), xen, Profiles, Virtual Machine Manager, test.qa dn: cn=UCS 2.4 (64 Bit),cn=xen,cn=Profiles,cn=Virtual Machine Manager,dc=test, dc=qa cn: UCS 2.4 (64 Bit) ... An allen anderen Profilen ist univentionVirtualMachineProfileRTCOffset gesetzt (auf utc für Linux/UCS bzw. auf localtime für Windows Profile) Update von 2.4-2 auf 2.4-3 OK
Im Join-Skript wurde für den Fall der Xen-Profile aus die falsch Versionsnummer getestet, so daß dort das Profil nicht aktualisiert wurde. ldapsearch -x -b "cn=Profiles,cn=Virtual Machine Manager,$(ucr get ldap/base)" cn univentionVirtualMachineProfileRTCOffset | ldapsearch-wrapper | less svn26437, univention-virtual-machine-manager-daemon_0.9.326-1.264.201108291341 ChangeLog: ±0
ok, Changelog Eintrag vorhanden.
UCS 2.4-3 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".