Gibt es mit PVE 2.x ggf. Änderungen bei der RAM-Nutzung, bzw. deren Anzeige bei VMs?

[jim_os]

Hi @Impact

Das is eine gute Frage - nächste. Nein mal Spaß beiseite. Auch wenn ich Proxmox schon ein paar Jahre nutze, komme ich dabei an einen Punkt an dem mir etwas Wissen fehlt. Die CLI Befehle müsste ich doch eigentlich im Command Mode bei der NAS VM ausführen, oder? Dazu müsste ich dort erst einmal SSH + Terminal einrichten - was ich bisher noch nicht gemacht habe. Oder kann ich über die Proxmox PVE Shell diese Daten auch für eine VM abfragen?

Aber mal unabhängig davon was jetzt bei free -h herauskommt. Die Memory usage Anzeige bei der VM bleibt ja dauerhaft auf > 100%. D.h. wenn da ggf. irgendein Cache/Buffer oder Swap eine Rolle spielen sollte, dann sollte sich die Anzeige ja irgendwann auch wieder normalisieren, eben weil der Gast ja das RAM gar nicht mehr benötigt und die NAS Software selber den RAM-Verbrauch dann ja auch korrekt anzeigt. Auch bei meinen anderen VMs (z.B. Home Assistant , OMV ...) hier funktioniert das ja problemlos, nur eben bei der NAS VM nicht.

Ich vermute mal das irgendetwas mit dem Ballooning bei der NAS Software nicht "stimmt/passt" und sie liefert bei info balloon ja auch einfach nur so etwas zurück

balloon: actual=10240 max_mem=10240

und nicht wie die anderen VM dann so etwas in der Art.

balloon: actual=6144 max_mem=6144 total_mem=5924 free_mem=1782 mem_swapped_in=0 mem_swapped_out=0 major_page_faults=20434 minor_page_faults=89525157 last_update=1779697106

Darum hatte ich ja auch schon geschrieben das es jetzt wohl schwierig werden dürfte die genaue Ursache und den "Übeltäter" dafür zu finden. Da es hier bei mir eben nur die NAS VM betrifft und die anderen VMs Memory usage korrekt anzeigen, wird es wohl an der NAS Software liegen und das ist etwas was weder Proxmox noch ich ändern kann. Zumindest wüsste ich nicht wie.

VG Jim

 

[Impact]

Ich nutze DSM nicht selbst, kann dir daher nicht so genau sagen wie man das am besten macht oder warum es nur wenige Werte zurückgibt. Vermutlich ein spezieller bzw. veraltetet Kernel? Eventuell funktioniert es sich direkt über noVNC einzuloggen. Ansonsten halt SSH und dann sudo -i.
Hier ein bisschen Info zum Linux Caching. Versuche hier auch (nach dem du meine Befehle benutzt und dessen Ausgabe notiert hast) auch mal den drop_caches Test der dort beschrieben ist. Ein NAS arbeitet ganz anders mit seinen Daten. Die Befehle sollten hier aber Aufschluss geben.

 

[TErxleben]

Welche OMV-Version nutzt du denn? Aktuell ist 8.2.14-3 (Synchrony)

 

[jim_os]

Ich nutze hier schon seit über 10 Jahren Synology NAS und aktuell zwei Stück. Das mit DSM virtualisieren war bzw. ist eher zum "spielen", weil ich auch schon seit Jahren OMV als NAS Software nutze. Früher halt bare metal und seit dem ich Proxmox nutze eben dort als VM.

D.h. wenn jetzt die RAM-Anzeige bei PVE für die DSM-NAS-VM nicht mehr (richtig) funktioniert dann ist das kein Beinbruch für mich. Für mich war halt wichtiger die mögliche Ursache dafür zu finden. Das ich das Problem dann ggf. nicht beseitigen kann, weil ich selber eben nicht "mal eben" an dem Loader, DSM oder PVE etwas ändern kann, ist dann eben so.

BTW ändern und mal eben ganz spontan probiert: Das Ballooning für die NAS-VM zu ändern, sprich zu deaktivieren


