[SOLVED] Restore eines Hosts als VM führt zu Fehlern im produktiven Cluster

[NexorProject]

Hallo Zusammen

Ich habe wieder einmal ein sehr merkwürdiges Problem und komme nun nach allem Möglichen rum probieren einfach nicht auf die Ursache...

Vorneweg:
Ja alle Einträge in "/etc/hosts" und "/etc/network/interfaces" sind auf der neuen IP-Range.

Szenario:
Wir machen ein Backup der Produktiven PVE Systeme mittels RSYNC. Um Sicherzustellen das die Backups funktionieren und nicht beschädigt sind würden wir gerne 1x im Jahr einen Restore Test machen auf einem genesteten System (spricht Proxmox als Guest im Physischen Proxmox).

Problem:
Sobald man nun jedoch nach dem Restore den genesteten Host neustartet, fällt das gesamte Produktive Cluster in einen Status "?" (läuft aber weiter und ein wiederherstellen ist durch neustarten der PVE-Dienste kein Problem). Nachdem mir aufgefallen ist das in der corosync.conf die bindaddr und in "/etc/pve/priv/known_hosts" noch verweise auf die originalen IP-Adressen drin waren (und ich mit etwas tricksen diese Einträge mittels pmxcfs -l manuell Nachbearbeiten konnte), passiert das selbe immer noch.

Mit grep auf die Pfade "/etc/pve" und "/var/lib/pve-cluster" konnte ich in der Volltextsuche keine Verweise auf die alte IP-Adresse mehr finden. Auch die config.db enthält nichts mehr dazu. Gibt es noch irgendwo Verweise auf die alte IP-Range in einem Komprimierten oder angepassten Format (z.B. Base64) das ich mit Klartext suchen so gar nicht finden kann?

Irgendjemand eine Idee was ich vergessen haben könnte? Oder müssen wir diese Testumgebung in einem Abgeschirmten Netzwerk Aufbauen?

Vielen Dank schon Mal!

EDIT:
Hier mal noch exakt was Kopiert wurde und wo ich überall die IP-Adresse angepasst habe, vielleicht hilft das etwas das Problem einzugrenzen.

Kopiert:

• /var/lib/pve-cluster/*
• /etc/ssh/*
• /etc/corosync/*
• /etc/hosts
• /etc/network/interfaces
• /etc/passwd
• /etc/passwd-
  
• /etc/shadow
• /etc/shadow-
• /etc/gshadow
• /etc/gshadow-
• /etc/group
• /etc/group-

Angepasst:

• /etc/pve/priv/known_hosts (IP-Adressen angepasst)
• /etc/pve/corosync.conf (bindaddr angepasst)
• /etc/corosync.conf (passierte anscheinend automatisch)
• /etc/hosts (IP-Auflösung per Hostname angepasst)
• /etc/network/interfaces (alles entfernt außer vmbr0 und diese statisch auf die neue Range umgestellt)

In der config.db scheint auch kein Eintrag auf die alten IP-Adressen mehr zu existieren.


Freundliche Grüsse
NexorProject

 

[dcsapak]

wurde die 'echte' corosync.conf auch korrigiert? (/etc/corosync/corosync.conf)

 

[NexorProject]

Wie meinst du ob die echte auch korrigiert wurde? Die auf den Physischen Servern? Wird Arbeiten nur mit den Hostnamen in der Corosync (ring0_addr=hostname) und haben die IP-Adressen lediglich in der "/etc/hosts" Datei stehen. Das einzige was in der Kopie von corosync angepasst werden musste war die "bindaddr" von 172.24.1.X zu 172.24.17.X (16Bit-Maske).

 

[Stoiko Ivanov]

Ich glaube hier geht es um den Umstand, dass PVE die corosync.conf in '/etc/pve/corosync.conf' und in '/etc/corosync/corosync.conf' ablegt.
(Der Grund dafuer ist, dass die Version in /etc/pve ueber das pmxcfs auf den Cluster verteilt wird (und mittels Inotify dann auf /etc/corosync/corosync.conf kopiert wird), einerseits und andererseits, dass corosync laufen muss, damit /etc/pve beschreibbar ist).

Insofern die Frage: ist der inhalt von '/etc/pve/corosync.conf' und '/etc/corosync/corosync.conf' auf allen nodes ident?

 

[NexorProject]

Ah vielen Dank, ich wusste nicht mal das es zwei corosync.conf Dateien gibt. Habe dies jedoch gerade überprüft und auf den Physischen Servern sind beide auf allen Servern identisch mit der bindaddr 172.24.1.X und im genesteten System ist sie ebenfalls an beiden Orten identisch mit der bindaddr 172.24.17.X. Wir haben im übrigen auch keine externe DNS-Auflösung der Hostnamen nur die Einträge in der hosts-Datei.

EDIT: Habe mal im Startpost noch eingefügt was Kopiert wurde und welche Dateien ich angepasst habe um der neuen IP-Range zu entsprechen.

 

[dcsapak]

man sollte außerdem noch den clusternamen anpassen, da corosync die multicast adresse daraus berechnet (dh die node schickt zur gleichen multicast adresse die daten),
oder einfach multicast traffic der vm(s) mittels firewall abfangen

 

[NexorProject]

Aha okay das ergibt noch Sinn. Das heisst also das genestete System schickt einen Multicast mit bezug auf den Clusternamen und wenn die Physischen Server das sehen versuchen diese mit dem genesteten System zu kommunizieren?

Wie passe ich das an? Genügt es den Clusternamen in den corosync-Dateien anzupassen?

 

[dcsapak]

Wie passe ich das an? Genügt es den Clusternamen in den corosync-Dateien anzupassen?

ja sollte genügen, wie gesagt würde es auch sinn machen die test vms per firewall abzuschotten

 

[NexorProject]

Vielen Dank für eure Hilfe! Das mit Multicast war es definitiv. Das genestete System läuft seid einigen Minuten ohne dem echten Cluster Probleme zu machen. Die Firewall Einschränkung war soweit nicht notwendig, ich behalte es jedoch im Hinterkopf sofern es wieder zu Problemen kommt.