OpenBSD 6.1 guest hängt

[moustache]

Hallo zusammen

Ich habe auf einer Mini-Umgebung mit Intel NUC 6i5SYH (neuestes 062 BIOS) und neustem PVE 5.0 mit OpenBSD 6.1 Guest-VMs immer wieder Hänger. Unter pve 4.x war dies rocksolid, erst seit PVE manchmal hängts sogar täglich!

Es spielt keine Rolle, ob es frisch installierte oder bestehende guest VM ist, habs sogar noch mit aus PVE 4 mitgegenomme VMs probiert. Irgendwann hängts, gleich ob via Console oder nun auch via ssh (während Kompilieren eines neuen Kernels...toll nicht;-).

Das kann auch dann passieren, wenn ich die VM runterfahren oder rebooten will, dann irgendwann hängt es sich so auf, dass ich mit STOP einen harten shutdown machen muss, denn das löst sich nix auch nicht nach Stunden (was ich ausprobiert habe).

In allen Fällen steigt im PVE der Load steigt auf 100% des einen CPUS cores an. Andere VMs wie Linuxe laufen parallel, also HW schliesse ich aus. Ich nutze für die Vm 2 core sund genügend Ram, SCSI und VirtIO Netzwerk, keine Passthroughs oder komplexe Config, die da einen Einfluss haben könnte.

Es gibt aus den OpenBSD Kreisen Hinweise, die probiert aber keinen Erfolg gebracht haben:
https://marc.info/?l=openbsd-misc&w=2&r=1&s=Openbsd+6.1+and+Current+Console+Freezes+&q=b

Habt ihr Ideen zur Lösung?

LG Oliver

 

[wolfgang]

Hast du alle Power savings abgeschaltet wenn das bei der NUC möglich ist?

 

[moustache]

Danke für den Hinweis, ich habe zwar alles abgeschaltet gehabt, aber nochmals alles überprüft und noch eine Saving einstellung gefunden. Also da ist gar nix mehr drin.

 

[wolfgang]

Versuch das in /etc/default/grub hinzuzufügen um den SW governor auszuschalten.

intel_pstate=disable

also die ganze Zeile lautet dann
GRUB_CMDLINE_LINUX_DEFAULT="quiet,intel_pstate=disable"

"update-grub" nicht vergessen und Rebooten.

 

[moustache]

Ich habe habe den governor deaktiviert wie oben erwähnt, ich habe gehofft, dass dies etwas hilft.

Allerdings nach ein paar Stunden ist der Sachverhalt mal wieder da und dort, aber schon deutlich weniger.
Will heissen Login auf console und vm hängt, console und auch via ssh ist die vm nicht mehr erreichbar. Was mir auch nun schon aufgefallen sit: ich mache eine ssh Verbindung zu vm und man startet was und vm hängt plötzlich, dieser fall ist aber eher selten. Oder ich bin in via console oder ssh drin und will rebooten. reboot steht dann einfach, minuten lang (obwohl nix auf vm läuft) und ohne STOP passiert nix. Das geht mal, mal nicht. also ein absolut doofes verhalten, weil nicht nachvollziehbar.

wenn ihr möchtet, kann ich Euch auch ein vm image openbsd 6.1 zur verfügung stellen, so dass ihr das näher untersuchen könnt.

ob es mit der upcoming 6.2 auch so läuft oder passiert kann ich aktuell nicht sagen.

 

[wolfgang]

Hab bei uns das gleiche Model der Nuc.

Hab mal alles aufgesetzt und lass das mal laufen.
Meld mich wenn ich was weis.

Hast du eigentlich auch den Turbo Mode ausgeschaltet, denn der kann auch Probleme machen.
Oder generell alles war die Cpu Frequenz verändert

 

[wolfgang]

Es sieht aus wie ein KVM bug den ich leider nur auf mehrer commits eingänzen kann

gitk bb3dd056ed1af9b186f0d9fe849eab78c51d14ce..813ae37e6aed72cc457094b6066aa38efd66c9e9

Ich werde das mal an die OpenBSD liste schicken vielleicht können die damit was anfangen.
Was mal auf alle Fälle sicher ist, es wird alle KVM gehosteten OpenBSD mit einem Kernel der neuer ist als 4.9 betreffen.

 

[moustache]

Hoi Wolfgang

Ich antworte gleich auf beide Deiner Antworten:

1. turbo mode war draussen, apmd aktiv und nicht aktiv (habe ich eben auch noch gedacht gehabt), immer das gleiche Verhalten, aber zeitlich mal dann oder dann. Eben nicht eingrenzbar. Wie wahrscheinlich bei Dir auf der Nuc oder anderer Intel Plattform auch.