ändert auch nichts. Die Memory usage Anzeige kennt nur einen Weg und zwar nach oben. D.h. unter Last und somit steigenden RAM-Bedarf, "schaukelt" sich die Memory usage Anzeige immer weiter nach oben und wenn sie dann am Anschlag (> 100%) ist bleibt sie dort auch dauerhaft.

Vielleicht hat @aaron ja noch irgendeine Idee was ich mal machen/testen könnte, aber ich will das Memory usage Problem hier ja auch nicht für mich, oder gar Euch, zum Dauerthema machen. Das hat mich eh schon viel zu viel Stunden gekostet. D.h. wenn niemand eine Lösung aus dem Hut zaubert kann und werde ich damit leben. Wie gesagt ist die DSM-NAS-VM eh nur zum "herumspielen" da.

@TErxleben Ne es geht nicht um ein/meine OMV VM - bei der funktioniert alles - sondern um eine virtualisierte Synology DSM Version.

VG Jim

 

[Impact]

Ich wäre wirklich an den Ausgaben der Befehle interessiert.

 

[jim_os]

Vermutlich ein spezieller bzw. veraltetet Kernel?

Jepp DSM nutzt immer noch einen Asbach Uralt Kernel 4.x. Wie ich auf den Command Mode von DSM zugreife ist mir bekannt. Auch die Infos auf der verlinkten Seite wie Linux mit RAM umgeht. Trotzdem natürlich danke dafür. Letztendlich geht es hier ja auch nicht darum wie DSM dann RAM wann, wie und wofür verwendet, sondern einfach nur darum das die "Kommunikation" zwischen PVE und DSM bzgl. RAM - warum auch immer - nicht funktioniert. Das das dann eben auch Auswirkungen auf den Host hat, weil er per Ballooning anderen VMs dann keinen frei gewordenen Speicher zuweisen kann, ist klar. Für PVE sieht es eben so aus als würde die NAS VM immer noch 100% vom RAM brauchen.

Wenn DSM den RAM wieder freigibt - was es ja macht - aber diese Infos nicht (richtig) bei PVE ankommt, dann ist das eben so. Das hat nicht wirklich etwas damit zu tun wie Linux RAM nutzt, sondern ist m.M.n. einfach nur ein "Kommunikationsproblem" zwischen PVE <---> Loader <---> DSM. Ob das jetzt erst mit PVE 9.2.2 und Kernel 7.x aufgetreten ist kann ich nicht zu 100% sagen, aber ich bin mir recht sicher das es das Problem früher noch nicht gab. Warum kann ich das nicht genau sagen: A) Weil ich eben die DSM VM nicht produktiv nutze und genutzt habe und somit vielleicht nur alle paar Wochen mal eher zufällig einen Blick auf deren Summary Anzeige geworfen habe und B) weil ich hier jetzt keinen Proxmox Host mit einer älteren PVE und Kernel Version mehr am laufen habe und nur dafür jetzt auch nicht noch extra neu einrichte.

VG Jim

 

[TErxleben]

Hast dur die DSM-VM mal heruntergefahren und geguckt was der PVE-Host dann anzeigt? Wenn dessen Anzeige sich normalisiert, hast du den schlimmen Finger identifiziert.
Allerdings empfinde ich dein "Konstrukt" als recht exotisch. OMV ist ein SW-Produkt, Synology ist in meinen Augen eher ein HW-Produkt mit eigener SW-Basis.
Warum betreibst du das überhaupt in einer VM, statt das Ding direkt auf der vorgesehenen Baremetal-Kiste?
Irgendwie liegt es doch auch auf der Hand, dass die Systeme auseinender driften. ich sage nur 4er-Kernel.

 

[jim_os]

Wenn dessen Anzeige sich normalisiert,

Ja klar geht die Memory usage Anzeige für die DSM VM dann wieder auf Null und ja der "schlimmer Finger" ist halt das die Kommunikation bzgl. Memory usage zwischen PVE <---> Loader <---> DSM nicht (mehr) funktioniert. Das war ja schon klar.

