[SOLVED] Migrationsprobleme

crmspezi

Renowned Member
Sep 5, 2019
427
34
68
45
Germany/Thueringen
Hallo zusammen,
schon seit längerer Zeit beobachte ich folgendes:


Ich habe in einem Proxmox Cluster bei einer VM zwei Replikationen (bei Node1) zu unterschiedlichen Nodes (Node2 und Node3) laufen. Das funktioniert. Die Migration über die WebGUI scheiert meistens bei mehr als einer Replikation, so das ich einmal repliziere, dann per winscp von /etc/pve/nodes/Node1/qemu-server/100.conf zu /etc/pve/nodes/Node2/qemu-server/100.conf verschiebe. Dabei zerstört sich offensichtlich die Replikation zu Node3.

Warum passiert das? Und warum kann ich nur im ausgeschalteten Zustand EFI-VMs migrieren? Seabios VMs funktioniert die migration auch Online.

Danke vorab.
 
Hi,
wenn Du einfach manuell Dateien verschiebst, kann Proxmox VE nicht immer drauf reagieren/Bescheid wissen. Bitte mal die Task-Logs von den fehlgeschlagenen Migrationen posten, die VM-Konfigurationen qm config ID (mit der echten ID) und die Ausgabe von pveversion -v von Quell- und Ziel-Knoten.
 
Hi,
wenn Du einfach manuell Dateien verschiebst, kann Proxmox VE nicht immer drauf reagieren/Bescheid wissen. Bitte mal die Task-Logs von den fehlgeschlagenen Migrationen posten, die VM-Konfigurationen qm config ID (mit der echten ID) und die Ausgabe von pveversion -v von Quell- und Ziel-Knoten.
Hallo, das ist ja der Notbehelf mit dem manuellen Verschieben. Es scheint so das die Migration über die WebGUI nicht funktioniert (abbricht, gleich beim Beginn), wenn mehr als eine Replikation angelegt ist (also zu 2 Nodes).
 
Das sollte nicht passieren. Bitte den gesamten Task-Log teilen (doppelklick auf VM ID - Migrate unten in der UI) bzw. die genaue Fehlermeldung. Wenn es das nicht gibt bitte im System-Log/Journal nachschauen.
 
Hi crmspezi,
hattest du die VMs vor dem manuellen Verschieben immer ausgeschaltet?
Prüfe auch mal mit ps -ef | grep '/usr/bin/kvm -id <vmid>
ob auf beiden Hosts noch die VM Prozesse laufen, die ggf. der Replikation in die Quere kommen?
Bei der Replikation handelt es sich vermutlich um die ZFS-basierte Snapshot-Replikation?

Bei ausgeschalteten VMs sollte es in einem Cluster eigentlich ausreichen, auf einem einzelnen Knoten die vmid.conf
zu verschieben e.g. mv /etc/pve/nodes/Node1/qemu-server/100.conf /etc/pve/nodes/Node2/qemu-server/100.conf
Das Clusterfilesystem übernimmt dann die Replikation nativ.
Bei eingeschalteten VMs aber definitiv ein Vorgang der zu Problemen führt.

BG, Lucas
 
Hi crmspezi,
hattest du die VMs vor dem manuellen Verschieben immer ausgeschaltet?
Prüfe auch mal mit ps -ef | grep '/usr/bin/kvm -id <vmid>
ob auf beiden Hosts noch die VM Prozesse laufen, die ggf. der Replikation in die Quere kommen?
Bei der Replikation handelt es sich vermutlich um die ZFS-basierte Snapshot-Replikation?

Bei ausgeschalteten VMs sollte es in einem Cluster eigentlich ausreichen, auf einem einzelnen Knoten die vmid.conf
zu verschieben e.g. mv /etc/pve/nodes/Node1/qemu-server/100.conf /etc/pve/nodes/Node2/qemu-server/100.conf
Das Clusterfilesystem übernimmt dann die Replikation nativ.
Bei eingeschalteten VMs aber definitiv ein Vorgang der zu Problemen führt.

