Proxmox Memory Problem mit WIN2012 und SQL Server

 In meinen Kundenumgebungen beobachte ich eine sehr hohe Speicherauslastung bei Microsoft SQL Servern. Der Durchschnitt liegt bei >90% Speicherverbrauch und der Windows-Server ist durchweg mit swapping beschäftigt.

Die Vermutung war, dass es Probleme mit der Datenbankeinstellung gegeben hat, jedoch war hier alles korrekt eingestellt. Nach etwas Suchen im Internet wurde ich dann darauf aufmerksam, dass das Problem mit dem Ballooning-Treiber (KVM/Proxmox) zu tun haben kann.

Die VM hatte 120 GB RAM konfiguriert und Proxmox sollte davon mindestens 80 GB bereit bereit halten.

VM Hardware Einstellung vor der Änderung

Nachdem ich den Min. Speicher auch auf 120 GB eingestellt hatte, war das Problem sofort beseitigt. Sowohl die VM als auch der Proxmox Host selbst, sind in ihrem Speicherverbrauch gesunken und die VM performt jetzt spürbar schneller.

VM Einstellung nach der Änderung,
Ballooning bleibt aktiviert

Die Auswirkungen sind mehr als deutlich zu erkennen.

Die dynamische Speicherverwaltung (Ballooning) scheint daher leider nicht immer optimal zu funktionieren. Es ist aber dennoch wichtig, dass das Häkchen bei "Ballooning Gerät" gesetzt bleibt, weil Proxmox sonst nicht in der Übersicht die richtigen Werte für den Speicherverbrauch der VM anzeigen kann.

Migration von VMs von VMware nach Proxmox

 Ich stecke gerade in einer sehr großen Migration von VMware nach Proxmox. Es gibt viele Anleitungen im Internet, wie das funktionieren kann. Über den Export von OVFs, qemu-Converter oder CloneZilla gibt es da viele gute Ideen. Ich fand sie aber viel zu kompliziert und habe mir mit einer sehr einfachen Lösung geholfen.

Im ersten Schritte habe ich auf der VMware-Seite eine einfache Linux-VM, ohne GUI oder sonstiger Softwareauswahl, minimal System reicht, installiert. Wichtig ist nur, dass diese VM über das Netzwerk den Proxmox-Server erreichen kann.

Die VM, welche nun umgezogen werden soll, wird ausgeschaltet. Die virtuellen Disks dieser VM werden an die Linux-Helper-VM gehängt.

Jetzt sollte man in der Helper-VM natürlich wissen, welche Disks hinzugekommen sind, ein "dmesg" wird da Auskunft geben.

Auf der Proxmox-Seite wird die neue VM konfiguriert, also die Werte für RAM, CPU. Netzwerk usw. eingestellt. Wichtig: Die Disks der VM müssen genauso groß sein, wie sie es auf der VMware-Seite sind. In meinem Fall liegen die virtuellen Disks auf dem Proxmox-Server alle im LVM als logische Disks.

Zurück zu der VMware-Helper-VM kann ich nun anfangen die Disks zu kopieren:

"dd if=/dev/sdb BS=1M status=progress | ssh -l root <ProxmoxServer/IP> "dd of=/dev/VG-Name/vm-121-disk0 BS=1M"

VG-Name=Name der LVM Volume Group

Sollte die Ursprungs-VM mehrere Disks haben, können natürlich auch mehrere Sessions parallel gestartet werden. So wird gleich alles in einem Rutsch migriert.

Sobald der Kopiervorgang durch ist, kann die Proxmox-VM gestartet werden. Hier sollten zunächst die VMware-Tools deaktiviert und dafür der Qemu-Gast-Agent und Treiber installiert werden. 

Podman Container als systemd-Dienste automatisch starten

Hat man eine Applikation in einen Container verpackt und kann diese erfolgreich mit podman laufen lassen, soll diese vermutlich auch bei einem Neustart des Hosts automatisch gestartet werden.

Podman liefert dazu die Werkzeuge, um die Systemd-Service-Units zu generieren.

In dem Beispiel betreibe ich einen Container mit dem Namen App1. Mit dem Kommando:

podman generate systemd --name App1 --files --new

[--name Es wird der Name des Containers verwendet und nicht die Container-ID

--files Die Ausgabe erfolgt in Dateien, statt auf STDOUT]

wird die Service-Unit-Datei im lokalen Verzeichnis erstellt:

container-App1.service

Es ist zwingend nötig die Datei in sein Homeverzeichnis unter .config/systemd/user/ zu kopieren:

cp conatiner-App 1.service ~USER/.config/systemd/user/

Bevor nun mit systemctl der Container gestartet wrid, muss sichergestellt sein, dass der ursprüngliche Container gestoppt ist.

podman stop App1

Auch das Container Image darf nicht mehr vorhanden sein:

podman rm App1

Ab jetzt kann der Container mit den systemd-Tools administriert werden:

systemctl --user daemon-reload

systemctl --user start container-App1

systemctl --user enable container-App1

Damit der Service nun auch gestartet werden kann, wenn der User nicht eingeloggt ist, muss noch folgendes Kommando ausgeführt werden:

loginctl enable-linger USERNAME

Der Dienst kann nun mit systemctl verwaltet werden und wird bei einem Rechnerneustart automatisch gestartet.