Warum betreibst du das überhaupt in einer VM, statt das Ding direkt auf der vorgesehenen Baremetal-Kiste?

Die Standard-Antwort auf diese Frage lautet: Weil ich/man es kann. Nein mal Spaß beiseite. Warum sollte ich hier nur für DSM noch eine extra Kiste laufen lassen, wenn das ganze auch als VM unter Proxmox funktioniert. Zumindest hat es da ja eine lange Zeit lang zu 100% und andere User nutzen das ja auch schon viel länger (x Jahre) als ich. Das das z.T. immer ein "Hase und Igel Spiel" war/ist, sprich das es nach irgendwelchen DSM-Updates immer mal wieder zu Problemen kam bzw. kommt, ist ja hinlänglich bekannt. Daher würde ich so etwas ja auch nie als produktives System nutzen. Wozu auch, dafür habe ich ja meine Synology NAS und eben auch noch OMV. Trotzdem ist es etwas mit dem ich auch "herumspiele", genau so wie ich das auch z.B. mit TrueNAS Scale mache. Das ich etwas mehr mit einer virtualisierten Version von DSM herumspiele liegt halt daran das ich Synology NAS eben schon sehr lange (> 10 Jahre) nutze und mich somit mit DSM entsprechend auskenne.

dass die Systeme auseinender driften.

Jepp auch das ist klar, aber bisher gab es eben dieses "Problem" mit der Memory usage Anzeige für eine DSM VM unter Proxmox nicht. Wenn sich das jetzt - warum genau auch immer - geändert hat dann ist das eben so. Wie gesagt kann ich damit leben.

VG Jim

 

[TErxleben]

Ich zielte eher auf die PVE-Übersicht, als auf Werte einzelner VMs.
Wenn du Zeit und Lust hast, solch seltsames Verhalten zu verfolgen, spricht natürlich nichts dagegen.
Aber einen potentiellen, anderen Hypervisor virtualisiert zu betreiben, rangiert für mich unter "Ich schaffe mir Probleme um die Ursachen zu ermitteln", die überflüssig/sinnlos sind.
Ich hätte es längst unter "zwar möglich, aber problembehaftet" abgelegt. Allerdings kann man jemandem, der mit solchen Ideen herantritt, glaubhaft und guten Gewissens vermitteln, warum das eine schrullige Idee ist.

 

[jim_os]

Aber einen potentiellen, anderen Hypervisor virtualisiert zu betreiben, rangiert für mich unter "Ich schaffe mir Probleme um die Ursachen zu ermitteln", die überflüssig/sinnlos sind.

Ähm - DSM ist nichts anderes wie es z.B. auch Unraid, TrueNAS, OMV usw. ist. Es ist einfach nur ein Linux BS, das zusätzlich auch noch virtualisieren kann/könnte. Das DSM halt auf einem sehr alten Linux Kernel basiert ist dann ein anderes Thema. Auch ist es ein anderes Thema welches Linux BS User dann unter Proxmox virtualisieren oder nicht und warum sie das machen.

rangiert für mich unter "Ich schaffe mir Probleme um die Ursachen zu ermitteln", die überflüssig/sinnlos sind.

Ich bin mir eigentlich ziemlich sicher das auch Du schon mir irgendwelchen Dingen "herumgespielt" hast, um dann irgendwann festzustellen das etwas ggf. überflüssig oder sinnlos war. Und sei es nur - wie in dem Fall - weil sich etwas bei einer von Dir genutzten Software geändert hat, auf das Du ggf. gar keine Einfluss hattest.

warum das eine schrullige Idee ist.

Schrullige Ideen gibt es viele, aber ein Linux BS unter Proxmox zu virtualisieren zähle ich jetzt nicht wirklich dazu. Wie gesagt hat das mit DSM ja auch seit Jahren funktioniert - zumindest nutze andere User das bereits seit Jahren so - aber jetzt scheint es eben wohl nicht mehr zu 100% zu funktionieren.

