Kategorien

Druckansicht des Beitrags Druckansicht des Beitrags

VirtualBox Guest Additions und die Zeit

Leider musste ich mittlerweile einen Nachteil bei der Installation der Gasterweiterungen feststellen, der mich sogar dazu brachte, sie komplett zu deinstallieren: Die Gasterweiterungen synchronisieren in unregelmäßigem Abstand die Zeit des Gastsystems mit dem Hostsystem. Wenn man als Host Windows hat und als Gast ein Linux-System mit ntpd, dann ist das nicht gerade toll. Wie also wird man die Gasterweiterungen wieder los? Nach einer Anleitung im Virtualbox-Forum muss man das aufgrund des Fehlens einer uninstall Option von Hand folgendermaßen bewerkstelligen:

sudo find /etc -name "*vboxadd*" -exec rm {} \;
sudo find /etc -name "*vboxvfs*" -exec rm {} \;
sudo rm -r /usr/src/vboxadd-*
sudo rm -r /usr/src/vboxvfs-*
sudo rm /usr/sbin/vboxadd-timesync
sudo rm /lib/modules/`uname -r`/misc/vboxadd.ko
sudo rm /lib/modules/`uname -r`/misc/vboxvfs.ko

Nach einem Neustart mit

sudo reboot

sollte sich das Zeitproblem erledigt haben. Vielleicht hätte es auch einfach gereicht, die Datei /usr/sbin/vboxadd-timesync umzubenennen und stattdessen einen Link auf /dev/null zu erzeugen. Aber sicher ist sicher 😉 Wer trotz der Entfernung der Gasterweiterungen Probleme hat, sollte bei älteren Kernel-Versionen eventuell die Bootparameter entsprechend ändern.