2. Möglicher KVM bug, danke für Deine Spürnase;-) Dein Posting an misc@ habe ich gesehen. Hast Du dies auch als möglicher KVM denen gemeldet?

Grüsse, Oliver

 

[wolfgang]

2. Möglicher KVM bug, danke für Deine Spürnase;-) Dein Posting an misc@ habe ich gesehen. Hast Du dies auch als möglicher KVM denen gemeldet?

Es sind patches die den RTC und apic betreffen.
Ich kenne mich im OpenBSD nicht aus.
Wenn ich jetzt auf die KVM Liste einfach etwas schreibe wird mir dort keiner helfen ohne das ich genauer weiß was genau nicht geht.
Ich möchte erst eine eine Feedback der OpenBSD Liste haben.

 

[moustache]

Ich verwende als guests OpenBSD 6.1-stable and 6.1-release syspatched und kommenden OpenBSD 6.2, aktuell in snapshot 134.

Der Zusammenhang scheint sich hauptsächlich auf proxmox (pve)/kvm serial console (via noVNC) zu beschränken. Diese zu starten kann die VM zum Hängen bringen, manchmal gibt man username ein, enter, fertig. Oder ein erfolgreiches Login und dann hängt die Vm fest, nix aus Ende. Hohe cpu last und wie unten beschrieben. Dann ist auch ein ssh Login nicht mehr möglich, also man hat eine laufende und unkontrollierte Vm.

In meinen Installationen fielen mir die Hänger hautpsächlich via ssh ausgelöste reboot und shutdown -p now (in OpenBSD nicht mit -h!) auf:
Das System fährt korrekt runter, es erscheint die Meldung syncing disk....ok und spätestens da drehen die virtuellen CPUs (cores) rot auf über 100%, 102% oder auch 105% und es hat den Anschein als würde da was passieren (oder eben nicht!), weil die Prozessorauslastung sich immer wieder verändert. Aber gar nichts passsiert auch nicht nach Stunden des Wartens.
Mit halt - p bekomme ich jedenfalls zwischendurch einen sauberen Poweroff hin.

Update: Bei 6.2 scheinen die reboots immer mal wieder zu funktionieren. Aber auch nicht immer.

Ein paar Male hatte ich auch Hänger während einer aktiven ssh session (cvs up or compiling stable-kernel) oder es hängte sich während es Tages irgendwann auf. Keine log entries or dmesg auf Os Seite gibt ein Hinweis auf eine Richtung.

 

[wolfgang]

Ich sehe das problem als eins von OpenBSD.
Da OpenBSD 6.0 funktioniert und FreeBSD auch ohne Probleme läuft.
Es gibt auch keine anderen Guest OS das solche Probleme hat.
Wobei es aber Berichte von Ubuntu Usern gibt,die das gleiche Problem mit Ihren OpenBSD Guest haben.
Auf meine Anfrage auf der OpenBSD Liste ist leider keine Reaktion gekommen.

 

[moustache]

Zwei OpenBSD, die 6.0 und 6.1, funktionierte bei mir wunderbar mit Proxmox 4.4, mit reboots und problemlos über Wochen uptime etc. Also wenn das GuestOS gleich bleibt und hingegen seit Proxmox 5 bei mir und anderen Usern etwas nicht mehr so tut, glaube ich nicht, dass man das einfach so aufs GuestOS schieben kann. Ausschliessen tue ich und kann ich nicht, dass der Fehler bei OpenBSD liegt, nur Hin-und Herschieben der Problematik bringt niemandem einen Fortschritt.

Alle BSDs sind anderes, also wenn FreeBSD läuft, heisst das per se noch lange nicht, dass beispielsweise DragonflyBSD oder OpenBSD auch gleich und korrekt funktioniert. Die haben zwar alle einen ähnlichen Ursprung, gehen aber alle in eine eigene BSD-Richtung, immer irgendwie ähnlich aber doch nicht (jedenfalls mein Eindruck). Wenn bei Ubuntu Probleme mit dem GuestOS OpenBSD auftauchen zeigt mir das, auch daher weil Ubuntu und das in Proxmox 5.x unterliegende Debian mit Ubuntu-Kernel somit auf einer gleichen Kernel-Schiene (kvm) läuft, dass der hier erwähnte mögliche kvm bug wohl näher liegt als das GuestOS.