Meine Betreffzeile hier lautet: "Gibt es mit PVE 2.x ggf. Änderungen bei der RAM-Nutzung, bzw. deren Anzeige bei VMs?" und den Beitrag habe ich erstellt weil mir eben die erwähnten Unterschiede aufgefallen sind. Ich weiß jetzt das sich das Verhalten der Memory usage Anzeige (und somit vermutlich auch das Thema RAM-Freigage bei der PVE DSM VM) verändert hat und das ich selber daran wohl nichts ändern kann. Somit ist meine ursprünglich Frage geklärt.

Ja mir ist schon klar was Du mit schrullige Idee usw. meinst, aber falls Du - so wie ich - noch ein mit Benzinmotor betriebenes Autos fährst, wirst Du vielleicht bereits jetzt, oder ggf. in ein paar Jahren dazu von Usern vielleicht hören was das doch für eine "schrullige Idee" ist. D.h. Du könntest Dein Auto ja jetzt - oder schon lange - auch als

"zwar möglich, aber problembehaftet" abgelegt

Vielleicht verstehst Du worauf ich hinaus will, auch wenn der Vergleich natürlich hinkt.

Ich warte jetzt darauf ob dazu von den Mädels und Jungs von Proxmox ggf. noch jemand eine Idee hat und ansonsten ist das Thema für mich hier durch.

VG Jim

 

[TErxleben]

Sollte auch nie Kritik sein. Freut mich sogar, wenn du dir die Mühe machst, solchen Nickligkeiten auf den Grund zu gehen. Wie du erwähnst hast, verfüge ich auch über viel Spieltrieb Darum meine Frage, ob sich das Anhalten der DMS-VM bis auf den PVE-Host reproduzierbar durchschlägt. Deine beiden ersten screenshots zeigen schon einen erheblichen alt/neu Unterschied, obwohl sich die Kisten nicht wesentlich unterscheiden.

 

[jim_os]

Wie du erwähnst hast, verfüge ich auch über viel Spieltrieb

Hätte mich jetzt auch gewundert wenn das nicht der Fall wäre.

Deine beiden ersten screenshots zeigen schon einen erheblichen alt/neu Unterschied, obwohl sich die Kisten nicht wesentlich unterscheiden.

Ja dazu sollte ich vielleicht noch etwas klarstellen. Als ich die Screnshots in #1 gepostet habe, sprich den von der Fujitsu Kiste mit PVE 9.1.9 mit Kernel 6.17.13-3-pve



und den von der Lenovo Kiste mit PVE 9.2.2 mit Kernel 7.0.2-6-pve



hatte ich zu dem Zeitpunkt keinen "Belastungstest" (z.B. viele GB an Dateien kopieren) bei der Fujitsu Kiste mit PVE 9.1.9 und Kernel 6.17.13-3-pve gemacht. D.h. es ist durchaus möglich das dieses "Memory usage Anzeige Problem" auch schon bei der Fujitsu Kiste mit PVE 9.1.9 und Kernel 6.17.13-3-pve aufgetreten wäre. Was ich nur zu ca. 99 % sagen kann ist das es dieses Verhalten nicht schon immer so gab. Das es erst mit dem Kernel 7.x auftritt ist allerdings naheliegend, weil mir das ansonsten wohl auch schon vor 3, 6 oder vielleicht auch 9 Monaten aufgefallen wäre.

Das erst eine Belastung die Memory usage Anzeige der VM so in die Höhe treibt und sie dann eben bei > 100 % dauerhaft bleibt, ist mir erst heute klar und deutlich geworden. Ja das hätte ich so auch schon eher testen und somit feststellen können.

Das die überwiegende Anzahl von Usern DSM vermutlich nicht virtualisiert sondern bare metal nutzt und das man von Proxmox nicht verlangen kann auf irgendeinen Asbach Uralt Kernel von irgendeinem Linux BS Rücksicht zu nehmen, ist schon vollkommen klar. D.h. ich selber hake das für mich nicht unter einer "schrullige Idee" ab, sondern jetzt eher als ein es war "nice to have" und nicht als ein "must have".

VG Jim

 

[TErxleben]