12 comments to VirtualBox Guest Additions und die Zeit

  • Daniel

    Macht es nicht evtl. mehr Sinn die Gasterweiterungen installiert zu lassen und das entsprechende Init-Script lahm zu legen?

    Leider hab ich grad kein passendes System da – ich meine aber das Script heisst „vboxadd-timesync“ oder ähnlich.

  • Itsme

    > Wenn man als Host Windows hat und als Gast ein Linux-System mit ntpd, dann ist das nicht gerade toll.

    Und warum ist das nicht gerade toll? Dann stimmt automatisch die Zeit in der VM.

    • Mit nicht gerade toll meine ich folgendes (kleiner Auszug aus /var/log/syslog):

      Mar 22 15:03:50 skylix ntpd[4135]: synchronized to 91.189.94.4, stratum 2
      Mar 22 15:03:51 skylix ntpd[4135]: synchronized to 85.214.29.92, stratum 2
      Mar 22 15:04:22 skylix ntpd[4135]: synchronized to 91.189.94.4, stratum 2
      Mar 22 15:09:45 skylix ntpd[4135]: synchronized to 213.239.214.170, stratum 2
      Mar 22 15:14:08 skylix ntpd[4135]: time reset +3.453878 s
      Mar 22 15:19:08 skylix ntpd[4135]: synchronized to 91.189.94.4, stratum 2
      Mar 22 15:26:42 skylix ntpd[4135]: synchronized to 62.52.175.213, stratum 2
      Mar 22 15:27:45 skylix ntpd[4135]: synchronized to 91.189.94.4, stratum 2
      Mar 22 15:29:59 skylix ntpd[4135]: time reset +3.471569 s
      Mar 22 15:34:04 skylix ntpd[4135]: synchronized to 91.189.94.4, stratum 2
      Mar 22 15:43:22 skylix ntpd[4135]: synchronized to 213.239.214.170, stratum 2
      Mar 22 15:45:52 skylix ntpd[4135]: synchronized to 91.189.94.4, stratum 2
      Mar 22 15:45:55 skylix ntpd[4135]: time reset +3.502302 s
      Mar 22 15:50:42 skylix ntpd[4135]: synchronized to 85.214.29.92, stratum 2
      Mar 22 15:51:05 skylix ntpd[4135]: synchronized to 91.189.94.4, stratum 2
      Mar 22 15:53:00 skylix ntpd[4135]: synchronized to 213.239.214.170, stratum 2
      Mar 22 15:57:18 skylix ntpd[4135]: synchronized to 91.189.94.4, stratum 2
      Mar 22 15:57:37 skylix ntpd[4135]: synchronized to 85.214.29.92, stratum 2
      Mar 22 16:00:20 skylix ntpd[4135]: synchronized to 91.189.94.4, stratum 2
      Mar 22 16:00:48 skylix ntpd[4135]: synchronized to 85.214.29.92, stratum 2
      Mar 22 16:01:27 skylix ntpd[4135]: time reset +3.515730 s
      Mar 22 16:06:26 skylix ntpd[4135]: synchronized to 91.189.94.4, stratum 2
      Mar 22 16:17:09 skylix ntpd[4135]: time reset +3.535388 s
      Mar 22 16:22:24 skylix ntpd[4135]: synchronized to 91.189.94.4, stratum 2
      Mar 22 16:32:09 skylix ntpd[4135]: time reset +3.559771 s
      Mar 22 16:37:46 skylix ntpd[4135]: synchronized to 85.214.29.92, stratum 2
      Mar 22 16:39:47 skylix ntpd[4135]: synchronized to 91.189.94.4, stratum 2
      Mar 22 16:44:02 skylix ntpd[4135]: synchronized to 213.239.214.170, stratum 2
      Mar 22 16:47:44 skylix ntpd[4135]: time reset +3.577487 s
      Mar 22 16:53:42 skylix ntpd[4135]: synchronized to 213.239.214.170, stratum 2
      Mar 22 16:56:57 skylix ntpd[4135]: synchronized to 85.214.29.92, stratum 2
      Mar 22 16:58:01 skylix ntpd[4135]: synchronized to 91.189.94.4, stratum 2
      Mar 22 17:00:36 skylix ntpd[4135]: synchronized to 85.214.29.92, stratum 2
      Mar 22 17:00:41 skylix ntpd[4135]: synchronized to 91.189.94.4, stratum 2
      Mar 22 17:02:50 skylix ntpd[4135]: time reset +3.607324 s
      Mar 22 17:07:58 skylix ntpd[4135]: synchronized to 91.189.94.4, stratum 2
      Mar 22 17:18:03 skylix ntpd[4135]: time reset +3.624522 s
      Mar 22 17:23:07 skylix ntpd[4135]: synchronized to 213.239.214.170, stratum 2
      Mar 22 17:28:28 skylix ntpd[4135]: synchronized to 85.214.29.92, stratum 2
      Mar 22 17:28:43 skylix ntpd[4135]: synchronized to 213.239.214.170, stratum 2
      Mar 22 17:33:53 skylix ntpd[4135]: time reset +3.644392 s
      Mar 22 17:38:06 skylix ntpd[4135]: synchronized to 91.189.94.4, stratum 2
      Mar 22 17:48:56 skylix ntpd[4135]: time reset +3.666057 s
      Mar 22 17:53:19 skylix ntpd[4135]: synchronized to 62.52.175.213, stratum 2
      Mar 22 17:57:34 skylix ntpd[4135]: synchronized to 85.214.29.92, stratum 2
      Mar 22 18:00:09 skylix ntpd[4135]: synchronized to 213.239.214.170, stratum 2
      Mar 22 18:04:17 skylix ntpd[4135]: time reset +3.689787 s
      Mar 22 18:09:01 skylix ntpd[4135]: synchronized to 91.189.94.4, stratum 2

      Etwa alle 15 Minuten wird offensichtlich die Uhrzeit wieder umgestellt. Schuld daran sind die Gasterweiterungen, die die Uhrzeit des Gastsystems der des Hostsystems anpassen. Hat man die Gasterweiterungen nicht installiert, dann läuft der ntpd problemlos durch und muss nicht ständig die Zeit verstellen, weil ihm jemand „dazwischenpfuscht“. Eigentlich ist es sowieso seltsam, dass Windows XP nicht die korrekte Uhrzeit hat, da es bei mir die Zeit mit time.windows.com synchronisiert.

  • Conceit

    Es ist eine denkbar schlechte Idee, in virtuellen Maschinen einen NTPD zu betreiben, da dieser die Uhrzeit nicht einfach synchronisiert. NTPD versucht vielmehr durch Ändern der „Geschwindigkeit“ der Uhr, eine leichte Zeitverschiebung anzupassen (skewing). Da die Uhr in der virtuellen Maschine aber software-getrieben ist und sie somit keine kleine und einheitliche Abweichung hat, wird der NTPD sich falsch verhalten und einer tickenden „Zeitbombe“. (Jaja.. Einen Euro ins Phrasenschwein..)

    Die Software-Uhr läuft einfach massiv falsch, wenn die Maschine unter Last ist. Der NTPD kommt mit diesem rumgeeiere nicht klar und regelt falsch nach. Evtl. hängen beide Uhren (Host und Guest) sogar zusammen (dependant wallclock). Wenn dann auf beiden Maschinen NTPDs laufen, wirds richtig schlimm. Von rückwärts laufenden Uhren bis hin zu Abstürzen im Host wie im Guest ist dann alles dabei.

    Also: NTPD u.ä., im Gast AUS. Guest-Additions zur Zeitsync. AN. Die Guest Additions holen sich ab und zu die Zeit von Host und *setzen* sie einfach im Guest (also kein Clock Skewing wie bei NTP). Ist gesünder. Das gilt übringens für XEN, VirtualBox und VMware und wie sie nicht alles heißen gleichermaßen. Wenn man im Guest eine andere Uhrzeit will, sollte man in der virtuellen Maschinen einen Zeitoffset einstellen.

    Siehe hier: http://www.vmware.com/pdf/vmware_timekeeping.pdf
    und hier: http://stackoverflow.com/questions/117422/how-can-i-resolve-the-drifting-clock-for-my-virtual-machine

    • Sehr interessante Betrachtung. Wenn ich den VMWare-Artikel lese, so werden aus meiner Sicht ntp und die Guest-Additions als gleichwertige Alternativen vorgestellt.
      In a physical machine, it is generally necessary to run network clock synchronization software such as NTP or the Windows Time Service to keep time accurately over the long term. The same applies to virtual machines, and the same clock synchronization software can be used, although it sometimes needs to be configured specially in order to deal with the less smooth behavior of virtual timer devices. VMware Tools can also optionally be used to correct long‐term drift and errors by periodically resynchronizing the virtual machine’s clock to the host’s clock, but the current version at this writing is limited.
      Aus meiner Sicht macht das auch Sinn. Entweder ich nehme die Guest-Additions und habe dadurch evt. Zeitsprünge zurück oder nach vorne bei der Zeitsynchronisierung oder ich verwende den ntpd, der die Taktrate entsprechend korrigiert, somit keine Zeitsprünge aufweist, wobei die Zeit aber eher falsch liegen kann. In letzter Konsequenz heißt das, dass ich auf einem virtuellen System nie die genaue Zeit haben kann – mit keiner der beiden Alternativen. Weil dovecot (mein IMAP-Server) mit Zeitsprüngen in die Vergangenheit absolut nicht zurechtkommt, werde ich weiterhin die Variante mit ntpd einsetzen.

  • Markus Effinger

    Mit der aktuellen Version von VirtualBox (3.0.2) lässt sich die Zeitsynchronisierung auch durch ein einfaches

    sudo /usr/sbin/vboxadd-service --disable-timesync

    deaktivieren. Wichtig ist nur, dass man unmittelbar nach der Installation der Guest Additions auf dem Gastsystem einen Reboot durchführt, sonst erhält man nämlich eine Fehlermeldung (wenn ich mich richtig erinnere irgendetwas mit failed VERR_FILE_NOT_FOUND).

  • Conceit

    Nimm das VMware-Dokument bitte nicht zu wörtlich (indem Du einen einzigen Satz zitierst) und bilde es gleich auf die VirtualBox-Realität ab. Erstmal beschreibt das Dokument generell in den späteren Kapiteln das Fehlverhalten bei der verwendung „nativer“ Zeitsynchronisationssysteme (stellt sie aber harmloser da) sagt dann aber, dass ebendies mit NTP unter Linux getestet wurde und alles prima sei. Was davon Marketing ist, entscheide selbst.

    Tatsächlich habe ich einige persönliche Erfahrung mit VirtualBox, XEN und NTP machen dürfen, und es läuft alles andere als gut.

    Hier ein paar Eckdaten aus der Realität:
    – Host: OpenSuSE 11.1 mit Kernel 2.6.27.21 und NTPD
    – Guest: OpenSuSE 11.0 mit Kernel 2.6.25.0 und NTPD unter VirtualBox 2.2.4

    Abweichung: Zwischen etwa eine und 15 (!!) Minuten nach einer Stunde Betrieb unter Last. Abstürze (freeze) des gesamten Client-Systems täglich, abstürze des Hosts etwa alle 4 Tage. Getestet über einen Zeitraum von einem Monat.

    Vor diesem Test lief dasselbe System mit XEN unt NTPD und verhielt sich beinahe identisch falsch.

    Alle Probleme verschwanden sofort, als NTPD im Client abgeschaltet wurde. Dies deckt sich mit den Aussagen aus sehr vielen Foren, Blogs und dem XEN Bugtracker, die ich in meinem vorigen Kommentar zusammengefasst habe.

    Mein System läuft nun stabil. Die o.g. Kernelversionen sind die z.Zt. eingesetzten, aber ich habe nicht zeitgleich NTP deaktiviert und Kernel aktualisiert – nur falls jemad jetzt glaubt es sei durch ein Kernel-Update behoben worden.

    Dementsprechend kann ich wirklich nur weiterhin stark davon abraten, NTPD zu benutzen – dem sollte zumindest eine mehrtägige Testphase unter Last(!!) vorausgehen. Es gibt sicherlich konstellationen, wo das funktionieren mag. Vielleicht ist VMware da auch wirklich stabiler, habe ich nicht getestet. Bin froh, dass es hier nun endlich läuft… Viel Erfolg!

  • Ford Prefect

    In 3.1 gibt es ein Deinstallationsskript in /opt/VBoxGuestAdditions*/, siehe:

    http://episteme.arstechnica.com/eve/forums/a/tpc/f/96509133/m/776000263041

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  

  

  

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.