Umwandeln weil Notlage RAM

T

Thabeus

New Member
Proxmox Subscriber
Dec 4, 2024
8
7
3
Guten Tag,
ich habe mehrere Maschinen von einem ESXI zu Proxmox konvertiert und es läuft alles super.
Leider ist eine Maschine jetzt zu langsam und soll zurück auf die alte Hardware.

Die VM hat nur Laufwerk C aber ist 1TB groß.
Ich würde daher gerne die VM (runterfahren) dann konvertieren so das ich sie zum esxi verschieben kann und dort wieder starten kann.
Die VM liegt auf einem ZFS und wenn ich das richtig sehe ist das Dateiformat RAW.

Leider steck ich noch nicht so tief in der Materie.

Wo finde ich eine Anfänger Anleitung, wie ich die Maschine konvertieren kann um sie danach per WINSCP zum ESXI zu kopieren und neu einzuhängen die VHD.

Beide Server können sich per SSH erreichen, jedoch sind meine "Linux Kenntnisse" eher rudimentär bis hin zu nicht vorhanden.

Ich wäre über jede verständlich Hilfe sehr dankbar.

LG
Thabs
 
Und die migrierte VM hast auf dem ESXi vorausschauend gelöscht statt nur herunterzufahren?
Du kannst das mit dem VMware Standalone Converter aus der Laufenden VM wahrscheinlich am sichersten und effektivsten durchführen.
 
Thabeus said:
Ja, die alte vm ist noch da. Werde die wieder aktivieren.
Ich gebe Rückmeldung nach Umsetzung
Click to expand...
Und wenn die neue zu langsam ist, liegt es oft nur an kleinen Einstellungen. Die default Settings sind bei PVE etwas konservativer als beim ESXi.
 
Nein, leider fehlt der Hardware RAM das steht fest. Lief alles super bis eine Maschine dazu kam.
Aber das lässt sich lösen, aber die Preise aktuell sind krass für ram.

Ich denke es gibt sicherlich einiges was man optimieren könnte, aber dafür bin ich noch zu frisch.
 
Thabeus said:
Nein, leider fehlt der Hardware RAM das steht fest.
Click to expand...
Um ein paar Prozent Ram-Entlastung zu erzeugen taugt das hier:
Code: 
# apt show zram-tools
Homepage: https://github.com/highvoltage/zram-tools

zram-tools uses this module to set up compressed swap space.
 This is useful on systems with low memory or servers
 running a large amount of services with data that's easily swappable
 but that you may wish to swap back fast without sacrificing disk
 bandwidth.
 
  • Like
Reactions: Johannes S
@Thabeus,

da du ZFS nutzt: Standardmäßig belegt der ZFS ARC bis zu 50% des RAMs als Cache. Das sieht in der GUI oft wie ein tatsächlicher Engpass aus, ist aber meist unproblematisch, da dieser Speicher bei Bedarf für VMs freigegeben wird.

Solltest du es irgendwann nochmal probieren wollen: Begrenze den ARC Max-Wert manuell. Wie @Falk R. schon angedeutet hat, liegt gefühlte "Langsamkeit" oft eher an fehlenden VirtIO-Treibern oder nicht optimalen Disk-Cache-Settings (z.B. Writeback) statt am reinen RAM-Volumen.
 
  • Like
Reactions: Johannes S
Dieser Standardwert ist auch nicht mehr unbedingt 50%: Zum einen weil seit PVE 8.4 ( oder früher, aber irgendwann zu einer PVE8-Version) der Intaller von ProxmoxVE bei der Installation den ARC -Cache auf 10% (und maximal 16GB) des zu dem Zeitpunkt verbauten RAMs begrenzt: https://pve.proxmox.com/wiki/ZFS_on_Linux#sysadmin_zfs_limit_memory_usage

Zum anderen weil die in PVE9 und PBS4 verwendete ZFS-Version den Default auf 90% angehoben hat, dafür aber was am Verfahren zur Wiederfreigabe geändert. Bei PVE9 greift weiterhin der Installer-Default (also 10% - 16GB ), beim PBS4 dagegen tatsächlich die 90%. Nur: Gerade bei einen Backupserver ist es ja durchaus ganz praktisch, wenn der seine Daten aus den RAM-Cache statt von deutlich langsameren Platten ziehen muss (und auch SSD ist lahmer als RAM), daher finde ich das Verhalten da schon ok. Anpassen kann man das in beiden Fällen, wie das geht, steht im verlinkten Wiki Artikel.
 
  • Like
Reactions: UdoB
UdoB said:
Um ein paar Prozent Ram-Entlastung zu erzeugen taugt das hier:
Code: 
# apt show zram-tools
Homepage: https://github.com/highvoltage/zram-tools

zram-tools uses this module to set up compressed swap space.
 This is useful on systems with low memory or servers
 running a large amount of services with data that's easily swappable
 but that you may wish to swap back fast without sacrificing disk
 bandwidth.
Click to expand...

Die haben auch eine eigene Wikiseite im Proxmoxwiki: https://pve.proxmox.com/wiki/Zram#Alternative_Setup_using_zram-tools