Ich habe nun, dank dieses Gedankenaustauschs, gedanklich abgelegt, dass ein VM-Kernel v4, durchaus problembehaftet (funktionell?) in Verbindung mit einer qemu-Version unter einem Host-Kernel v7 ist. Wäre unerwartet und ätzend, da die Kapselung in einer VM dann doch Macken hat und nicht ganz so, wie erwartet funktioniert. Wenn die DSM-VM aber sonst ordentlich funktioniert würde ich ein Ei drauflegen und es aufs PVE-GUIs schieben.
Hast du denn mal gemessen, ob reale Last/Zeiten auf den unterschiedlichen VMs existieren?

 

[Impact]

Wenn DSM den RAM wieder freigibt - was es ja macht

Ja, aber nicht unbedingt den Cache. Werden viele Dateien gelesen steigt dieser und PVE inkludiert das. Mit den Augaben der Befehle kann man da auch konkret etwas dazu sagen. Ich verstehe nicht so ganz warum es so schwierig ist dir diese Information zu entlocken.

 

[jim_os]

Moin

Ich bin für jede Hilfe grundsätzlich dankbar, aber weil ich auch noch mehr zu tun habe muss ich auch Prioritäten setzen. Das Ergebnis der Abfragen ändert halt nichts daran das ich an dem Zustand ja nichts ändern kann.

Vorab die free -h Abfrage beim Host



Aktuelles Summary bei dem Gast


Aktueller RAM Verbrauch lt. Gast




Abfragen beim Gast



Nun muss ich mich erst einmal wieder um andere Dinge kümmern und bin offline.

VG Jim

 

[GMBauer]

Ich glaube, ich habe sehr weit oben geschrieben, dass der Jumping Point der Cache-Speicher vom DSM ist.

Der wird in der Speicheranzeige der DSM-Software ignoriert, aber halt natürlich nicht vom HV. Und dann balloont sich natürlich auch nichts. Die DSM-Software erwartet, dass eine Datei, die mal aufgerufen wird, später wieder aufgerufen wird und behält sie im Cache. Solange, bis diese Daten von was anderem verdrängt werden oder das Gerät resettet wird.

Ich habe es nie geschafft, in einem virtuellen DSM den Cache leer zu bekommen. Und das war unter Kernel 6 auch schon so. Ich bin vor exakt zwei Jahren zu Proxmox gekommen (habe heute das Lob vom Forum-Roboter für zwei Jahre dabei bekommen) und da habe ich dann sehr schnell auch DSM installiert. In meiner "Hochphase" reichte ich einen ASmedia 1166 durch auf vier HDDs. Auch da hatte ich das Problem des minimal über 100% stehenden RAMs. Habe auch die verschiedensten Bootloader ausprobiert.

Bin allerdings nach ungefähr einem Jahr - aus Sicherheitsgründen und weil die virtuellen Systeme zicken, wenn man Updates macht, - von virtuellen DSMs weg auf echte Synology-Hardware. Meine erste Syno war übrigens eine 918, die mit dem mittlerweile dritten Netzteil und jetzt einem 2,5-GBit-Dongle immer noch perfekt läuft.

 

[Impact]

Hmm. Wie erwartet ist alles im Cache. Da würde auch ein anderes OS oder ein anderer Kernel nicht wirklich helfen da das von PVE als benutzt berechnet wird.

Du kannst probieren den Cache so zu leeren und der Wert sollte runter gehen. Ist halt nur nicht sonderlich hilfreich.

echo 3 > /proc/sys/vm/drop_caches

Da du den Namen zensiert hast arbeitest du wohl nicht als root. Solltest du für so etwas aber.
Das Verhalten sieht für mich normal aus. Ich kenne es von PVE nicht anders.

 

[jim_os]

arbeitest du wohl nicht als root. Solltest du für so etwas aber.

Doch es gibt bei DSM keinen User "root" und der User über den ich eingeloggt bin hat natürlich Root-Rechte.

VG Jim

 

[Impact]

Probier mal sudo -i und lasse den fehlgeschlagenen slabtop Befehl dann erneut laufen. Ist aber nicht so wichtig. Das zeigt dir nur was den Cache ausmacht,