Proxmox VE Installation und Grundkonfiguration

Im folgenden Beitrag gehe ich auf die Konfigurationsmöglichkeiten einer Proxmox VE Basisinstallation ein. Für den Beitrag habe ich noch PVE 6.4 installiert, da kurz darauf PVE 7.0 released wurde, habe ich Änderungen in dieser Version noch in den Beitrag einfließen lassen.

Installation

Die eigentliche Grundinstallation von PVE ist im Wiki vom Proxmox hier (https://pve.proxmox.com/wiki/Installation) ganz gut dokumentiert, daher gehe ich auf die Installation nicht mehr groß ein.

Grundkonfiguration

Im Anschluss an die Installation nehme ich über die Web UI und SSH einige Grundeinstellungen vor.

No-Subscription Warning

Ohne Subscription erscheint in der Web-GUI von Proxmox bei jedem Login eine Warnmeldung, dass das System ohne Subscription betrieben wird. Dies ist trotzdem ganz legal, allerdings ist die Meldung sehr störend, kann aber glücklicherweise deaktiviert werden.

Dazu verbindet man sich im ersten Schritt per SSH mit dem PVE Host. Danach sichert man die Datei, die für die Deaktivierung angepasst werden muss und öffnet die Datei mit nano:

cp /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js.bak
nano /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js

In der proxmoxlib.js Datei sucht man in nano mit Ctrl+W nach dem Suchbegriff No valid subscription. Die Ergebniszeile sieht wie folgt aus:

...
Ext.Msg.show({
  title: gettext('No valid subscription'),
...

Der Eintrag Ext.Msg.show wird gegen den Eintrag void getauscht und die Datei mit Ctrl+X gespeichert:

...
void({
  title: gettext('No valid subscription'),
...

Danach muss nur noch der PVE Web Service neu gestartet werden, um die Änderung zu aktivieren:

systemctl restart pveproxy.service

Nach einem Versionsupdate kann es vorkommen, dass die obige Konfiguration erneut durchgeführt werden muss!

No-Subscription Repository

Da ich keine Subscription habe, deaktiviere das Enterprise Repository und lege eine Sources-Datei an für das No-Subscription Repository.

mv /etc/apt/sources.list.d/pve-enterprise.list /etc/apt/sources.list.d/pve-enterprise.list.bak
nano /etc/apt/sources.list.d/pve-no-subscription.list

In der neu erstellte Sources-Datei ist folgender Eintrag hinzuzufügen:

# PVE 6.x
deb http://download.proxmox.com/debian/pve buster pve-no-subscription
# PVE 7.x
deb http://download.proxmox.com/debian/pve bullseye pve-no-subscription

Update/Änderung in PVE 7.0

Mit PVE 7.0 wurde die Möglichkeit geschaffen, die Repositories über die Web GUI auszuwählen. Zu finden ist die Option unter dem Server-Node im Menü Updates -> Repositories. Der Eintrag in der pve-no-subscription.list wird nur für das Update von 6.x auf 7.x benötigt.

Open vSwitch

Optional kann man auch noch Open vSwitch (OVS) nachinstallieren, falls man das Feature nutzen möchte:

apt update
apt install openvswitch-switch

Mir reichen in meinen Installationen die normalen Linux Netzwerk-Bridges und benötige daher OVS nicht.

ifupdown2

Um Änderungen an der Netzwerkkonfiguration in der PVE GUI auch im laufenden Betrieb ohne Neustart zu ermöglichen, installiere ich noch das dazu benötigte ifupdown2 Tool.

apt install ifupdown2

Update/Änderung in PVE 7.0

In PVE 7.0 wurde ifupdown2 in die Basisinstallation integriert und muss nicht mehr nachinstalliert werden.

ZFS File System Konfiguration / ZFS ARC Tuning

Wie in einem anderen Beitrag beschrieben, habe ich 2 Server, ein Produktivsystem und ein Testsystem; in beiden Systemen sind 2 Data Disks, die ich per ZFS mit RAID 1 zu einem logischen Volume zusammenschließe. Für die Nutzung von ZFS ist jedoch einiges zu beachten.

ARC (Adaptive Replacement Cache) ist eine Funktion von ZFS, die Daten, auf die am häufigsten zugegriffen wird, im RAM speichert und so extrem schnelle Lesevorgänge für diese Ressourcen ermöglicht. Das ist an sich eine sinnvolle Funktion, aber die standardmäßige maximale Größe für ARC beträgt 50% des gesamten System-RAMs. Auf einem File Server macht eine Einstellung von 50% oder sogar noch mehr durchaus Sinn, aber Proxmox VE ist ja nun mal kein File Server sondern ein Hypervisor. Da RAM einerseits teuer ist und andererseits der RAM für ein System begrenzt ist, drehe ich die Einstellung in meiner Installation daher herunter.

Es gibt viele Empfehlungen, wie viel RAM für ARC verwendet werden soll. Häufig trifft man dabei auf den Wert 1 GB pro TB ZFS Speicher, mindestens jedoch 8 GB. Meine Server haben jeweils eine 500 GB ZFS RAID 1 Disk, d.h. rein nach diesem TB Wert würde 1 GB für ARC reichen. Zudem verfügen meine Server über 32 GB, bzw. 64 GB RAM. Daher bleibe ich erst mal unter der Empfehlung und limitiere ARC erstmal auf 2 GB, bzw. 4 GB. Sollte das zu Performance Problemen führen, kann auf 8 GB erhöht werden. 1 GB RAM bzw. 2 GB RAM konfiguriere ich als Minimalwert.

Diese Werte müssen in Bytes angegeben werden und können wie folgt berechnet werden:
GB * 1024 = MB -> MB * 1024 = KB -> KB * 1024 = Bytes
Daraus ergeben sich folgende Werte:
8GB = 8589934592 Bytes
4GB = 4294967296 Bytes
2GB = 2147483648 Bytes
1GB = 1073741824 Bytes

Um ARC zu konfigurieren, ist mit dem folgenden Befehl die zfs.conf Datei zu editieren (wird neu angelegt, falls sie noch nicht existiert):

nano /etc/modprobe.d/zfs.conf

Dort trage ich folgende Werte ein:

Produktivserver

options zfs zfs_arc_min=2147483648
options zfs zfs_arc_max=4294967296

Testserver

options zfs zfs_arc_min=1073741824
options zfs zfs_arc_max=2147483648

Da ich UEFI Systeme verwende, muss die Kernel Liste aktualisiert werden, damit das aktualisierte RAM File System verwendet wird (bei BIOS nicht notwendig):

pve-efiboot-tool refresh

Für das eigentliche PVS System verwende ich eine separate EXT4 formatierte LVM Disk. Dadurch ist die Konfiguration von ZFS für meine System fertig. Wer jedoch auch das System auf einer ZFS Disk installiert, muss auch das initiale RAM Dateisystem anpassen, damit die Änderung wirksam wird vor dem Mounten des ZFS Volumes.

update-initramfs -u

Damit obige Änderungen wirksam werden, muss das System abschließend nun noch gebootet werden.

Replication Runner Syslog Messages

Wer den Replication Runner unverändert lässt, dem werden im Syslog von PVE minütliche Einträge wie diese auffallen:

systemd[1]: Starting Proxmox VE replication runner...

Um diese Meldung zu unterbinden, lässt sich der entsprechende Dienst einfach deaktivieren:

systemctl disable pvesr.timer

Wer den Dienst nicht komplett abschalten möchte, kann alternativ das Intervall ändern, in denen der Replication Runner ausgeführt wird:

nano /lib/systemd/system/pvesr.timer

Hier ändere ich den Eintrag …

[Timer]
OnCalendar=minutely

… in …

[Timer]
OnCalendar=monthly

Danach läuft der Replication Runner nur noch einmal monatlich.

Netzwerk Konfiguration

In meinen Systemen befinden sich je 4 NICs. Diese teile ich wie folgt auf:
NIC 1  > LAN Bond 1/2
NIC 2  > LAN Bond 2/2
NIC 3  > DMZ
NIC 4  > SAN

Besonders bei der Konfiguration des Bonds hatte ich massive Probleme. Das Löschen der vmbr0, Anlegen von bond0 mit Member eno0 eno1 (oder wie die IFs im System halt heißen), Anlegen von vmbr0 mit Member bond0 und IP Konfiguration, Anwenden der Konfiguration hat bei mir dazu geführt, dass das System nicht mehr erreichbar ist.

Die Lösung war bei mir:
Löschen der vmbr0, anlegen von bond0 mit Member eno0, anlegen von vmbr0 mit Member bond0 und IP Konfiguration, anwenden der Konfiguration; danach hinzufügen von eno1 zu bond0, anwenden der Konfiguration

Warum das so ist, konnte ich noch nicht nachvollziehen, Hinweise dazu sind natürlich willkommen.

Wichtig ist auch zu beachten, dass PVE ggf. bei der Bildung von Bridges und Bonds eigene MAC-Adressen vergibt und sich diese bei einem Major Release Update auch gerne mal ändern. Dies tritt auf, wenn die physikalischen Bond-Members automatisch starten.

Welche MACs verwendet werden, lässt sich mit folgendem Befehl anschauen:

ip -c link

Die Ausgabe sieht dann z.B. wie folgt aus, wenn die Bond-Members automatisch starten:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eno1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond1 state UP mode DEFAULT group default qlen 1000
    link/ether f6:76:43:97:f6:a4 brd ff:ff:ff:ff:ff:ff permaddr ac:1f:6b:44:cd:18
    altname enp5s0f0
3: eno2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond1 state UP mode DEFAULT group default qlen 1000
    link/ether f6:76:43:97:f6:a4 brd ff:ff:ff:ff:ff:ff permaddr ac:1f:6b:44:cd:19
    altname enp5s0f1
4: eno3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr2 state UP mode DEFAULT group default qlen 1000
    link/ether ac:1f:6b:44:cd:1a brd ff:ff:ff:ff:ff:ff
    altname enp7s0f0
5: eno4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr3 state UP mode DEFAULT group default qlen 1000
    link/ether ac:1f:6b:44:cd:1b brd ff:ff:ff:ff:ff:ff
    altname enp7s0f1
6: bond1: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr1 state UP mode DEFAULT group default qlen 1000
    link/ether f6:76:43:97:f6:a4 brd ff:ff:ff:ff:ff:ff
7: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether f6:76:43:97:f6:a4 brd ff:ff:ff:ff:ff:ff
8: vmbr2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether ac:1f:6b:44:cd:1a brd ff:ff:ff:ff:ff:ff
9: vmbr3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether ac:1f:6b:44:cd:1b brd ff:ff:ff:ff:ff:ff

Wie man in diesem Beispiel sieht, vergibt PVE für alle Member-NICs des Bonds, für den Bond selbst und für die Bridge des Bonds eine neue MAC-Adresse. Wie geschrieben, kann diese sich jedoch unter Umständen ändern. Um dies zu vermeiden, gibt es 2 Optionen:

1. Konfiguration einer statischen MAC für die Bridge
2. Deaktivierung des Autostarts für die physikalischen NIC Members des Bonds

Warum ist es wichtig, mit welchen MAC-Adressen der PVE Server daherkommt? In meinem Fall, weil ich eine Firewall mit MAC-based Policies verwende. Ändert sich also die MAC, muss das jeweilige Firewall Objekt angepasst werden, sonst funktionieren die Freischaltungen nicht mehr.

Konfiguration einer statischen MAC

Leider lässt sich die vergebene MAC-Adresse nicht in der PVE-GUI konfigurieren. Um diese anzupassen und persistent zu halten, muss über die Shell die Datei /etc/network/interfaces mit z.B. nano angepasst werden, indem ein Parameter hwaddress in die entsprechende Bridge-Konfiguration eingefügt wird, also in meinem Beispiel:

auto vmbr1
iface vmbr1 inet static
	hwaddress f6:76:43:97:f6:a4
        address 10.x.x.x/24
        gateway 10.x.x.1
        bridge-ports bond1
        bridge-stp off
        bridge-fd 0

Deaktivierung des Autostarts für die phsikalischen NIC Members des Bonds

Der Autostart der NICs muss ebenfalls über die Datei /etc/network/interfaces durchgeführt werden. Dazu muss bei allen betroffenen NICs der auto Parameter entfernt oder auskommentiert werden. Wichtig! Die Änderung funktioniert nur, wenn keine VM auf die Bridge und den Bond gebunden wird, dessen Slaves die NICs sind.

auto eno1
iface eno1 inet manual

auto eno2
iface eno2 inet manual

Abschließend muss die neue Konfiguration noch angewendet werden. Dazu ist der Befehl ifreload -a. Danach sieht die Ausgabe von ip -c link nun so aus:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eno1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond1 state UP mode DEFAULT group default qlen 1000
    link/ether ac:1f:6b:44:cd:18 brd ff:ff:ff:ff:ff:ff
    altname enp5s0f0
3: eno2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond1 state UP mode DEFAULT group default qlen 1000
    link/ether ac:1f:6b:44:cd:18 brd ff:ff:ff:ff:ff:ff permaddr ac:1f:6b:44:cd:19
    altname enp5s0f1
4: eno3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr2 state UP mode DEFAULT group default qlen 1000
    link/ether ac:1f:6b:44:cd:1a brd ff:ff:ff:ff:ff:ff
    altname enp7s0f0
5: eno4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr3 state UP mode DEFAULT group default qlen 1000
    link/ether ac:1f:6b:44:cd:1b brd ff:ff:ff:ff:ff:ff
    altname enp7s0f1
6: bond1: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr1 state UP mode DEFAULT group default qlen 1000
    link/ether ac:1f:6b:44:cd:18 brd ff:ff:ff:ff:ff:ff
7: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether ac:1f:6b:44:cd:18 brd ff:ff:ff:ff:ff:ff
8: vmbr2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether ac:1f:6b:44:cd:1a brd ff:ff:ff:ff:ff:ff
9: vmbr3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether ac:1f:6b:44:cd:1b brd ff:ff:ff:ff:ff:ff

Leider bleibt diese Korrektur nicht persitent – warum auch immer. Der auto Parameter bleibt zwar raus, die „virtuelle“ MAC wird aber beim Reboot wieder erzeugt. D.h. die Korrektur ist bei jedem Reboot per cron-Job auszuführen:

@reboot ifreload -a

NTP Server

Da Proxmox VE auf Debian basiert, versucht das System sein Zeit standardmäßig mit den debian.pool.ntp.org Servern zu synchronisieren. Dazu verwendet PVE den Daemon systemd-timesyncd. Um eigene Server zu hinterlegen, muss daher die Datei /etc/systemd/timesynd.conf mit z.B. nano angepasst werden (mehrere Server werden mit Leerzeichen getrennt angegeben), z.B.:

[Time]
NTP=de.pool.ntp.org

Danach muss nur noch der entsprechende Dienst neu gestartet werden, damit die Änderung aktiv wird:

systemctl restart systemd-timesyncd

Die Änderung kann geprüft werden entweder mit den Befehlen systemctl status systemd-timesynd oder journalctl --since -1h -u systemd-timesyncd.

---

Quellen:
https://pve.proxmox.com/wiki/