psychofaktory Posted May 13, 2021 Share Posted May 13, 2021 Hallo liebe Unraid-Community, ich habe ein Problem mit der Systemzeit in meiner OPNsense-VM die auf Unraid läuft. Folgende Ausgangssituation: OPNsense 21.1.5-amd64 als VM auf Unraid 6.9.2 Meine VM-Konfiguration: <?xml version='1.0' encoding='UTF-8'?> <domain type='kvm' id='1'> <name>ADL15-FW001</name> <uuid>c434e72d-1ae9-f97c-5f6e-26fee578337b</uuid> <description>OPNsense-Firewall</description> <metadata> <vmtemplate xmlns="unraid" name="FreeBSD" icon="freebsd.png" os="freebsd"/> </metadata> <memory unit='KiB'>4194304</memory> <currentMemory unit='KiB'>4194304</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>2</vcpu> <cputune> <vcpupin vcpu='0' cpuset='3'/> <vcpupin vcpu='1' cpuset='7'/> </cputune> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-i440fx-5.1'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/c434e72d-1ae9-f97c-5f6e-26fee578337b_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> </features> <cpu mode='host-passthrough' check='none' migratable='on'> <topology sockets='1' dies='1' cores='1' threads='2'/> <cache mode='passthrough'/> <feature policy='require' name='topoext'/> </cpu> <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/isos/OPNsense-21.1-OpenSSL-dvd-amd64.iso' index='2'/> <backingStore/> <target dev='hda' bus='sata'/> <readonly/> <boot order='2'/> <alias name='sata0-0-0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='writeback'/> <source file='/mnt/user/domains/ADL15-FW001/vdisk1.img' index='1'/> <backingStore/> <target dev='hdc' bus='sata'/> <boot order='1'/> <alias name='sata0-0-2'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> <controller type='pci' index='0' model='pci-root'> <alias name='pci.0'/> </controller> <controller type='sata' index='0'> <alias name='sata0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </controller> <controller type='virtio-serial' index='0'> <alias name='virtio-serial0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </controller> <controller type='usb' index='0' model='ich9-ehci1'> <alias name='usb'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <alias name='usb'/> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <alias name='usb'/> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <alias name='usb'/> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> </controller> <serial type='pty'> <source path='/dev/pts/0'/> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> <alias name='serial0'/> </serial> <console type='pty' tty='/dev/pts/0'> <source path='/dev/pts/0'/> <target type='serial' port='0'/> <alias name='serial0'/> </console> <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-1-ADL15-FW001/org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> <alias name='channel0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='tablet' bus='usb'> <alias name='input0'/> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='ps2'> <alias name='input1'/> </input> <input type='keyboard' bus='ps2'> <alias name='input2'/> </input> <graphics type='vnc' port='5900' autoport='yes' websocket='5700' listen='0.0.0.0' keymap='de'> <listen type='address' address='0.0.0.0'/> </graphics> <video> <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> <alias name='video0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x03' slot='0x00' function='0x1'/> </source> <alias name='hostdev0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x03' slot='0x00' function='0x2'/> </source> <alias name='hostdev1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </hostdev> <memballoon model='none'/> </devices> <seclabel type='dynamic' model='dac' relabel='yes'> <label>+0:+100</label> <imagelabel>+0:+100</imagelabel> </seclabel> </domain> als NTP-Zeitserver verwende ich sowohl unter Unraid als auch der OPNsense-VM: ptbtime2.ptb.de ntp1.ipv6.fau.de 2.de.pool.ntp.org ntp1.t-online.de Alle Server sind sowohl von Unraid als auch von der VM aus erreichbar und es kann jeweils die Zeit abgefragt werden. Mit diesen NTP-Servern bleibt die Systemzeit in Unraid aktuell. In der VM weicht die Zeit aber bereits 30 Minuten nach der letzten Abfrage um ca. 2 Minuten ab. Worauf sind diese Abweichungen zurückzuführen, und wie kann ich die Zeit synchron halten? Quote Link to comment
hawihoney Posted May 13, 2021 Share Posted May 13, 2021 (edited) YES! Seit einiger Zeit kämpfe ich damit, dass meine VMs kurz nach dem Start die Clocksource wegen abweichender Zeit wechseln und die Performance auf 1/4 fällt. Nichts hat geholfen bisher: Wechsel der zugewiesenen Cores (bei 2 CPUs, 20 Cores, 40 Threads) etc. irgendein Cores meldete immer als einziger die Abweichung. Bisher nicht getraut habe ich mich die Abschaltung bzw. die Vertrauensstellung des Zeitgebers zu markieren. Das geht angeblich über die syslinux. Ich glaube nicht, dass es mit NTP zu tun hat. Bei mir trat das erst durch den Wechsel auf die 6.9.x Versionen auf, was mich eher an den 5er Kernel denken lässt. Hast Du die Möglichkeit in Deiner VM System Log nach dem Text Clocksource zu durchsuchen. Edited May 13, 2021 by hawihoney Quote Link to comment
psychofaktory Posted May 13, 2021 Author Share Posted May 13, 2021 Demnach gibt es wohl Gleichgesinnte. 1 minute ago, hawihoney said: Ich glaube nicht, dass es mit NTP zu tun hat. Das denke ich auch nicht. die NTP-Abfrage funktioniert ja an sich sowohl unter Unraid als auch dessen Gast fehlerfrei. Die Zeit läuft dann unter Unraid "normal" weiter. Auf dem Gast läuft die Zeit dann aber offenbar etwas langsamer oder etwas schneller als auf dem Host. Beides habe ich schon beobachtet. Der Zeitgeber-Takt scheint also irgendwo zu schwanken. Ich kann aber mit meinen Kenntnissen leider nicht ermitteln wo... In der XML-Ansicht der VM-Konfiguration ist mir folgender Bereich aufgefallen der nicht in der GUI-Konfiguration vorkommt: <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> Womöglich liegt hier ein Problem und es sollten in meiner Konstellation andere Werte eingetragen werden. Leider konnte ich keine Dokumentation oder ähnliches finden was mir hier weiterhelfen könnte. Quote Link to comment
hawihoney Posted May 13, 2021 Share Posted May 13, 2021 (edited) Das scheint wohl Standard zu sein. Hier meine VM Konfiguration zur Clock: <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> Ich bin mir sehr sicher, dass es ein Fehler im KVM, o.ä. ist, aber das kann ich nicht beweisen. Meine VMs sind Unraid VMs - geclont aus dem Bare-Metal Unraid. Mehrere Unraid VMs laufen auf Unraid: 1.) Das Bare-Metal Unraid hat nie ein Problem mit der Clock. 2.) Es ist immer nur die erste gestartete VM die dieses Problem bekommt. Die als zweite oder dritte gestartete VM hat das Problem nie. Wenn ich die VMs in umgekehrter Reihenfolge starte, ist es wieder die erste gestartete VM die das Problem bekommt. 3.) Das Problem nennt immer einen Core, der abweicht, aber es ist immer ein anderer Core. Ich habe VMs schon anderen CPUs oder anderen Cores zugewiesen. Es bleibt immer bei 2.) Der Fehler in der betroffenen Unraid VM lautet dann: May 4 02:10:40 TowerVM01 kernel: clocksource: timekeeping watchdog on CPU2: Marking clocksource 'tsc' as unstable because the skew is too large: May 4 02:10:40 TowerVM01 kernel: clocksource: 'acpi_pm' wd_now: 70aa1c wd_last: 51d1b1 mask: ffffff May 4 02:10:40 TowerVM01 kernel: clocksource: 'tsc' cs_now: 5b65e65f2fb54 cs_last: 5b65e12de6c58 mask: ffffffffffffffff May 4 02:10:40 TowerVM01 kernel: tsc: Marking TSC unstable due to clocksource watchdog May 4 02:10:40 TowerVM01 kernel: clocksource: Switched to clocksource acpi_pm Dazu muss man wissen, dass diese Clock für das Handling im Multithreading benötigt wird, kann sich Linux nicht auf eine saubere Synchronisaion verlassen, dann schaltet es einen Gang runter. In meinem Fall wird um 3/4 runtergeschaltet. Ein laufender 60 MB/s Parity Sync knallt von einer Sekunde auf die andere auf 15 MB/s runter. Im Moment ist VM01 die leidtragende. Angeblich kann man in der syslinux der VMs die folgenden Kernel-Parameter eintragen: clocksource=tsc tsc=reliable Ich habe aber bis zum heutigen Tag nicht herausgefunden ob Unraid diese Parameter unterstützt und habe mich nicht getraut sie zu verwenden. Statt dessen starte ich eine Dummy VM als erstes und dann erst die produktiven VMs. Edited May 13, 2021 by hawihoney Quote Link to comment
psychofaktory Posted May 13, 2021 Author Share Posted May 13, 2021 Das ist auch ein interessanter Fehler auch wenn sich das Fehlerbild etwas vom meinigen unterscheidet. Dennoch könnten die Fehlerquelle und somit die zur Lösung notwendigen Schritte die gleichen sein. Ich bin aufgrund Deines Posts auf die Dokumentation von libvirt gestoßen, wo die Parameter zum Zeitabgleich zwischen Host und Gast und die möglichen Optionen beschrieben werden: libvirt - Time keeping Die große Frage lautet nun: Welche Parameter sind für OPNsense (FreeBSD) unter einem aktuellen Unraid die richtigen? Quote Link to comment
hawihoney Posted May 14, 2021 Share Posted May 14, 2021 (edited) 10 hours ago, psychofaktory said: Welche Parameter Vergangene Nacht ist etwas passiert, was in den letzten zwei Jahren, seit ich mit der aktuellen Anzahl von VMs arbeite, noch nie passiert ist. Eine zweite VM meldete den selben Fehler und schaltete zurück. Es ist wie verhext. Ich schreibe hier meine Theory und in der folgenden Nacht wird sie ad absurdum geführt. Arrggghhhh! Die libvirt Seite hatte ich schon in meinem Lesezeichen Allerdings beim erneuten Lesen fiel mir heute morgen auf, dass der "tsc" timer, der in meinen Unraid VMs zunächst läuft, überhaupt nicht in der </clock> Konfiguration aufgeführt ist. Es stehen in unseren Konfigurationen drei timer, von denen aber keiner bei mir läuft. Bei mir laufen zunächst "tsc" und später, nach dem Fehler, wird auf "acpi_pm" zurückgeschaltet. Vielleicht sollte ich spaßeshalber den "tsc" in der VM Konfiguration aufführen ... <timer name='tsc' tickpolicy='catchup' mode='auto'/> Edited May 14, 2021 by hawihoney Quote Link to comment
psychofaktory Posted May 14, 2021 Author Share Posted May 14, 2021 (edited) Ich habe zumindest das Gefühl wir sind auf der richtigen Spur 🙂 Offensichtlich müssen ja die Zeitzähler, die der VM-Gast nutzen möchte zu den vom VM-Host bereitgestellten passen. Ich habe mich daher mal auf die Suche nach Informationen begeben, welche Zeitzähler FreeBSD verwenden möchte und bin auf diese Seite gestoßen: FreeBSD Time Counters Der dort beschriebene Fehler "TIME_ERROR: 0x41: Clock Unsynchronized" taucht auch genau dann in meinem Log auf wenn die Zeit anfängt abzuweichen. Das hier sind die Werte die ich aus meiner OPNsense-Installation auslesen konnte: root@ADL15-FW001:~ # dmesg | grep Timecounter Timecounter "i8254" frequency 1193182 Hz quality 0 Timecounters tick every 10.000 msec Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 Timecounter "i8254" frequency 1193182 Hz quality 0 Timecounters tick every 10.000 msec Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 Timecounter "i8254" frequency 1193182 Hz quality 0 Timecounters tick every 10.000 msec Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 Timecounter "i8254" frequency 1193182 Hz quality 0 Timecounters tick every 10.000 msec Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 Timecounter "i8254" frequency 1193182 Hz quality 0 Timecounters tick every 10.000 msec Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 Timecounter "i8254" frequency 1193182 Hz quality 0 Timecounters tick every 10.000 msec root@ADL15-FW001:~ # sysctl kern.timecounter kern.timecounter.tsc_shift: 1 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 0 kern.timecounter.fast_gettime: 1 kern.timecounter.tick: 1 kern.timecounter.choice: i8254(0) ACPI-fast(900) TSC-low(-100) dummy(-1000000) kern.timecounter.hardware: ACPI-fast kern.timecounter.alloweddeviation: 5 kern.timecounter.timehands_count: 2 kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.counter: 19671 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.counter: 1961978 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.TSC-low.quality: -100 kern.timecounter.tc.TSC-low.frequency: 1909497435 kern.timecounter.tc.TSC-low.counter: 4174462623 kern.timecounter.tc.TSC-low.mask: 4294967295 Jetzt müsste ich nur wissen ob ich auf Host- oder auf Gast-Seite etwas anpassen muss. Und wenn ja, was genau. Edited May 14, 2021 by psychofaktory Quote Link to comment
hawihoney Posted May 14, 2021 Share Posted May 14, 2021 (edited) Im Moment kann ich meine VMs nicht neu starten, da ein disk-rebuild läuft. Da will ich nicht reingrätschen. Ich habe aber Folgendes vor: 1.) Ich werde auf Host Seite in allen VM Konfigurationen in der <clock> section diesen zusätzlichen Timer aufnehmen: <timer name='tsc' tickpolicy='catchup' mode='auto'/> 2.) Wenn die VMs damit starten werde ich sie mal eine Zeit lang laufen lassen und prüfen ob der Fehler wieder auftritt. 3a.) Sollte der Fehler nochmals auftreten, werde ich auf dem Host in der Flash Konfiguration (syslinux) evtl. mal "tsc=reliable" hinzufügen. Wie bereits geschrieben weiß ich nicht ob Unraid diesen Kernel Parameter überhaupt unterstützt und ob das nicht doch negative Nebenwirkungen hat. 3b.) Als dämlichen Test könnte ich auch auf dem Host und allen VMs ein User Script einrichten, dass alle 5 Minuten ntptime ausführt. Keine Ahnung ob das hilft ... Unabhängig davon habe ich aber mal im VM Forum nachgefragt wie es sein kann, dass in einer VM ein Timer läuft, der überhaupt nicht in der Konfiguration aufgeführt ist (TSC). Ich erwarte dort keine Erklärung die uns weiter bringt da es doch sehr speziell ist. Als langer (2008), treuer (6 Pro Lizenzen) Unraid Kunde werde ich dann mal den Chef per Mail kontaktieren. Evtl. kann er uns ja weiter helfen. Nachtrag: Die beiden Befehle aus Deinem vorherigen Post laufen bei mir ins Leere. Edited May 17, 2021 by hawihoney Quote Link to comment
psychofaktory Posted May 14, 2021 Author Share Posted May 14, 2021 (edited) Der Ansatz klingt für deinen Fall sehr vielversprechend. So ganz scheint mir das für mein Szenario aber noch nicht die Lösung zu sein. Ich versuche das mal so zusammenzufassen wie ich das verstehe. Aktuell stell Unraid (in der default-Konfiguraton) den VMs folgende Timer zur Verfügung: rtc (catchup) pit (delay) hpet (not present) OPNsense unterstützt folgende Timer: i8254 (0) ACPI-fast (900) TSC-low (-100) dummy (-1000000) Wobei in meinem Fall aktuell wohl "ACPI-fast" genutzt wird. 'tsc' als zusätzlichen Timer in der Konfiguration in Unraid für den Gast zur Verfügung zu stellen erscheint mir sinnvoll. Schließlich sollten vom Host bereitgestelter Timer und vom Gast genutzer Timer ja übereinstimmen. Allerdings müsste ich der OPNsense nach meinem Verständnis ja dann noch sagen dass sie statt "ACPI-fast" jetzt "TSC-low" verwenden soll. Oder sehe ich hier etwas falsch? 2 hours ago, hawihoney said: Die beiden Befehle aus Deinem vorherigen Post laufen bei mir ins Leere. Die Befehle habe ich direkt in die Konsole der OPNsense eingegeben. Möglicherweise sind diese bei Unraid anders. Ich hatte sie aus dem obigen Link zu FreeBSD entnommen. dmesg.txt Edited May 14, 2021 by psychofaktory Quote Link to comment
Ford Prefect Posted May 14, 2021 Share Posted May 14, 2021 sorry für offtopic, aber ich weiss garnicht ob ich je einen Windows Host (ob VM oder real) hatte, bei dem die Uhrzeit synchron zum ntp war/blieb. Ich habe im Lockdown festgestellt, dass Terminkalender-Warnungen nicht vertrauenswürdig sind um einen übervollen Terminkalender zu managen Quote Link to comment
psychofaktory Posted May 14, 2021 Author Share Posted May 14, 2021 @Ford Prefect Die Erfahrung habe ich noch so nicht machen müssen. Ich hatte schon mit sehr vielen Windows-Installationen zu tun. Natürlich gab es immer mal wieder leichte Abweichungen in der Zeit (einige Sekunden in einem Zeitraum von 24 Stunden). Aber mit der nächsten NTP-Synchronisation war das wieder OK. Windows lief dabei sowohl auf verschiedensten physikalischen Maschinen als auch virtuell (HyperV, ESXi, virtual Box) Probleme gab es nur mal unter CentOS in einer bestimmten Version oder wenn die BIOS-Batterie am Mainboard leer war. OPNsense scheint hier aber deutlich empfindlicher auf Zeitabweichungen zu reagieren. Da die Instanz auch gleichzeitig als interner NTP-Server für andere Clients dienen soll sind die Auswirkungen noch weitreichender. Quote Link to comment
Ford Prefect Posted May 14, 2021 Share Posted May 14, 2021 @psychofaktory danke. bei mir sieht es wirklich umgekehrt aus. ich bin bei Windoof nur (gequälter) User und habe nur notgedrungen damit zu tun. dank Lockdown haben wir in der Family aufgestockt und es sind aktuelle 5-6 Instanzen, inkl. 4men Läppi immer mal wieder hier im Einsatz. Jede davon ist schonmal mit Abweichungen von 5+ Minuten aufgefallen und bei keiner nutze ich den internen ntp-Service des Routers primär. Mit Linux hatte ich die Probleme noch nie. Wenn man den eigenen Router als NTP-Server für das Heimnetz anbietet, selbst aber diesen nur über das I-Netz - statt einer echten ?Stratum-1? Instanz - versorgt, bekommen das die Clients natürlich gesagt und vertrauen diesem evtl. weniger? Quote Link to comment
psychofaktory Posted May 14, 2021 Author Share Posted May 14, 2021 Best-Practice war für mich immer: Der Router bezieht die Zeit via NTP von (mehreren) öffentlichen Stratum 1 Server und stellt die Zeit dann intern für alle Clients bereit Alle interne Clients beziehen dann vom Router via NTP dessen Zeit. Außnahmen: bei VMs bezieht der Host die Zeit vom Router und die Gäste die Zeit vom Host. Sonst kann es wohl zu Konflikten kommen. ist der Router selbst eine VM (wie in meinem Fall hier) bezieht die Router-VM von einem öffentlichen Zeitserver obwohl es sich um einen VM-Gast handelt. Ob der VM-Host die Zeit dann von seinem VM-Gast oder ebenfalls von öffentlichen NTP-Servern bezieht, da bin ich mir noch nicht ganz schlüssig. Vielleicht liegt ja auch hier ein Teil meines Problems?... Handelt es sich um eine (Windows-)Domäne, bezieht der Domänen-Controller die Zeit vom Router (oder falls virtuell vom VM-Host) und alle Domänen-Clients die Zeit vom Domänen-Controller. Mit dieser Umsetzung lief die Zeit bei mir bisher in jeder Konstellation sauber. Quote Link to comment
hawihoney Posted May 14, 2021 Share Posted May 14, 2021 1 hour ago, psychofaktory said: bei VMs bezieht der Host die Zeit vom Router und die Gäste die Zeit vom Host. Bei einer Unraid VM ist das anders. Host Unraid sowie Guest Unraid haben in den Einstellungen den Router eingetragen. Das Problem hat auch nur begrenzt mit NTP zu tun, da TSC ein Counter ist. Übrigens gibt es für Windows andere clock Einstellungen. Über die bin ich heute gestolpert. localtime statt utc und diverse andere. Der gemeinsame Nenner bei dem Ganzen ist, dass innerhalb einer VM die Timer drastisch abweichen können und das hat dann unterschiedliche Auswirkungen je nach Guest. Beim Einen ist es die falsche Uhrzeit, bei mir sorgt der Ersatz-Counter für eine Performance-Reduzierung um satte 75%. Wäre schön wenn das Problem etwas abgemildert werden könnte - wie auch immer. Quote Link to comment
psychofaktory Posted May 14, 2021 Author Share Posted May 14, 2021 15 minutes ago, hawihoney said: Bei einer Unraid VM ist das anders. Host Unraid sowie Guest Unraid haben in den Einstellungen den Router eingetragen. Genau so würde ich es auch handhaben. Außer eben wenn der Router der eigene Gast ist wie eben in meinem Fall. Auf referenziert man den Host hier? 17 minutes ago, hawihoney said: Übrigens gibt es für Windows andere clock Einstellungen. Darauf bin ich bei meinen bisherigen Recherchen auch schon gestoßen. Es scheint also schon sehr wichtig zu sein, dass die Clock-Einstellungen dem Gast angepasst sind. Die Frage ist nur: gibt es hier irgendwo eine Vorgabe für welches System welche Werte zu nehmen sind? Quote Link to comment
hawihoney Posted May 18, 2021 Share Posted May 18, 2021 Nur zur Info: Ich habe heute einige Tests mit einer Unraid VM und diversen <clock> Einstellungen durchgeführt. Ich bin zur Überzeugung gekommen, dass diese - zumindest für das Slackware Template (Unraid) - ignoriert werden. Ich habe dazu einen Bug Report erstellt. Mal sehen was daraus wird. Ich habe leider keine Windows Linzenz um eine Windows VM aufzubauen - sonst würde ich das auch mal testen. Ich rate aber, dass es dort nicht anders sein wird. Quote Link to comment
psychofaktory Posted May 18, 2021 Author Share Posted May 18, 2021 Hier auch mein Stand: Ich habe auf Empfehlung aus dem OPNsense-Forum hin in der VM-Konfiguration in Unraid <timer name='hpet' present='yes'/> gesetzt. sowie die Datei /var/db/ntpd.drift in OPNsense gelöscht. Diese enthält Informationen zum Zeitversatz zum Host und wird bei Bedarf wieder neu geschrieben. In OPNsense wird HPET auch als Zeitzähler erkannt und genutzt. Dazu waren keine expliziten Anpassungen erforderlich. On 5/14/2021 at 12:28 PM, hawihoney said: <timer name='tsc' tickpolicy='catchup' mode='auto'/> Diesen Wert habe ich ebenfalls probiert. Allerdings hat sich dadurch in der VM rein garnichts geändert. Quote Link to comment
jj1987 Posted May 18, 2021 Share Posted May 18, 2021 1 hour ago, hawihoney said: Ich habe leider keine Windows Linzenz um eine Windows VM aufzubauen - sonst würde ich das auch mal testen. Ich rate aber, dass es dort nicht anders sein wird. Theoretisch kannst du Windows auch ohne Lizenz nutzen, dann kommt zwar bei jedem Start die Aufforderung "Bitte aktivieren" und du kannst den Hintergrund und ein paar andere Dinge nicht verändern, aber gerade zum testen ist das ja nicht weiter wild. Quote Link to comment
psychofaktory Posted May 21, 2021 Author Share Posted May 21, 2021 Ich habe inzwischen weiter beobachtet und getestet. Im OPNsense-Forum wurde angemerkt, dass der Fehler von einer fehlerhaften Zeit am Host, also in Unraid, kommen kann. Bisher hatte ich es so eingestellt, dass Unraid die Zeit via NTP von den gleichen öffentlichen NTP-Servern bezieht wie der VM-Gast OPNsense. Hier funktioniert die NTP-Synchronisation und läuft im Gegensatz zu OPNsense auch sauber weiter. Während in OPNsense die Zeitsynchronisation nur einmalig nach Start des NTPd-Dienstes funktioniert und dann immer weiter abweicht. Also habe ich zum Test NTP in Unraid mal deaktiviert und die Zeit manuell gesetzt. Bereits nach wenigen Stunden hatte ich eine Abweichung von mehreren Minuten zur tatsächlichen Zeit. Der Zeitzähler in Unraid scheint also zu langsam zu laufen. Und das interessanterweise im gleichen Maße, wie die Systemzeit in OPNsense zu langsam läuft wenn der Abgleich mit den NTP-Servern nicht mehr funktioniert. Die BIOS-Einstellungen (Mainboard: ASUS Pro B550M-C; CPU: AMD Ryzen 3 PRO 4350G) habe ich bereits überprüft, aber keine Einträge gefunden die ich hier als relevant erachtet hätte. Das BIOS ist aktuell und die BIOS-Batterie verfügt über ausreichend Spannung. Welche Anpassungen kann ich vornehmen, damit die Systemzeit korrekt läuft? Quote Link to comment
hawihoney Posted May 21, 2021 Share Posted May 21, 2021 56 minutes ago, psychofaktory said: Der Zeitzähler in Unraid scheint also zu langsam zu laufen. An dieser Stelle laufen unsere beiden Installationen weit auseinander. Man kann sie, obwohl ähnliche Probleme, überhaupt nicht mehr vergleichen. Der gemeinsame Nenner ist lediglich, dass innerhalb von VMs die Zeit nicht mehr mit dem Host zu synchronisieren ist. Mittlerweile wird in meinen VMs der TSC in der Boot-Sekunde bereits als instabil markiert. Ich hatte auch schon versucht im Host und allen VMs die gleiche NTP Konfiguration anzugeben und per Timer permanent zu synchronisieren. Auch das hat nicht gefruchtet. Einfach nur ärgerlich das Ganze. Ich nutze derzeit noch ziemlich alte, potente Hardware. Mal sehen wie es mit aktueller Hardware wird. Quote Link to comment
mgutt Posted May 21, 2021 Share Posted May 21, 2021 1 hour ago, psychofaktory said: Also habe ich zum Test NTP in Unraid mal deaktiviert und die Zeit manuell gesetzt. Bereits nach wenigen Stunden hatte ich eine Abweichung von mehreren Minuten zur tatsächlichen Zeit. Das teste ich jetzt auch mal. Also so ja? Quote Link to comment
psychofaktory Posted May 21, 2021 Author Share Posted May 21, 2021 16 minutes ago, mgutt said: Also so ja? Ja, genau so meinte ich es. Quote Link to comment
mgutt Posted May 21, 2021 Share Posted May 21, 2021 Gut, habe nun bei zwei Servern das NTP deaktiviert. Heute Abend gebe ich dann Feedback. Quote Link to comment
mgutt Posted May 22, 2021 Share Posted May 22, 2021 Beide Server (Intel C246 und Atom J5005) haben immernoch korrekte Zeiten. Quote Link to comment
jj1987 Posted May 22, 2021 Share Posted May 22, 2021 @mgutt, @hawihoney, @psychofaktory: Habt ihr im BIOS einen Punkt "HPET" und wenn ja ist der aktiviert oder deaktiviert? Das ist ein (neuer?) Timer der aber wohl häufig Standardmäßig deaktiviert ist. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.