Dass und wieso keine Antwort von der OpenBSD Liste kam, da kann ich nichts dazu sagen. Ich weiss aber, dass wenn man traces und andere handfeste Facts liefert, dass wir da weiterkommen. Daher ich kann Euch im konstruktiven Sinne meine Labumgebung für Tests zu Verfügung stellen, damit ihr traces machen könnt, denn das Problem lässt sich zig Male 100% reproduzieren. Alternativ: Ich hingegen weiss da einfach nicht, wie ich was wo machen müsste, um traces und Fakten zu erhalten. Wenn ihr mich anweist, bin ich gerne bereit da Effort reinzugeben. Ich gehe davon aus, es wäre sowohl für Proxmox wie auch für OpenBSD gut, dass diese Kombi miteinander funzt.

Gehen wir doch gemeinsam schrittweise voran. -oliver

 

[wolfgang]

Dass und wieso keine Antwort von der OpenBSD Liste kam, da kann ich nichts dazu sagen. Ich weiss aber, dass wenn man traces und andere handfeste Facts liefert, dass wir da weiterkommen

Bitte lies was ich in diesen Thread geschrieben habe und behaupte nicht wir würden nichts tun.
Ich habe den Fehler auf mehre commit im Linux kernel eingegrenzt.
Wenn mir keiner erklärt was das bei OpenBSD macht kann ich auch nichts fixen.

 

[moustache]

Das ist nun wirklich ein Missverständnis. Da haben wir an-einander vorbei-geschrieben, mein Deutsch ist halt auch eher Rösti-mässig;-) Ich weiss doch, dass ihr da mithelft und das ist doch auch echt gut, auch ein anderer User hat Euch positiv in der Mailinglist von OpenBSD erwähnt. Daher auch mein Dank für Eure Bemühungen.

Ich meinte es so, dass wenn ich die Inhalte der OpenBSD-Mailingliste so ansehe, sehe ich, dass die am liebsten grad Code, diffs, traces, dmesgs, logeinträge etc. erhalten wollen und dann darauf mit einem Wenigzeiler antworten. Ich glaube, dass die von OpenBSD mit Linux Kernel commits nichts anfangen können/wollen(?), auch wenn das als einen guten Weg gedacht ist. Das könnte wiederum erklären, warum noch keiner sinnvoll geantwortet hat. Darum überlege ich mir einen anderen, gemeinsamen Weg (schliesslich sind ja nicht nur wir beide da dran), ich melde mich..

Falls ihr mein Lab benutzen wollt oder meine Mithilfe mit Anleitung, sehr gerne. -oliver

 

[moustache]

Meine zwei VMs Testumgebung habe ich nun mal auf das gestern erschienene OpenBSD 6.2-release upgegradet. Es dünkt mich vom ersten Eindruck an eher stabiler. Darum beobachte ich das mal für den Woche.

Den release-Upgrade auf -stable mache ich dann.

 

[wolfgang]

Ja halt uns bitte auf den Laufenden.
Ich hab den Fehler immer nach spätestens 30 min beim compilieren triggern können.

 

[wolfgang]

Hat das mit dem CPU auf einen anderen Typ setzen funktioniert?

 

[moustache]

Nein, im Gegenteil. Da blieb je nach CPU Typ auch plötzlich der Gast stehen während Betrieb. Mit Typ KVM64 funzts am Besten bislang.

 

[moustache]

Der upgrade auf OpenBSD6.2 vor einigen Wochen brachte keine Besserung.
Letzte Woche habe auf die neuste pve version upgegradet (subscription version) und da hat sich was merklich getan. OpenBSD 6.2 läuft seit Tagen, ebenfalls ist die Prozessorauslastung in der GastVM sehr viel niedriger als zuvor. Reboots sind nun möglich, ohne Hänger. Poweroffs (shutdown -p now) ebenfalls.
Hänger hatte ich nur vereinzelt, nämlich immer dann wenn ich im pve die NoVNC Console öffne, entweder es dauert einen Moment bis das Login erscheint oder es bleibt gleich alles wieder stehen, via ssh jedoch nicht. Wenns dann hängt geht der VM Prozessorload nicht wie vorher auf über 100% sondern, bleibt irgendwo bei 50-52%, warum auch immer.
Habe mich schon gefreut, doch vor wenigen Minuten VM gecheckt: gleicher Sachverhalt wie zu Beginn, Hänger während laufendem Betrieb, Prozessorload auf 102%.

Update Stunden später: Mein Testsystem ist komplett abgeraucht, pve lief nicht mehr richtig, WebGUI gar nicht mehr. Es liessen sich keine Dateien hochladen etc. Ich versuche mal zu retten, was es zu retten gibt, evtl hat sich klammheimlich eine SSD altershalber verwirrt. Gehe den Reinstall mal langsam an.

Daher schliesse ich nicht aus, dass da was hw-technisches bei mir mitspielte.

 

[moustache]

Testumgebung repariert (neue disk), bin auf PVE 5.1 mit neuem Kernel und gucke mal wie es sich so bewährt mit OpenBSD 6.2