Und wären generell auch meine Empfehlung, auch wenn man natürlich keine Wunder erwarten sollte. Sie kosten dabei aber auch etwas CPU-Load (irgendwie müssen die Daten ja komprimiert werden müssen. Im Normalfall habe ich bei mir aber eher zuwenig RAM als zu wenig freie CPU-Kapazitäten
 
  • Like
Reactions: UdoB
Ich bin auch der Meinung, man kann beim RAM sehr oft noch etwas optimieren.
In jeder Maschine die typische RAM Auslastung anschauen, einen GB hinzu addieren, fest einstellen ohne Ballooning. Notfalls soll die Maschine selbst intern SWAP betreiben.
Empfehlung gilt nicht, sofern es sich um eine VDI Maschine handelt, also User darauf arbeiten.

ZFS ARC Cache reichen aus meiner Sicht 4 GB, sofern nicht bereits noch geringer eingestellt.
Für den Host sollte der Onboard-Graphik RAM (bei Intel oft < 500 MB), zzgl. ZFS ARC Cache, zzgl. 1 GB für Proxmox selbst reserviert sein.

Dann kann man sich leicht ausrechnen, ob der RAM passt:

Festgelegten RAM aller VMs nach obiger Methode
+ ZFS ARC Cache (ca. 1 - 4 GB)
+ 0,5 GB Graphik RAM (individuell prüfen und auch im BIOS ggf. reduzieren, wenn möglich [bei einigen AMD Systemen ist der auf 2 GB eingestellt])
+ 1 GB Proxmox Host

Sollte kleiner oder gleich sein als der im Rechner verbaute RAM. Wer wirklich Not am Mann hat, kann den ARC auf bis zu 1 GB runterschrauben.
Ich nutze keinen zRAM, keinen KSM, kein Ballooning, weil das aus meiner Sicht im Ernstfall die Stabilität beeinflusst.
Dieses Vorgehen führt oft aber zu erheblichen Einsparungen. DIe meisten Systeme sind arg überdimensioniert und mehr RAM als benötigt wird bringt fast keine Vorteile.

Habe ich dann noch RAM übrig, würde ich GB-weise den Maschinen mehr zuweisen und mit dem ARC auf bis zu 4 GB gehen. Die Maschinen mit der größten Variabilität (VDI/RDP Maschinen, SQL Server, Anwendungsserver, DCs in dieser Reihenfolge) bekommen als erstes mehr RAM. Für einen DC reichen oft 3 GB. Anwendungsserver kommen oft mit 8 GB aus.

Ich hab schon Rechner gesehen für 3-Mann Buden, da hat man 'vorsorglich' 192 GB verbaut, den 3 VMs (DC, Anwendungsserver, VDI Host) je 32 GB zugeordnet, der Rest lag brach, obwohl der RAM alleine 2000 € gekostet hat.
Ausgereicht haben dann 3 GB für den DC, 8 GB für den Anwendungsserver und 32 GB für den VDI.
Letzteren habe ich nach zwei Monaten abgeschaltet, weil den MA lokales Arbeiten ohnehin lieber war. Einmal mit Profis arbeiten.


Quizfrage:
Warum sind die Ansichten von mir und z.B. Johannes S. so unterschiedlich?
Weil ich meinem Vorschlag der RAM je Maschine schon aufs äußerste getrimmt wurde. In einem solchen Fall ist die Wahrscheinlichkeit hoch, dass auf dem Host einfach keine Reserven übrig sind für KSM, Ballooning oder zRAM und bei eine Überbuchung führt das Ausführen eines RAM intensiven Prozess in einer VM zu einem Out of Memory auf der Host Seite.

5 VMs mit je 8 GB 'zuviel' RAM führt im statistischen Mittel sehr viel seltener zu einem OOM auf Host-Seite und ein klein wenig Überbuchung kann sehr lange sehr gut gehen.

Ich dimensioniere bei mir auch nicht jede VM 'bis aufs äußerste', aber das wäre mein Vorgehen bei akuter Knappheit.
 
Last edited:
  • Like
Reactions: Johannes S
@ivenae,

das ist ein sehr pragmatischer Ansatz. Gerade bei akuter Knappheit ist das Eliminieren von Variablen (Ballooning, KSM) oft zielführender als das Hoffen auf deren Effizienz. Wie @Falk R. bereits anmerkte, sind die PVE-Defaults oft konservativ – dein manuelles Vorgehen umgeht das effektiv. Für @Thabeus dürfte das die schnellste Lösung sein, um die VM ohne Hardware-Upgrade stabil zu bekommen.
 
  • Like
Reactions: Johannes S
Guten Morgen,
vielen Dank für den Input. Ich habe jetzt mal eine RAM lastige Maschine auf den alten ESXI zurück geschoben bzw. dort wieder aktiviert und es ist alles wieder super. Ich habe leider ein RAM Problem, das kann ich anpassen wo viel wie ich will, das würde am ende verbesserung schaffen, aber leider nicht die Lösung.
Daher werde ich zu sehen das wir RAM bekommen, wenn endlich lieferbar.
Die Maschine selber hat sonst keine Performance Probleme.
CPU(s)​

64 x AMD EPYC 9124 16-Core Processor (2 Sockets)​
Kernel Version​

Linux 6.8.12-16-pve (2025-10-14T08:58Z)​



und 5x 2 TB NVME SSD
Leider aber 9VMs und aktuell nur 256GB RAM
Der alte ESXI hatte rund 750GB RAM und da waren keine Probleme. Ein TS ist leider der RAM Fresser, da lässt sich leider kaum was ändern.
Aber wir haben uns erstmal beholfen und die beiden TS auf dem ESXI wieder laufen und die Probleme sind "verschoben" und die 7 VMs auf dem Proxmox laufen super schnell.
 
  • Like
Reactions: Johannes S and ThoSo
Wenn du, was derzeit ja eher unüblich ist, einen Dual Socket AMD Sever nutzt, muss du natürlich auch auf NUMA achten. Bei 256 GB RAM was auch eher ungünstig aufgeteilt sein muss, sind ja nur 128GB pro CPU.
Bei den AMD Servern haben wir 12Channel RAM Support, also vollen Speed nur mit mindestens 12 RAM Riegel je CPU.
 
You must log in or register to reply here.
Top Bottom