BG, Lucas
Hallo Lucas,
genau so habe ich es ja oben beschrieben. Eingeschaltet über WebGUI geht ja nicht mit EFI Disk. Im Dateisystem (Cluster) funktioniert dies mit dem Verschieben, aber damit zerstöre ich die 2. Replikationskette. Woher soll Host2 dann was von den Snapshot auf Host3 wissen? Damit muss ich diese Aufwendig reparieren oder neu machen. Bei 4TB fast unmöglich.
Das sollte nicht passieren. Bitte den gesamten Task-Log teilen (doppelklick auf VM ID - Migrate unten in der UI) bzw. die genaue Fehlermeldung. Wenn es das nicht gibt bitte im System-Log/Journal nachschauen.
Hi Fiona,
ich probiere das heute und melde mich.
 
Hallo Lucas,
genau so habe ich es ja oben beschrieben. Eingeschaltet über WebGUI geht ja nicht mit EFI Disk. Im Dateisystem (Cluster) funktioniert dies mit dem Verschieben, aber damit zerstöre ich die 2. Replikationskette. Woher soll Host2 dann was von den Snapshot auf Host3 wissen? Damit muss ich diese Aufwendig reparieren oder neu machen. Bei 4TB fast unmöglich.

Hi Fiona,
ich probiere das heute und melde mich.
Diesmal lief alles ohne Probleme, trotz 2-facher Replikation. Ok, erstmal Danke.
 
  • Like
Reactions: bl1mp
Ich konnte es nachstellen, warum eine Migration im ausgeschalteten Zustand manchmal nicht möglich war.

Der Button zur Migration war dann immer ausgegraut.

Einfach ein anderes Ziel im Cluster mit gleichem möglichen Datenträgern wählen (wie ZFSDATA1 und ZFSDATA2), dann zurück zum Wunsch Ziel, dann ist auch der Button wieder aktiv. Das war der Grund warum ich über scp verschoben hatte und dadurch nur Ärger dann hatte.

So gehts bei mir jedenfalls nun auch mit zwei Repl. Partnern.

Viele Grüße
crmspezi
 
Ich konnte es nachstellen, warum eine Migration im ausgeschalteten Zustand manchmal nicht möglich war.

Der Button zur Migration war dann immer ausgegraut.

Einfach ein anderes Ziel im Cluster mit gleichem möglichen Datenträgern wählen (wie ZFSDATA1 und ZFSDATA2), dann zurück zum Wunsch Ziel, dann ist auch der Button wieder aktiv. Das war der Grund warum ich über scp verschoben hatte und dadurch nur Ärger dann hatte.
Was ist die Ausgabe von pveversion -v, qm config ID mit der echten ID von der VM und cat /etc/pve/storage.cfg während das Problem auftritt?
 
Ich hab nix von Fehlermeldung gesagt. Ein nicht-aktiver Button, der aktiv sein sollte, ist auch ein Problem. Oder habe ich jetzt falsch verstanden, und es war erwartet, dass der Button nicht aktiv war?
 
Ich hab nix von Fehlermeldung gesagt. Ein nicht aktiver Button, der aktiv sein sollte, ist auch ein Problem. Oder habe ich jetzt falsch verstanden, und es war erwartet, dass der Button nicht aktiv war?
Ja er hätte aktiv sein müssen. Ich kann es erst am WE nachstellen da die VM produktiv ist
 
Diesmal lief alles ohne Probleme, trotz 2-facher Replikation. Ok, erstmal Danke.

Mein Gedanke, war das wenn man nicht immer sauber von Hand checkt, manchmal auch ggf. ein einzelner noch stehender qemu Prozess dort ggf. wegen offenen Filehandles Problem verursacht hat. Meine Frage war nicht ausreichend präzise formuliert :) Mea culpa.
Meine Überlegung war in die Richtung, ob es jedes mal geprüft worden ist, um einzelne noch verbliebende Prozesse auszuschließen.


Die Fragen von Fiona nach den Storages cat /etc/pve/storage.cfg und und der VM Konfiguration qm config ID
sind wichtig für das Verständnis. Wenn die Konfigurationen der Hosts nicht kompatibel sind, z.B. weil die Storages unterschiedlich heißen, kann die VM nicht migriert werden. Bei fehlenden Netzwerkinterfaces z.B. diese auch nicht gestartet werden.

BG, Lucas