Ist an dieser Stelle nur die VM gemeint oder setzt Du VM mit CT gleich?
Das ist gleichzusetzen, quasi alles was auf einem Host läuft, erzeugt Last. Egal ob das proxmox (es ist ein Päckchen aus zusammengeschnürten Diensten) an sich ist, ein weiterer Dienst auf dem Host oder eine VM, CT oder Dienste in einem der beiden ist. Der Trick ist, die vorhanden Ressourcen so zu verteilen und zu delegieren, dass du das so gut wie möglich für deinen zu erwartenden Einsatzzweck verteilst, aber die Grundregel ist dennoch dem Host immer was übrig zu lassen. Mit dicken CPUs und vielen Kernen ist das einfacher, meist rennt man aber eher durch den RAM ins Limit.
Wenn du 8 Kerne hast, dann behalte ich das für die Beispiele bei:
Hast du eine VM und dieser alle 8 Kerne zugewiesen, dann läuft das ok solange die Maschine idlet oder die Dienste darin nicht anspruchsvoll sind. Sobald darin aber ein Dienst alle Kerne in Beschlag nimmt, kämpfen VM und Host um die Ressourcen. Das bremst sich dann unnötig gegeneinander aus, da der Host die VM ausführen will, die VM dem Host aber die Butter vom Brot zieht. Quasi 8 Rentner am Rockzipfel eines Erwerbstätigen.
Ideal wäre, wenn eine VM ausreicht, 1x4 Kerne zugewiesen. -> Die VM kann Vollgas abrufen, nimmt die 4 Kerne in Beschlag aber dem Host bleiben immer 4 Kerne frei.
Hast du jetzt zwei VMs und beiden jeweils 1*8 Kerne zugewiesen (das geht!), dann geht das auch klar, solange alle idle sind. Ruft jetzt eine VM Vollgas ab, dann gehen alle VMs inkl. host in die Knie ...alles bremst sich gegeneinander aus.
Man kann jetzt jeder VM 4 Kerne zuweisen und dann safe Vollgas abwechselnd in den VMs abrufen. Laufen aber beide VMs gleichzeitig Vollgas, hat der Host wieder nichts für sich und der Kampf geht los.
Ideal hier wäre dann für zwei VMs: jeweils 1x2 Kerne. Eklig wird es dann, wenn man mehr als zwei VMs fahren will oder die Leistung bei 2 Kernen in der VM einfach nicht ausreicht. Dann kann man 6 Kerne aufteilen, damit dem Host 2 bleiben, aber drunter würde ich nicht gehen. Im Zweifel oder am Limit eher Abstriche bei der VM machen als beim Host, denn wenn der nicht atmen kann, 'strafst' du alle VMs ab.
Ob du das jetzt aufteilst nach Kernen, Threads oder prozentual, das gibt sich nichts und wenn, dann nur marginal und allenfalls mit Benchmarks feststellbar.
Mit der Verteilung vom RAM wäre ähnlich zu verfahren (primär mal 50% für den Host lassen und nicht 'verplanen') und dann gucken wie sich das so entwickelt. Gerade nach ein paar Tagen uptime sieht man dann schon mehr und meist wird man dann auf den Boden der Tatsachen geschleudert. Z.B. dass 64GB RAM doch nicht so gigantisch sind, wie gedacht.
VMs: 1 * 1 Core + 1 * 2 Core
CT: 4 * 1 Core
Wäre ohne die Differenzierung zwischen CT und VM schon hart am Limit? Mit diesen "Maschinen" decke ich meine Netzwerkbedürfnisse ab. Da die CPU und RAM Auslastung dennoch niedrig sind, wollte ich ein paar Maschinen zum lernen aufsetzen. Klar, die Ziehen Ressourcen, aber das wäre bei mir zweitrangig.
Wie gesagt, solange alles idle ist und bleibt, passt das. Wichtig ist, dass du keiner VM die 'Macht' gegeben hast, dass sie alle Kerne auf einmal abrufen könnte.
Wie bekommt man es dann hin, dass die "langsamen Maschinen" die trotz ihrer bringen Anforderungen diese immer bekommen, auch wenn eine Maschine gerade Vollgas gibt?
Die Zuweisung der Kerne bilden das Limit je VM, an den freien bedienen sich dann die anderen.
An welcher Stelle wird das gesetzt? Und wenn ich den Hinweis von @Dunuin lese, dann würde ich die Option so verstehen, dass der Host der Machine eher nicht gestattet mehr RAM zu nehmen.
vm.swappiness=0 in
/etc/sysctl.conf auf dem Host + reboot.
Das setzt aber eine vorhandene swap-Partition voraus und ich bin mir jetzt gerade aber nicht sicher ob deine Frage auf swap auf dem Host oder in einer VM abzielte.
Unter Ballooning verstehe ich den Effekt, dass der Maschine zwischen min. RAM und max. RAM dieser dynamisch zugewiesen wird.
So ist es. Das geht aber nur, wenn der Host den RAM auch in 'frei' vorliegen hat. Nicht vorhandes kann auch nicht zugewiesen werden.
Und so wie ich jetzt deine Antwort lese, Das Kriterium der Zuweisung nicht von der Maschine selbst bestimmt wird, sondern vom Host?
Der Host bestimmt wo es langgeht und ist der Boss, nicht die VM. Das klingt jetzt verwirrend, weil ich oben schrieb, dass die VM Leistung zieht (nicht selbstbestimmt, obwohl es so klingt), aber das eigentliche scheduling läuft dennoch auf dem Host ab. Eine VM ist technisch auch nur ein Dienst, den der Host ausführt.
Hast du 8GB Min und 16GB max RAM gesetzt und brauchen deine Services z.B. 12GB, dann wird dir Windows 4GB an Services killen müssen, damit es noch mit den 8GB RAM auskommt, nachdem Ballooning 8GB RAM entfernt hat.
Richtig, das muss man noch erwähnen! Daher lieber generöser den RAM verteilen als Kerne oder anders: lieber ein paar Sekunden Wartezeit in Kauf nehmen, als abgeschossene Dienste.
Und nutzt die VM PCI Passthrough, dann klappt kein Ballooning.
Ich hatte das zwar aufgeschnappt, aber war der Meinung, dass das nur für GPU passthrough + den VRAM galt? Ich nutze das nämlich mit einem HBA und die VM rennt mit ballooning...
