Admin: Die Seite wurde neu angelegt: „= Proxmox VE Installation und Grundkonfiguration =
Im folgenden Beitrag gehe ich auf die Konfigurationsmöglichkeiten einer Proxmox VE Basis…“

2022-08-24T11:10:45Z

Die Seite wurde neu angelegt: „= Proxmox VE Installation und Grundkonfiguration = <div class="clear">Im folgenden Beitrag gehe ich auf die Konfigurationsmöglichkeiten einer Proxmox VE Basis…“

Neue Seite

= Proxmox VE Installation und Grundkonfiguration =
<div class="clear">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. </div><div class="entry themeform"><div class="entry-inner">
===== Installation =====
Die eigentliche Grundinstallation von PVE ist im Wiki vom Proxmox hier ([https://pve.proxmox.com/wiki/Installation 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:<pre class="wp-block-preformatted">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</pre>In der <code>proxmoxlib.js</code> Datei sucht man in <code>nano</code> mit Ctrl+W nach dem Suchbegriff ''<code>No valid subscription</code>''. Die Ergebniszeile sieht wie folgt aus:<pre class="wp-block-preformatted">...
Ext.Msg.show({
title: gettext('No valid subscription'),
...</pre>Der Eintrag <code>Ext.Msg.show</code> wird gegen den Eintrag <code>void</code> getauscht und die Datei mit Ctrl+X gespeichert:<pre class="wp-block-preformatted">...
void({
title: gettext('No valid subscription'),
...</pre>Danach muss nur noch der PVE Web Service neu gestartet werden, um die Änderung zu aktivieren:<pre class="wp-block-preformatted">systemctl restart pveproxy.service</pre>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.<pre class="wp-block-preformatted">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</pre>In der neu erstellte Sources-Datei ist folgender Eintrag hinzuzufügen:<pre class="wp-block-preformatted"># PVE 6.x
<tt>deb http://download.proxmox.com/debian/pve buster pve-no-subscription</tt>
# PVE 7.x
<tt>deb http://download.proxmox.com/debian/pve bullseye pve-no-subscription</tt></pre>''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 <code>pve-no-subscription.list</code> 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:<pre class="wp-block-preformatted">apt update
apt install openvswitch-switch</pre>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 <code>ifupdown2</code> Tool.<pre class="wp-block-preformatted">apt install ifupdown2</pre>''Update/Änderung in PVE 7.0''In PVE 7.0 wurde <code>ifupdown2</code> 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 BytesUm ARC zu konfigurieren, ist mit dem folgenden Befehl die <code>zfs.conf</code> Datei zu editieren (wird neu angelegt, falls sie noch nicht existiert):<pre class="wp-block-preformatted">nano /etc/modprobe.d/zfs.conf</pre>Dort trage ich folgende Werte ein:''Produktivserver''<pre class="wp-block-preformatted">options zfs zfs_arc_min=2147483648
options zfs zfs_arc_max=4294967296</pre>''Testserver''<pre class="wp-block-preformatted">options zfs zfs_arc_min=1073741824
options zfs zfs_arc_max=2147483648</pre>Da ich UEFI Systeme verwende, muss die Kernel Liste aktualisiert werden, damit das aktualisierte RAM File System verwendet wird (bei BIOS nicht notwendig):<pre class="wp-block-preformatted">pve-efiboot-tool refresh</pre>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.<pre class="wp-block-preformatted">update-initramfs -u</pre>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:<pre class="wp-block-preformatted">systemd[1]: Starting Proxmox VE replication runner...</pre>Um diese Meldung zu unterbinden, lässt sich der entsprechende Dienst einfach deaktivieren:<pre class="wp-block-preformatted">systemctl disable pvesr.timer</pre>Wer den Dienst nicht komplett abschalten möchte, kann alternativ das Intervall ändern, in denen der Replication Runner ausgeführt wird:<pre class="wp-block-preformatted">nano /lib/systemd/system/pvesr.timer</pre>Hier ändere ich den Eintrag …<pre class="wp-block-preformatted">[Timer]
OnCalendar=minutely</pre>… in …<pre class="wp-block-preformatted">[Timer]
OnCalendar=monthly</pre>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  > SANBesonders 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 KonfigurationWarum 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:<pre class="wp-block-preformatted">ip -c link</pre>Die Ausgabe sieht dann z.B. wie folgt aus, wenn die Bond-Members automatisch starten:<pre class="wp-block-preformatted">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</pre>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:
#Konfiguration einer statischen MAC für die Bridge
#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 <code>/etc/network/interfaces</code> mit z.B. <code>nano</code> angepasst werden, indem ein Parameter <code>hwaddress</code> in die entsprechende Bridge-Konfiguration eingefügt wird, also in meinem Beispiel:<pre class="wp-block-preformatted">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</pre>''Deaktivierung des Autostarts für die phsikalischen NIC Members des Bonds''Der Autostart der NICs muss ebenfalls über die Datei <code>/etc/network/interfaces</code> durchgeführt werden. Dazu muss bei allen betroffenen NICs der <code>auto</code> 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.<pre class="wp-block-preformatted"><s>auto eno1</s>
iface eno1 inet manual

<s>auto eno2</s>
iface eno2 inet manual</pre>Abschließend muss die neue Konfiguration noch angewendet werden. Dazu ist der Befehl <code>ifreload -a</code>. Danach sieht die Ausgabe von <code>ip -c link</code> nun so aus:<pre class="wp-block-preformatted">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</pre>Leider bleibt diese Korrektur nicht persitent – warum auch immer. Der <code>auto</code> 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:<pre class="wp-block-preformatted">@reboot ifreload -a</pre>'''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 <code>/etc/systemd/timesynd.conf</code> mit z.B. <code>nano</code> angepasst werden (mehrere Server werden mit Leerzeichen getrennt angegeben), z.B.:<pre class="wp-block-preformatted">[Time]
NTP=de.pool.ntp.org</pre>Danach muss nur noch der entsprechende Dienst neu gestartet werden, damit die Änderung aktiv wird:<pre class="wp-block-preformatted">systemctl restart systemd-timesyncd</pre>Die Änderung kann geprüft werden entweder mit den Befehlen <code>systemctl status systemd-timesynd</code> oder <code>journalctl --since -1h -u systemd-timesyncd</code>.<hr class="wp-block-separator"></div></div>

Proxmox - Versionsgeschichte

Admin: Die Seite wurde neu angelegt: „= Proxmox VE Installation und Grundkonfiguration = Im folgenden Beitrag gehe ich auf die Konfigurationsmöglichkeiten einer Proxmox VE Basis…“

Admin: Die Seite wurde neu angelegt: „= Proxmox VE Installation und Grundkonfiguration =
Im folgenden Beitrag gehe ich auf die Konfigurationsmöglichkeiten einer Proxmox VE Basis…“