Dies ist die lückenhafte Dokumentation meines Proxmox-Setups.
Als langjähriger Administrator von VMware vSphere probiere ich etwas Neues aus. Mein Setup und erste Erkenntnisse halte ich in diesem Artikel fest. Ich werde ihn in der Zukunft weiter ausgestalten und ergänzen.
Ich möchte euch nicht vom Lesen abhalten, doch erwartet nicht zu viel.
Betreiber, Standort und Server-Hardware
Für den Betrieb von Labor-Umgebungen habe ich mir einen Server mit folgender Hardware-Ausstattung in Hetzners Serverbörse gemietet.
Ausstattung:
- Intel Core i9-9900K (8 Cores/16 Threads)
- 2x SSD M.2 NVMe 1 TB
- 4x RAM 32768 MB DDR4
- NIC 1 Gbit Intel I219-LM
- Standort: Deutschland, FSN1
- Rescue-System (Englisch)
- 1 x Primäre IPv4
- 1x /64-Subnetz IPv4
Installation
Auf der Hardware habe ich eine Debootstrap-Installation mit Debian 11 (Bullseye) durchgeführt, bei der alle Datenträger mit Ausnahme von /boot LUKS-verschlüsselt sind. Dazu bin ich der hervorragenden Anleitung meines Kollegen Steffen gefolgt: „Manually installing Debian 11 (Bullseye) with fully encrypted LUKS (besides /boot) using debootstrap“
Anschließend habe ich die Proxmox-Paketquellen eingebunden und Proxmox VE installiert. Ich weiß nicht mehr genau, welchem Tutorial ich gefolgt bin. Daher habe ich in [1-3] ein paar vielversprechend erscheinende Suchergebnisse verlinkt.
Netzwerkkonfiguration bis 2023-07-21
Die physikalische NIC meines Hosts wird mit meiner öffentlichen IPv4 und einer IPv6-Adresse für die Außenanbindung konfiguriert. Im Betriebssystem erstelle ich eine Bridge, an welche später die virtuellen Maschinen (VMs) angeschlossen werden. Über diese Bridge haben die VMs Zugriff auf das Internet und sind vom Internet aus zu erreichen.
Das folgende Bild stellt die Konfiguration exemplarisch dar. Statt IPv4-Adressen verwende ich für die Bridge und VMs jedoch ausschließlich IPv6-Adressen.
Die Datei /etc/network/interfaces meines Hosts hat folgenden Inhalt. Die realen IP-Adressen habe ich dabei durch Adressen aus RFC 3849 und RFC 5737 ersetzt.
$ cat /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 198.51.100.38/27
gateway 198.51.100.33
pre-up /sbin/ip addr flush dev eth0 || true
iface eth0 inet6 static
address 2001:db8:dead:beef::1
netmask 128
gateway fe80::1
up sysctl -w net.ipv6.conf.all.forwarding=1
up sysctl -p
auto vmbr0
iface vmbr0 inet6 static
address 2001:db8:dead:beef::2
netmask 64
up ip -6 route add 2001:db8:dead:beef::/64 dev vmbr0
bridge-ports none
bridge-stp off
bridge-fd 0Erläuterungen dazu folgen ggf. später. Als Einstieg empfehle ich einen Blick in die interfaces(5).
Damit eine VM auf das Routing-Netzwerk zugreifen und darüber das Internet erreichen kann, wird diese an die Bridge vmbr0 angeschlossen. Anschließend wird dieser eine IPv6-Adresse aus dem /64-Addressblock konfiguriert, wie es der folgende Code-Block exemplarisch darstellt, wobei static-ipv6 der Name der Verbindung und ens192 der Name der NIC ist:
# nmcli con add con-name static-ipv6 ifname ens192 type ethernet
# nmcli con mod static-ipv6 ipv6.addresses 2001:db8:dead:beef::3/128 ipv6.method manual ipv6.gateway 2001:db8:dead:beef::2
# nmcli con up static-ipv6Zur Verwendung von nmcli habe ich die Red Hat Dokumentation unter [4] zu Rate gezogen.
Netzwerkkonfiguration ab 2023-07-21
Ursprünglich habe ich die Absicht verfolgt, alle VMs auf meinem Hetzner-Server ausschließlich mit IPv6 zu betreiben. Wir schreiben ja schließlich das Jahr 2023. Da sollte das doch problemlos möglich sein. Wäre da nicht (mindestens) ein Dienst, der IPv6 nicht unterstützt.
Da es offenbar nicht ganz ohne IPv4 geht, habe ich mir bei Hetzner eine zweite IPv4-Adresse gemietet [5] und bin der Anleitung Netzwerkkonfiguration für Proxmox VE in der Hetzner-Community gefolgt. Da die Anleitung mein bestehendes Setup für IPv6 nicht berücksichtigt, waren ein paar Anpassungen notwendig. Der folgende Code-Block stellt den Inhalt der Dateien /etc/network/interfaces und /etc/network/interfaces.d/vmbr0-extra dar, wobei die IP-Adressen ersetzt wurden.
$ cat /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
iface eth0 inet manual
pre-up /sbin/ip addr flush dev eth0 || true
auto vmbr0
iface vmbr0 inet static
address 198.51.100.38/27
gateway 198.51.100.33
bridge-ports eth0
bridge-stp off
bridge-fd 0
iface vmbr0 inet6 static
address 2001:db8:dead:beef::1/64
gateway fe80::1
$ cat /etc/network/interfaces.d/vmbr0-extra
iface vmbr0 inet static
hwaddress <zweite MAC-Adresse aus dem Kundenportal>Die virtuelle Netzwerkkarte der VM, welche über die zweite IPv4-Adresse erreichbar sein soll, wird an die Bridge vmbr0 angeschlossen. Das Interface ens18 im Gastbetriebssystem wurde wie folgt konfiguriert:
# nmcli
ens18: connected to ens18
"Red Hat Virtio"
ethernet (virtio_net), 00:50:56:00:8C:22, hw, mtu 1500
ip4 default, ip6 default
inet4 198.51.100.36/32
route4 198.51.100.33/32 metric 100
route4 default via 198.51.100.33 metric 100
inet6 fe80::250:56ff:fe00:8c22/64
inet6 2001:db8:dead:beef::2/64
route6 2001:db8:dead:beef::/64 metric 100
route6 default via fe80::1 metric 100
route6 fe80::/64 metric 1024
# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 185.12.64.1
nameserver 185.12.64.2
nameserver 2a01:4ff:ff00::add:1Getestet habe ich die Konfiguration, indem ich eine Webseite einmal über IPv4 und einmal über IPv6 abgerufen habe. Dies kann man recht einfach mit curl nach folgendem Muster erledigen:
$ curl -4 [URL]
$ curl -6 [URL]Erster Eindruck
Wie ESXi und vSphere verfügt auch Proxmox VE über ein WebUI zur Administration der Umgebung und zur Erstellung virtueller Maschinen.
Selbstverständlich gibt es einige Unterschiede und nicht alles wirkt sofort vertraut. Bisher konnten die Proxmox-Dokumentation und das Proxmox-Wiki meine Fragen jedoch schnell beantworten.
Eine erste VM war schnell erstellt, installiert und in ein Template umgewandelt. Interessanterweise kann man Templates im WebUI nicht wieder in VMs umwandeln, was bei vSphere kein Problem ist.
Im Gegenzug können ISO-Images oder sonstige Dateien einfach per rsync auf den Proxmox-Host kopiert werden, was gerade beim erneuten Übertragen vorhandener Dateien eine enorme Zeitersparnis mit sich bringt. Hier muss bei vSphere und ESXi zum Upload von Dateien in den Datenspeicher das WebUI, SCP oder die Powershell bemüht werden und erneut zu kopierende Dateien werden jedes Mal komplett übertragen. Was bei Netzwerkgeschwindigkeiten im Datacenter nicht so dramatisch ist, nervt doch sehr, wenn man große ISO-Images über eine Internetleitung übertragen muss.
Der erste Eindruck ist zufriedenstellend. Als nächstes werde ich mich mal damit beschäftigen, wie man VMs mit Ansible auf Proxmox provisioniert. Das community.general.proxmox_kvm-Modul scheint dafür ein guter Einstiegspunkt zu sein.