Czy muszę uruchamiać serwer NTP na każdej maszynie wirtualnej?

Czy goście nie mogli w jakiś sposób odziedziczyć czasu systemowego hosta?

Nie ma sensu uruchamiać tego samego demona, aby uzyskać te same wyniki na tej samej maszynie wiele razy, ale nie znalazłem nic związanego z czasem podczas czytania artykułów KVM lub Xen. Rozumiem, że gość uruchamia hosta podczas rozruchu, ale może się wtedy rozpadać. Czy to jest poprawne ?

To jest poprawne. Należy zauważyć, że czas nie tylko „może” odpłynąć, ale również odpłynie z powodu faktu, że przerwy między przerwaniami timera (na których często opiera się pomiar czasu w systemie operacyjnym) są rozciągane i kompresowane, tak jak hiperwizor uznałby to za stosowne.

Często stosowanym obejściem na większości platform wirtualizacyjnych (usługi integracji Hyper-V, narzędzia VMWare) jest uruchamianie demona na gościu, który okresowo synchronizuje zegary z hostem VM. Jak zauważył Hauke ​​w komentarzu do twojego pytania, KVM zapewnia dodatkowo parawirtualizowany zegar, który wymagałby załadowania odpowiedniego sterownika do systemu-gościa.

Pomiar czasu w maszynach wirtualnych VMWare (vmware.com)
Synchronizacja zegara gości KVM (s19n.net)

W idealnym świecie goście maszyny wirtualnej zachowaliby idealny czas, a przynajmniej tak doskonały, jak zapewnia gospodarz. Niestety nie żyjemy w idealnym świecie.

Opierając się na moim doświadczeniu z praktycznie każdym hiperwizorem znanym człowiekowi, zawsze uruchamiam klienta NTP na maszynach wirtualnych, bez wyjątku. Moją zwykłą konfiguracją jest ntpd z opcją -g lub ntpdate rozpoczynający się tuż przed nim dla starych systemów, aby skrócić czas (który może być bardzo niezsynchronizowany podczas uruchamiania systemu).

KVM ma prawie idealną konfigurację z parawirtualizowanym zegarem czasu rzeczywistego ; goście z odpowiednim sterownikiem (przynajmniej najnowszym Linuksem) utrzymają czas, a także host. Ale nadal coś idzie nie tak: na przykład, host może nie działać z NTP, host może mieć niepoprawną strefę czasową, zegar hosta może być po prostu zły, itp.

VMware i Hyper-V znajdują się pośrodku. Każde z nich ma narzędzie przeznaczone do uruchamiania na gościu, które okresowo synchronizuje zegar z hostem, ale znowu jest to podatne na wszelkie istniejące problemy z zegarem hosta.

Goście na moim testowym serwerze Hyper-V również wykazywali dziwne zachowanie: nawet w przypadku usług integracyjnych zegar gościa dryfowałby szybciej niż 500 ppm, uniemożliwiając działanie ntpd ( uważa, że ​​zegar jest szalony, jeśli płynie szybciej niż ten ). Musiałem zmienić tych gości na chroniczne , co pozwala na dostosowanie tej wartości .

Xen jest najgorszy pod tym względem; nie ma absolutnie żadnej synchronizacji, a uruchomienie NTP u gości jest prawie wymagane. (Powiedziano mi, że bardzo najnowsze wersje Xen mają jakąś synchronizację, ale osobiście jeszcze z nią nie pracowałem).

Gorzej jest, gdy hiperwizor hosta nie jest pod twoją kontrolą, na przykład chmura publiczna. Jesteś na łasce dostawcy w odniesieniu do zegara hosta, a jeśli nie starają się go zsynchronizować, przegrywasz.

Mając to na uwadze, uruchamianie klientów NTP na maszynach wirtualnych jest prawie wymagane, jeśli potrzebujesz nawet pół-dokładnego zegara. Uwaga: Jeśli korzystasz z maszyn wirtualnych z systemem Windows, uzyskaj zewnętrznego klienta NTP, który stale dostosowuje zegar; niska wymówka dla klienta dostarczanego z systemem Windows dostosowuje zegar tylko raz w tygodniu , co jest całkowicie absurdalne.

Poleciłbym używać NTP, ponieważ jest dobrze znany i istnieje już od dłuższego czasu. Regulacja zegara nie jest trywialna. NTP rozwiązało ten problem.

Oficjalna linia VMware jest wykorzystanie jednego mechanizmu, z NTP korzystne , ponieważ jest bardziej drobnoziarnisty i wziąć mniejsze kroki, aby ustawić czas. Wewnętrzne rozwiązanie VMware wymaga większych kroków. Kiedy biegniesz, oboje mogą ze sobą walczyć. Wewnętrzne rozwiązanie VMware robi duży krok, a następnie NTP dostosowuje je i cofa nieco.

W praktyce jednak biegamy jednocześnie i nie widziałem jeszcze problemu.

$ ntpq   
ntpq> peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
something.org  172.2.1.5          2 u   57   64  377    1.597   -2.409   5.952


$  vmware-toolbox-cmd  timesync status
Enabled


$ vmware-toolbox-cmd help timesync
timesync: functions for controlling time synchronization on the guest OS
Usage: vmware-toolbox-cmd timesync <subcommand>

Subcommands:
  enable: enable time synchronization
  disable: disable time synchronization
  status: print the time synchronization status