Win11 ewige Baustelle

Der Host-Graph ist gar nicht so langweilig. Die Verwendet-Linie liegt die ganze Woche knapp unter Total, nur ein paar Dips nach unten. Genau da fängt PVE an, die Ballons aufzublasen, ab grob 80% Hostbelegung geht das los. Es trifft zuerst die VM mit der größten Spanne zwischen min und max - bei 8/32 ist das deine Datev-Kiste.

Ja, Ballooning entzieht da was. Der Balloon-Treiber reserviert im Gast Speicher wie jedes andere Programm auch und gibt die Seiten dann an den Host zurück. Windows muss Platz schaffen, Working Sets schrumpfen und auslagern, und meldet dann zu wenig Arbeitsspeicher.

Der Rückgang von 32 auf 12 kann vom Ballon stammen, nicht davon, dass Windows den Speicher freiwillig hergibt.

Was sagt denn max server memory jetzt? Wenn da noch der Default drinsteht, ziehen SQL und der Ballon gleichzeitig am selben RAM, und dann wirds wirklich unschön.
 
  • Like
Reactions: ThoSo
Der Host-Graph ist gar nicht so langweilig. Die Verwendet-Linie liegt die ganze Woche knapp unter Total, nur ein paar Dips nach unten. Genau da fängt PVE an, die Ballons aufzublasen, ab grob 80% Hostbelegung geht das los. Es trifft zuerst die VM mit der größten Spanne zwischen min und max - bei 8/32 ist das deine Datev-Kiste.

Ja, Ballooning entzieht da was. Der Balloon-Treiber reserviert im Gast Speicher wie jedes andere Programm auch und gibt die Seiten dann an den Host zurück. Windows muss Platz schaffen, Working Sets schrumpfen und auslagern, und meldet dann zu wenig Arbeitsspeicher.

Der Rückgang von 32 auf 12 kann vom Ballon stammen, nicht davon, dass Windows den Speicher freiwillig hergibt.

Was sagt denn max server memory jetzt? Wenn da noch der Default drinsteht, ziehen SQL und der Ballon gleichzeitig am selben RAM, und dann wirds wirklich unschön.
So ganz will das nicht in meinen Kopf. Ballooning wird doch erst aktiv, wenn dem vHost die Puste ausgeht. Das Diagramm zeigt 48GB von 64GB Belegung. Selbst wenn ich als Zeitbasis ein Jahr wähle, dann sehe ich ich nur 6 Momente, bei denen die Auslastung bei 58GB liegt. Also ist der PVE Quietschfiedel und dürfte keinerlei Ballooning anstoßen.
Also doch beschissenes Arbeiten des virtio-Treibers im Win-Umfeld?
Ich habe nun mal bei einem der Problembären Ballooning deaktiviert, werde beobachten und berichten.
 
Last edited:
Stimmt, bei 75% bläst PVE nichts auf. Zwei Sachen aber: stell den Graph mal von Durchschnitt auf Maximum um, in der Wochen- oder Jahresansicht ist ein 20-Minuten-Peak sonst komplett weggemittelt und du siehst nur eine glatte Linie. Und der ZFS ARC zählt für pvestatd als belegter Speicher, wird nicht als Cache rausgerechnet. Der ARC schiebt dich über 80%, obwohl er sich selbst zurückziehen würde. Bei 64 GB und einem ARC der sich ein paar GB greift ist das schneller passiert als man denkt.

Ob der Ballon überhaupt je gezogen hat, siehst du mit qm status <vmid> --verbose, unter ballooninfo steht actual gegen max_mem. Steht actual die ganze Zeit auf den vollen 32G, war der Ballon nie im Spiel und ich lag daneben. Am virtio-Treiber selbst liegts eher nicht, der macht nur was ihm der Host sagt. Gut, dass du bei einer Kiste den Ballon rausgenommen hast – wenn die trotzdem wieder meckert, wissen wir wenigstens, woran wir sind.
 
  • Like
Reactions: Johannes S
Nun habe ich auch einen PVE (64GB) mit vier Win10-ArbeitsVMs. Alle haben 12GB-Arbeitsspeicher ohne Ballooning. Bei VM-interner Kontrolle liegen die bei 20% RAM-Auslastung. Der PVE listet natürlich Vollauslastung der VMs. Trotzdem die dusselige Meldung wg. Speichermangel. Die Dinger liefen jahrelang ohne Auffälligkeiten. Sogar mit Ballooning und nur max 8GB. Da staunt der Fachmann und der Laie wundert sich.
P.S.:
Deutet leider darauf hin, dass die Host-SW (aktueller PVE, mit virtio .271) und Client-SW (Win10) auseinanderdriften.
 
Last edited: