Wechselnde IP-Adressen ( DHCP )

[rainer7]

hallo,

ich möchte einen Proxmox-Server in abwechselnd in verschiedenen IP-Netze betreiben.

Wenn ich das richtig verstanden habe wird bei der Installation die IP-Adresse via DHCP geholt und dann aber fest eingestellt.

Ist es möglich die Adressvergabe auf DHCP umzustellen so dass bei Wechsel des Netzwerks automatisch jeweils eine neue IP-Adresse von dort vergeben wird?

Gruss
Rainer

 

[Dunuin]

Ja, kann man machen. Ist natürlich nur unschön wegen Firewall-Regeln und Co oder wenn man für SSH/webUI/API Zugriff immer erst die IP herausfinden muss.

Man könnte aber z.B. die /etc/network/interfaces editieren, dort bei vmbr0 die IP und gateway entfernen und statt "iface vmbr0 inet static" dann "iface vmbr43 inet dhcp" nehmen. Dann sollte sich PVE eine IP vom DHCP-Server abholen.

 

[Ronny1978]

ich möchte einen Proxmox-Server in abwechselnd in verschiedenen IP-Netze betreiben.

Hallo rainer7,

jetzt muss ich mal blöd fragen: Warum??? Was ist der Vorteil von so einem Konstrukt? Sollte der Host nicht in EINEM Netz bleiben und nur die VMs und CTs in unterschiedliche Netze "gebracht" werden?

 

[rainer7]

Hallo rainer7,

jetzt muss ich mal blöd fragen: Warum??? Was ist der Vorteil von so einem Konstrukt? Sollte der Host nicht in EINEM Netz bleiben und nur die VMs und CTs in unterschiedliche Netze "gebracht" werden?

hallo,
ich möchte den Proxmox-Server an wechselnden Standorte einsetzen. Dort hab ich verschiedene Netze mit DHCP. Die Adressbereiche ändern sich ja je nach Standort.

Rainer

 

[rainer7]

Ja, kann man machen. Ist natürlich nur unschön wegen Firewall-Regeln und Co oder wenn man für SSH/webUI/API Zugriff immer erst die IP herausfinden muss.

Man könnte aber z.B. die /etc/network/interfaces editieren, dort bei vmbr0 die IP und gateway entfernen und statt "iface vmbr0 inet static" dann "iface vmbr43 inet dhcp" nehmen. Dann sollte sich PVE eine IP vom DHCP-Server abholen.

hallo,

das hier:
auto lo

iface lo inet loopback
iface enp1s0 inet manual
auto vmbr0

#iface vmbr0 inet static
# address 192.168.178.151/24
# gateway 192.168.178.1
# bridge-ports enp1s0
# bridge-stp off
# bridge-fd 0

iface vmbr0 inet dhcp

geht leider nicht. Nach einem Reboot wird da keine IP zugewiesen :-(

Rainer

 

[Neobin]

hallo,

das hier:
auto lo


geht leider nicht. Nach einem Reboot wird da keine IP zugewiesen :-(

Rainer

Die drei bridge- Parameter müssen schon auch bei der Bridge bleiben.


Nebenbei: Frage mich, wie es sich mit der: /etc/hosts bei DHCP verhält? Die wird doch sicherlich nicht automatisch aktualisiert, oder doch bei DHCP? Dachte, manche PVE-Services sind auf die Korrektheit dieser angewiesen?!

 

[rainer7]

hallo,

wäre das eine Lösung: https://weblog.lkiesow.de/20220223-proxmox-test-machine-self-servic/proxmox-server-dhcp.html

Gruss
Rainer

 

[Ronny1978]

hallo,
ich möchte den Proxmox-Server an wechselnden Standorte einsetzen. Dort hab ich verschiedene Netze mit DHCP. Die Adressbereiche ändern sich ja je nach Standort.

Rainer

Hallo rainer7,

danke für deine Info, auch wenn ich das Szenario noch nicht ganz kapiere? Du nimmst deinen Proxmox Host, gehst zu wem auch immer, startest, lässt eine VM oder LXC laufen und gehst dann wieder wo anderes hin??? Gibt es da kein Netz das ALLE Standorte haben? 191.168.178.x oder 192.168.0.x oder sind die Standorte auch noch alle verknüpft?

 

[TErxleben]

Nachdem dieser Thread nun seit zwei Jahren gut abgehangen ist möchte ich mal nachfragen, ob jemand eine Lösung gefunden hat ohne manuell in Systemdateien Änderungen vornehmen zu müssen.

Eine funktionierenden DHCP/DNS-Umgebungen vorausgesetzt, sollte ein Haken [DHCP] in der WebGUI doch reichen, um einen PVE/PBS aus Netz A in Netz B umzustöpseln. Ich spreche hier nicht von Clustermitglieder, sondern eher von Einzelsystemen, die im Fehlerfall als "Verstärkung" häufiger die Umgebung wechseln.

Oder von (Remote)PBS-Servern, die am dafür geplantem Standort ihren Dienst vorzüglich versehen und im Fehlerfall zum Zielsystem transportiert werden sollen. Ich möchte z.B. eben gerne einen 100TB Remoteserver per Kurierdienst transportieren, statt Drähte zum Glühen zu bringen.

Da will ich nicht dauernd manuell rumfrickeln nur um so eine Kiste in fremder IP-Umgebung verfügbar zu machen!

P.S.: schon 10TB sind in 95% der Fälle PITA.

 

[TErxleben]

Tipp, installiere noch einen Netzwerkkarte stelle auch dafür eine feste IPv4 und Netzwerk ein und ändere dann am Standort nur die Default Route.

Den Tipp kenne ich. Da muss ich aber immer noch frickeln. DHCP wäre die konsequente Basislösung und keinesfalls Hexenwerk, sondern ist Standard.

 

[TErxleben]

Der Proxmox VE Server benötigt jeweils Einträge mit seinem Namen in der /etc/hosts Datei!

Warum? Debian als Basis braucht es nicht!

 

[Falk R.]

Warum? Debian als Basis braucht es nicht!

Weil Debian ohne Nachinstallation keine Clusterfunktionen mitbringt und keine PVE Dienste hat.

 

[TErxleben]

Seit ich Proxmox nutze (>15J.), verwendet Proxmox feste IPs. Da gab es noch keine Clusterfunktionen. Wie ich eingangs beschrieb, sehe ich da einen echten Bedarf aber Proxmox offenbar nicht. Abgesehen davon das DHCP/DNS auch in Clusterumgebungen stabil funkioniert, glaube ich das Einzelsysteme den überwiegenden Teil aller Installationen ausmachen.

Nochmal kurz zusammengefasst, wo ich die Vorteile sehe:

• PVE wird in Netzwerk A konfiguriert und in Netzwerk B genutzt
• Daten eines Remote-PBS breitbandig im Zielnetz zwecks Rücksicherung zur Verfügung stellen
• Anpassungen der Netzwerkumgebung (z.B. Gateway) erfordern kein manuelles Nacharbeiten
• Minimierung von Fehlerquellen

 

[Johannes S]

Nichts für ungut, aber für mich wirkt das doch wie ein eher exotisches Szenario. Bevor ich einen Server quer durch die Republik kutschieren lasse, würde ich das ja noch eher mit Festplatten machen. Wie der PBS heißt und in welchen Netz die Daten dann für den Restore sind, ist doch für den Usecase völlig egal. Wieviele Leute gibt es, die regelmäßig (!) Server von Ort a nach b transportieren und wieder zurück und dabei jeweils sich ins andere Netz einklinken?

 

[TErxleben]

Nichts für ungut, aber für mich wirkt das doch wie ein eher exotisches Szenario. Bevor ich einen Server quer durch die Republik kutschieren lasse, würde ich das ja noch eher mit Festplatten machen. Wie der PBS heißt und in welchen Netz die Daten dann für den Restore sind, ist doch für den Usecase völlig egal. Wieviele Leute gibt es, die regelmäßig (!) Server von Ort a nach b transportieren und wieder zurück und dabei jeweils sich ins andere Netz einklinken?

Jeder, der eine zuverlässige DHCP/DNS-Umgebung betreibt, ist über Gerätschaften mit fester IP genervt und versucht die Zahl solcher Teile so gering wie möglich zu halten.
So wenige sind das bestimmt nicht.

 

[Falk R.]

Jeder, der eine zuverlässige DHCP/DNS-Umgebung betreibt, ist über Gerätschaften mit fester IP genervt und versucht die Zahl solcher Teile so gering wie möglich zu halten.
So wenige sind das bestimmt nicht.

Aber nicht bei Hypervisoren. Ich habe große Kunden mit vielen Tausend VMs. Diese Server nutzen alle DHCP. Die einzigen Ausnahmen sind Hypervisor, Backup und Storage. Das aus gutem Grund.

 

[TErxleben]

Was sind denn die guten Gründe? Etwaige Ausfall der DNS-Services? Alte Oma-Konzepte? Gewachsene Strukturen?

Ich habe viele Kunden, die mehrere Standorte betreiben. Da stehen dann 8-Bay-Würfel mit 100-200TB als PBS-Remotes. Die Standorte sind i.d.R nicht richtig fett untereinander verbunden. Vollzeit-Admins haben die auch nicht. Da bietet es sich schon an, im worstcase den Azubi mit dem Würfel unter dem Arm in den betroffenen Standort zu schicken um selbigen nur mittels zwei Kabeln ins Netzwerk "einzubinden". Ich könnte solchen Kunden auch sagen: Wartet 3 Tage, dann sind die Daten über Leitung zurückgetröpfelt.
Selbst wenn ich einen Remote-PBS in einem potenten RZ betreibe, sind Restorezeiten gerne unterirdisch. So richtig günstig auch nicht. Es gibt sogar Kunden, die gerade ihre Backups keinesfalls ausserhalb ablegen möchten.

 

[Johannes S]

Ich habe viele Kunden, die mehrere Standorte betreiben. Da stehen dann 8-Bay-Würfel mit 100-200TB als PBS-Remotes. Die Standorte sind i.d.R nicht richtig fett untereinander verbunden. Vollzeit-Admins haben die auch nicht. Da bietet es sich schon an, im worstcase den Azubi mit dem Würfel unter dem Arm in den betroffenen Standort zu schicken um selbigen nur mittels zwei Kabeln ins Netzwerk "einzubinden". Ich könnte solchen Kunden auch sagen: Wartet 3 Tage, dann sind die Daten über Leitung zurückgetröpfelt.

Was spricht denn in solchen Fällen dagegen mit removable Datastores und externen Festplatten zu arbeiten? Ich meine, ich habe im Studium auch mal den Spruch mit "Unterschütze nie die Bandbreite eines LKWs voller Magnetbänder" gehört, daraus folgt aber doch noch lange nicht, dass man die komplette Tapelibrary immer mitschleppen muss.

Selbst wenn ich einen Remote-PBS in einem potenten RZ betreibe, sind Restorezeiten gerne unterirdisch. So richtig günstig auch nicht. Es gibt sogar Kunden, die gerade ihre Backups keinesfalls ausserhalb ablegen möchten.

Dann drücke ich denen die Daumen, dass deren Daten nie von einer Naturkatastrophe, Diebstahl o.ä. betroffen sind.

 

[TErxleben]

Was spricht denn in solchen Fällen dagegen mit removable Datastores und externen Festplatten zu arbeiten? Ich meine, ich habe im Studium auch mal den Spruch mit "Unterschütze nie die Bandbreite eines LKWs voller Magnetbänder" gehört, daraus folgt aber doch noch lange nicht, dass man die komplette Tapelibrary immer mitschleppen muss.

PBS kann bis heute noch nicht einmal zuverlässig mit externen USB-Medien umgehen. Dann soll ich removable Datastores trauen/verwenden?
Diese PBS-"Tapelibrary" wiegt vielleicht 5kg und ist recht handlich. Eine 100TB HDD habe ich bisher nicht gefunden.

Dann drücke ich denen die Daumen, dass deren Daten nie von einer Naturkatastrophe, Diebstahl o.ä. betroffen sind.

Verstehe ich nicht. Gerade deshalb gibt es doch einen oder gar mehrere Remote-PBS

 

[Falk R.]

Was sind denn die guten Gründe? Etwaige Ausfall der DNS-Services? Alte Oma-Konzepte? Gewachsene Strukturen?

Wenn tatsächlich mal der K-Fall eintritt und alles Down ist, was startet man zuerst? Richtig, die Infrastruktur. Blöd wenn der Hypervisor auf einen DHCP Server angewiesen ist, der eventuell noch nicht läuft. Jeder der ein Notfallkonzept geschrieben hat, wird die Krise bekommen, wenn man die Grundlegende Infrastruktur mit DHCP betreibt.

Ich habe viele Kunden, die mehrere Standorte betreiben. Da stehen dann 8-Bay-Würfel mit 100-200TB als PBS-Remotes. Die Standorte sind i.d.R nicht richtig fett untereinander verbunden. Vollzeit-Admins haben die auch nicht. Da bietet es sich schon an, im worstcase den Azubi mit dem Würfel unter dem Arm in den betroffenen Standort zu schicken um selbigen nur mittels zwei Kabeln ins Netzwerk "einzubinden". Ich könnte solchen Kunden auch sagen: Wartet 3 Tage, dann sind die Daten über Leitung zurückgetröpfelt.
Selbst wenn ich einen Remote-PBS in einem potenten RZ betreibe, sind Restorezeiten gerne unterirdisch. So richtig günstig auch nicht. Es gibt sogar Kunden, die gerade ihre Backups keinesfalls ausserhalb ablegen möchten.

Wenn du solche unüblichen Szenarien hast, dann ist das für dich eine Option mit DHCP zu arbeiten. Aber zum restoren brauchst du mehr als den Azubi, der unfallfrei das Kabel stecken kann. Dann lässt du das BMC auf DHCP und kommst als Admin dran und änderst darüber die IP des PBS. Die 20 Sekunden sollten dann noch drin sein.