[SOLVED] ZFS (replication) Migration VM startet neu
- Thread starter Skyfay
- Start date
prozesse (und nix anderes ist eine VM im endeffekt) koennen ja nicht von einem system aufs andere teleportiert werden
Somit haben wir einen neuen Feature-Request
Last edited:
das journal aus der VM ("journalctl -b-1", wenn die VM gerade migriert und dadurch neugestartet worden ist).
Das müsste folgendes sein (VM25 mit dem Problem in diesem Fall):
Code:
Nov 23 13:47:01 skyv25 qemu-ga[806]: info: guest-ping called
Nov 23 13:47:02 skyv25 qemu-ga[806]: info: guest-fsfreeze called
Nov 23 13:48:01 skyv25 qemu-ga[806]: info: guest-ping called
Nov 23 13:48:01 skyv25 qemu-ga[806]: info: guest-fsfreeze called
Nov 23 13:49:01 skyv25 qemu-ga[806]: info: guest-ping called
Nov 23 13:49:01 skyv25 qemu-ga[806]: info: guest-fsfreeze called
Nov 23 13:50:03 skyv25 qemu-ga[806]: info: guest-ping called
Nov 23 13:50:04 skyv25 qemu-ga[806]: info: guest-fsfreeze called
Nov 23 13:51:01 skyv25 qemu-ga[806]: info: guest-ping called
Nov 23 13:51:02 skyv25 qemu-ga[806]: info: guest-fsfreeze called
Nov 23 13:52:01 skyv25 qemu-ga[806]: info: guest-ping called
Nov 23 13:52:01 skyv25 qemu-ga[806]: info: guest-fsfreeze called
Nov 23 13:53:01 skyv25 qemu-ga[806]: info: guest-ping called
Nov 23 13:53:02 skyv25 qemu-ga[806]: info: guest-fsfreeze called
Nov 23 13:54:01 skyv25 qemu-ga[806]: info: guest-ping called
Nov 23 13:54:02 skyv25 qemu-ga[806]: info: guest-fsfreeze called
Nov 23 13:54:43 skyv25 agetty[1203]: tty1: invalid character 0x1b in login name
Nov 23 13:54:53 skyv25 systemd[1]: getty@tty1.service: Deactivated successfully.
Nov 23 13:54:53 skyv25 systemd[1]: getty@tty1.service: Scheduled restart job, restart counter is at 1.
Nov 23 13:54:53 skyv25 systemd[1]: Stopped Getty on tty1.
Nov 23 13:54:53 skyv25 systemd[1]: Started Getty on tty1.
Nov 23 13:55:01 skyv25 qemu-ga[806]: info: guest-ping called
Nov 23 13:55:02 skyv25 qemu-ga[806]: info: guest-fsfreeze called
-- Boot b8975b02d746455f9fa67011bca862c9 --
Nov 23 13:55:29 skyv25 kernel: Linux version 5.15.0-89-generic (buildd@bos03-amd64-016) (gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #99-Ubuntu SMP Mon Oct 30 20:42:41 UTC 2023 (Ubuntu 5.15.0-89.99-generic 5.15.126)
Nov 23 13:55:29 skyv25 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.15.0-89-generic root=UUID=c7f87cc8-92f8-4dbc-9f81-63628445a393 ro
Nov 23 13:55:29 skyv25 kernel: KERNEL supported cpus:
Nov 23 13:55:29 skyv25 kernel: Intel GenuineIntel
Nov 23 13:55:29 skyv25 kernel: AMD AuthenticAMD
Nov 23 13:55:29 skyv25 kernel: Hygon HygonGenuine
Nov 23 13:55:29 skyv25 kernel: Centaur CentaurHauls
Nov 23 13:55:29 skyv25 kernel: zhaoxin Shanghai
Nov 23 13:55:29 skyv25 kernel: BIOS-provided physical RAM map:
Nov 23 13:55:29 skyv25 kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
Nov 23 13:55:29 skyv25 kernel: BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
Nov 23 13:55:29 skyv25 kernel: BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
Nov 23 13:55:29 skyv25 kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000bffd9fff] usable
Nov 23 13:55:29 skyv25 kernel: BIOS-e820: [mem 0x00000000bffda000-0x00000000bfffffff] reserved
Nov 23 13:55:29 skyv25 kernel: BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
Nov 23 13:55:29 skyv25 kernel: BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
Nov 23 13:55:29 skyv25 kernel: BIOS-e820: [mem 0x0000000100000000-0x000000023fffffff] usable
Nov 23 13:55:29 skyv25 kernel: NX (Execute Disable) protection: active
Nov 23 13:55:29 skyv25 kernel: SMBIOS 3.0.0 present.
Nov 23 13:55:29 skyv25 kernel: DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014
Nov 23 13:55:29 skyv25 kernel: Hypervisor detected: KVM
Nov 23 13:55:29 skyv25 kernel: kvm-clock: Using msrs 4b564d01 and 4b564d00
Nov 23 13:55:29 skyv25 kernel: kvm-clock: cpu 0, msr 167001001, primary cpu clock
Nov 23 13:55:29 skyv25 kernel: kvm-clock: using sched offset of 66315042739403 cycles
Nov 23 13:55:29 skyv25 kernel: clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
Nov 23 13:55:29 skyv25 kernel: tsc: Detected 3417.600 MHz processor
Nov 23 13:55:29 skyv25 kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Nov 23 13:55:29 skyv25 kernel: e820: remove [mem 0x000a0000-0x000fffff] usable
Nov 23 13:55:29 skyv25 kernel: last_pfn = 0x240000 max_arch_pfn = 0x400000000
Nov 23 13:55:29 skyv25 kernel: x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT
Nov 23 13:55:29 skyv25 kernel: last_pfn = 0xbffda max_arch_pfn = 0x400000000
Nov 23 13:55:29 skyv25 kernel: found SMP MP-table at [mem 0x000f5b70-0x000f5b7f]
Nov 23 13:55:29 skyv25 kernel: Using GB pages for direct mapping
Nov 23 13:55:29 skyv25 kernel: RAMDISK: [mem 0x2adcd000-0x316ddfff]
Nov 23 13:55:29 skyv25 kernel: ACPI: Early table checksum verification disabled
Nov 23 13:55:29 skyv25 kernel: ACPI: RSDP 0x00000000000F5960 000014 (v00 BOCHS )
Nov 23 13:55:29 skyv25 kernel: ACPI: RSDT 0x00000000BFFE34AB 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001)
Nov 23 13:55:29 skyv25 kernel: ACPI: FACP 0x00000000BFFE321D 000074 (v01 BOCHS BXPC 00000001 BXPC 00000001)
Nov 23 13:55:29 skyv25 kernel: ACPI: DSDT 0x00000000BFFDF040 0041DD (v01 BOCHS BXPC 00000001 BXPC 00000001)
Nov 23 13:55:29 skyv25 kernel: ACPI: FACS 0x00000000BFFDF000 000040
Nov 23 13:55:29 skyv25 kernel: ACPI: APIC 0x00000000BFFE3291 0000F0 (v03 BOCHS BXPC 00000001 BXPC 00000001)
Nov 23 13:55:29 skyv25 kernel: ACPI: SSDT 0x00000000BFFE3381 0000CA (v01 BOCHS VMGENID 00000001 BXPC 00000001)
Nov 23 13:55:29 skyv25 kernel: ACPI: HPET 0x00000000BFFE344B 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001)
Nov 23 13:55:29 skyv25 kernel: ACPI: WAET 0x00000000BFFE3483 000028 (v01 BOCHS BXPC 00000001 BXPC 00000001)
Nov 23 13:55:29 skyv25 kernel: ACPI: Reserving FACP table memory at [mem 0xbffe321d-0xbffe3290]
Nov 23 13:55:29 skyv25 kernel: ACPI: Reserving DSDT table memory at [mem 0xbffdf040-0xbffe321c]
Nov 23 13:55:29 skyv25 kernel: ACPI: Reserving FACS table memory at [mem 0xbffdf000-0xbffdf03f]
Nov 23 13:55:29 skyv25 kernel: ACPI: Reserving APIC table memory at [mem 0xbffe3291-0xbffe3380]
Nov 23 13:55:29 skyv25 kernel: ACPI: Reserving SSDT table memory at [mem 0xbffe3381-0xbffe344a]
Nov 23 13:55:29 skyv25 kernel: ACPI: Reserving HPET table memory at [mem 0xbffe344b-0xbffe3482]
Nov 23 13:55:29 skyv25 kernel: ACPI: Reserving WAET table memory at [mem 0xbffe3483-0xbffe34aa]
Nov 23 13:55:29 skyv25 kernel: No NUMA configuration found
Nov 23 13:55:29 skyv25 kernel: Faking a node at [mem 0x0000000000000000-0x000000023fffffff]
Nov 23 13:55:29 skyv25 kernel: NODE_DATA(0) allocated [mem 0x23ffd6000-0x23fffffff]
Nov 23 13:55:29 skyv25 kernel: Zone ranges:
Nov 23 13:55:29 skyv25 kernel: DMA [mem 0x0000000000001000-0x0000000000ffffff]
Nov 23 13:55:29 skyv25 kernel: DMA32 [mem 0x0000000001000000-0x00000000ffffffff]
Nov 23 13:55:29 skyv25 kernel: Normal [mem 0x0000000100000000-0x000000023fffffff]
Nov 23 13:55:29 skyv25 kernel: Device empty
Nov 23 13:55:29 skyv25 kernel: Movable zone start for each node
Nov 23 13:55:29 skyv25 kernel: Early memory node ranges
Nov 23 13:55:29 skyv25 kernel: node 0: [mem 0x0000000000001000-0x000000000009efff]
Nov 23 13:55:29 skyv25 kernel: node 0: [mem 0x0000000000100000-0x00000000bffd9fff]
Nov 23 13:55:29 skyv25 kernel: node 0: [mem 0x0000000100000000-0x000000023fffffff]
Nov 23 13:55:29 skyv25 kernel: Initmem setup node 0 [mem 0x0000000000001000-0x000000023fffffff]
Nov 23 13:55:29 skyv25 kernel: On node 0, zone DMA: 1 pages in unavailable ranges
Nov 23 13:55:29 skyv25 kernel: On node 0, zone DMA: 97 pages in unavailable ranges
Nov 23 13:55:29 skyv25 kernel: On node 0, zone Normal: 38 pages in unavailable ranges
Nov 23 13:55:29 skyv25 kernel: ACPI: PM-Timer IO Port: 0x608
Nov 23 13:55:29 skyv25 kernel: ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
Nov 23 13:55:29 skyv25 kernel: IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23
Nov 23 13:55:29 skyv25 kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
Nov 23 13:55:29 skyv25 kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
Nov 23 13:55:29 skyv25 kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Nov 23 13:55:29 skyv25 kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)
Nov 23 13:55:29 skyv25 kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
Nov 23 13:55:29 skyv25 kernel: ACPI: Using ACPI (MADT) for SMP configuration information
Nov 23 13:55:29 skyv25 kernel: ACPI: HPET id: 0x8086a201 base: 0xfed00000
Nov 23 13:55:29 skyv25 kernel: TSC deadline timer available
Nov 23 13:55:29 skyv25 kernel: smpboot: Allowing 16 CPUs, 0 hotplug CPUs
Nov 23 13:55:29 skyv25 kernel: kvm-guest: KVM setup pv remote TLB flush
Nov 23 13:55:29 skyv25 kernel: kvm-guest: setup PV sched yield
Nov 23 13:55:29 skyv25 kernel: PM: hibernation: Registered nosave memory: [mem 0x00000000-0x00000fff]
Nov 23 13:55:29 skyv25 kernel: PM: hibernation: Registered nosave memory: [mem 0x0009f000-0x0009ffff]
Nov 23 13:55:29 skyv25 kernel: PM: hibernation: Registered nosave memory: [mem 0x000a0000-0x000effff]
Nov 23 13:55:29 skyv25 kernel: PM: hibernation: Registered nosave memory: [mem 0x000f0000-0x000fffff]
Nov 23 13:55:29 skyv25 kernel: PM: hibernation: Registered nosave memory: [mem 0xbffda000-0xbfffffff]
Nov 23 13:55:29 skyv25 kernel: PM: hibernation: Registered nosave memory: [mem 0xc0000000-0xfeffbfff]
Nov 23 13:55:29 skyv25 kernel: PM: hibernation: Registered nosave memory: [mem 0xfeffc000-0xfeffffff]
Nov 23 13:55:29 skyv25 kernel: PM: hibernation: Registered nosave memory: [mem 0xff000000-0xfffbffff]
Nov 23 13:55:29 skyv25 kernel: PM: hibernation: Registered nosave memory: [mem 0xfffc0000-0xffffffff]
Nov 23 13:55:29 skyv25 kernel: [mem 0xc0000000-0xfeffbfff] available for PCI devices
Nov 23 13:55:29 skyv25 kernel: Booting paravirtualized kernel on KVM
Nov 23 13:55:29 skyv25 kernel: clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
Nov 23 13:55:29 skyv25 kernel: setup_percpu: NR_CPUS:8192 nr_cpumask_bits:16 nr_cpu_ids:16 nr_node_ids:1
Nov 23 13:55:29 skyv25 kernel: percpu: Embedded 61 pages/cpu s212992 r8192 d28672 u262144
Nov 23 13:55:29 skyv25 kernel: pcpu-alloc: s212992 r8192 d28672 u262144 alloc=1*2097152
Nov 23 13:55:29 skyv25 kernel: pcpu-alloc: [0] 00 01 02 03 04 05 06 07 [0] 08 09 10 11 12 13 14 15
Nov 23 13:55:29 skyv25 kernel: kvm-guest: setup async PF for cpu 0
Nov 23 13:55:29 skyv25 kernel: kvm-guest: stealtime: cpu 0, msr 237a33080
Nov 23 13:55:29 skyv25 kernel: kvm-guest: PV spinlocks enabled
boot.....die vielen qga pings und fsfreeze requests sehen etwas merkwuerdig aus.. sind die im aktuellen log auch? ansonsten steht im log nix von einem reboot, schaut eher nach crash/reset aus..
irgendwelche custom dinge (hook scripts, ...) ? wenn du testweise eine Debian bookworm VM installierst und migrierst, tritt das problem dann auch auf? und was wenn du den guest agent nicht installierst/aktivierst?
edit: ah, ist das replication intervall auf 1 minute gesetzt? das wuerde die ping/freeze thematik erklaeren
irgendwelche custom dinge (hook scripts, ...) ? wenn du testweise eine Debian bookworm VM installierst und migrierst, tritt das problem dann auch auf? und was wenn du den guest agent nicht installierst/aktivierst?
edit: ah, ist das replication intervall auf 1 minute gesetzt? das wuerde die ping/freeze thematik erklaeren
Last edited:
Ich habe Replication auf der VM Aktiv. Dies macht es jede Minute. Vermutlich kommt das daher oder?
Also die VM's sind eigentlich ziemlich Standard. Da ist nix spezielles gemacht nur Docker drauf. Und es passiert ja auch nur beim ersten mal und danach funktioniert die Migration problemlos (bis zum nächsten Reboot der Nodes).
Was mir grad auch aufgefallen ist, die VM's haben sich gerade einfach aufgehängt. Ich musste die beiden gerade Stopen und wieder starten.
Kann es vielleicht Probleme geben weil das früher qcow2 images waren und jetzt zu raw konvertiert wurden?
Das müsste ich mal testen, vielleicht würde es allgemein Sinn die Daten der VM's nochmal raus zu holen und eine neue VM aufzusetzen. Vielleicht sogar mal mit Debian tut vielleicht gut mal mit einem anderen System zu arbeiten als immer nur mit Ubuntu.
Last edited:
Was für ein Problem gibt es denn bei 1 Minute Replikation? Ich habe bei Kunden einige VMs mit 1 Minute Replikation und zum Glück bisher keine Probleme.die vielen qga pings und fsfreeze requests sehen etwas merkwuerdig aus.. sind die im aktuellen log auch? ansonsten steht im log nix von einem reboot, schaut eher nach crash/reset aus..
irgendwelche custom dinge (hook scripts, ...) ? wenn du testweise eine Debian bookworm VM installierst und migrierst, tritt das problem dann auch auf? und was wenn du den guest agent nicht installierst/aktivierst?
edit: ah, ist das replication intervall auf 1 minute gesetzt? das wuerde die ping/freeze thematik erklaeren
Ich denke nicht, dass das ein Problem sein sollte. Ist halt das einzige auffällige gewesen bisher. Ich werde jetzt vermutlich mal versuchen ne neue VM (Debian) aufzusetzen und schauen ob das Problem damit auch besteht.
Also ich habe jetzt mal ne neue VM mit Debian 12 aufgesetzt. Da hatte ich das Problem nicht auch nicht nach einem Reboot der Nodes.
Bei der einen VM welche ich auch im Video als Test hatte, hatte ich das Problem jetzt lustigerweise auch nicht mehr. Jedoch mit der anderen, da passiert es noch immer.
Ich habe es noch nicht getestet mit einer frischen Ubuntu VM aber ich denke ich werde mal alle VM durch Debian austauschen und schauen wie es sich verhält.
Bei der einen VM welche ich auch im Video als Test hatte, hatte ich das Problem jetzt lustigerweise auch nicht mehr. Jedoch mit der anderen, da passiert es noch immer.
Ich habe es noch nicht getestet mit einer frischen Ubuntu VM aber ich denke ich werde mal alle VM durch Debian austauschen und schauen wie es sich verhält.
keine (abseits der ueblichen - die systeme muessen entsprechend dimensoniert sein dass sie mit dem replizieren hinterherkommen
) - es war nur die erklaerung fuer die logeintrage in der VM die mich zuerst gewundert haben 
Sind die beiden VMs gleich konfiguriert? Auch mit z. B. dem Sync Intervall etc. pp.?
Vielleicht gibt es auch einen Zusammenhang mit dem Sync Intervall von 1 Minute und einer laufenden Migration. Wenn sich da irgendwas in die Quere kommt, könnte das womöglich den Neustart verursachen. Vielleicht ist es deshalb auch nur Zufall, dass es jetzt da funktioniert und bei der anderen nicht.
Rekonstruierbar scheint mir das aber auch nicht zu sein, da kann man nur versuchen laufend hin und her zu replizieren um vielleicht doch noch in den Fehler zu laufen.
Aber eigentlich auch wenn es daran liegt, sollte ja in irgendeinem Log auch ersichtlich sein, dass irgendwas zum Abbruch des Prozess geführt hat.
Kannst du uns hier vielleicht mal eine Gesamtübersicht geben? Also welche Hardware hat dein Cluster, wie das Netzwerk der Nodes konfiguriert, wie sind die Verbunden, wie sehen deine VM Configs aus, wie sehen deine ZFS Pools aus, Übersicht über den Zustand der Disks, Log Protokolle zum fraglichen Zeitpunkt von beiden Nodes und aus der VM etc. pp.
Vielleicht finden sich hierbei unterschiede oder Gemeinsamkeiten, welche auf ein Problem schließen lassen könnten.
Nein, die wichtigen VM's habe ich auf einer Minute und bei den VM's bei welcher sich die Konfig so gut wie nicht ändert habe ich mehr Zeit dazwischen. Bei der, bei welcher es plötzlich funktioniert hatte sind 30 Minuten eingestellt. Bei den problematischen VM's ist aktuell 1 Minute drinnen. Aber wie gesagt es tritt irgendwie nur bei der ersten Migration nach einem Boot auf. Zumindest das was ich bisher gefunden habe.
- Die Disks sind beide ganz neu (8TB Enterprise SSD's) jeweils eine pro Server. Konfiguriert auf ZFS (Installation's Menu Raid 0) ich nutze die Standard Partitionierung habe nichts weiter angepasst.
- Genauso beim Netzwerk da ist nichts spezielles konfiguriert. Nur ist Node 07 ab und zu nicht mehr erreichbar irgendwas anderes ist da noch faul aber weiss noch nichts was (Netzwerk Karte oder sonstiges). Sollte aber nichts mit diesem Problem zu tun haben.
- Die Log Protokolle habe ich bereits hier im Chat hinterlegt, viel anderes ist leider nicht ersichtlich.
- Als ich das letztens getestet hatte mit LVM war es noch ein Mini Server und ein NUC mit Consumer SSD und NFS als Speicher sowie LVM-thin. Jetzt sind es zwei Mini Server mit Enterprise SSD. Das ist das einzige was sich geändert hat. Aber ich gehe nicht davon aus dass Hardware hier etwas zu tun hat.
Vielleicht kannst du das mal auf 5 Minuten stellen und prüfen ob es weiterhin auftritt?
Würde ich pauschal nicht ausschließen. Auch wenn du schreibst, dass du Netzwerkprobleme hast - hierbei ist die Frage welche Probleme das sind, ob womöglich das Board oder Chipsatz was abbekommen hat.
Kannst du das tatsächlich gesichert nachstellen?
Kannst du sagen ob es von beiden in beide Richtungen auftritt oder tritt es nur von z. B. Node 2 nach Node 1 auf aber nach einem Reboot nicht bei der Migration von Node 1 nach Node 2.
Das ist aber unvollständig (du hast nur das Migrationslog und einmal journalctl von der VM gepostet). Mich würde hier mal das syslog von allen involvierten Maschinen interessieren, was während der Migration mitgeschrieben wird. Da lassen sich vielleicht entsprechende Anomalien erkennen die einen Rückschluss geben könnten. Vielleicht auch nicht. Aber ohne kann man immer nur spekulieren und nichts handfestes nachvollziehen.
Mir geistert schon die ganze Zeit der Gedanke Netzwerk durch den Kopf, wenn ich das lese. Da ihr auf einem Node Aussetzer habt, bestärkt mich das.
Wie sieht denn das Netzwerk aus?
Wenn es mit den neuen VM's nicht mehr funktioniert, dann würde ich das als nächstes testen, ja.
Also beide Server haben eine PCIE 10GbE Karte verbaut. Diese sind dann mit einem Ubiquiti UniFi Flex XG verbunden. Im Netzwerk selber sind noch weitere Unifi Switches enthalten. Ich habe gestern zur Netzwerk Karte (TP-Link TX401) bisschen recherchiert und auch jemanden mit Netzwerk Problemen und Proxmox gefunden. Bei ihm war es jedoch vermutlich ein Lan Kabel Problem. Auf jeden Fall habe ich durch die Recherchen mal bei meinen Switches das STP (Spanning Tree Protocol) deaktiviert. Habe da gelesen dass es eventuell damit Probleme geben könnte.
Was genau passiert ist, dass ich mich mit dem Node (Bissher nur mit einem passiert) nicht mehr über das Web Interface verbinden kann. Danach schaue ich ob man ihn pingen kann, geht dann auch nicht. Auf dem Switch sehe ich dass der Port verbunden ist, aber er kann nicht mal den Hostname ablesen also irgendwas passiert da. Und wenn ich mich mit dem zweiten Node verbinde ist der Node 1 halt nicht erreichbar.
Das ist mir jetzt schon ca. 3x passiert. Das einzige was hilft ist den Host komplett herunterzufahren und neu zu booten. Dann läuft es wieder normal. Es hilft auch nix wenn er noch läuft das Netzwerk Kabel neu zu verbinden hab ich bereits probiert.
Also die VM's die Probleme machen, funktionieren nach dem 1. Fehler bei der Migration dann ohne Reboot. Also das erste mal startet er nach der Migration neu und danach kann ich die VM verschieben wie ich möchte klappt eigentlich ohne Probleme.
Der Fehler tritt soweit ich getestet habe von beiden Nodes auf also von Node 1 zu 2 und 2 zu 1 jeweils das Problem schon gehabt.
Wenn alles nichts hilft könnte man da weiter suchen aber das ist relativ viel Aufwand hoffe wir finden vielleicht ne andere Lösung.
Da der Fehler halt sehr unregelmäßig und selten auftritt ist es nicht ganz einfach nachzuvollziehen wo das Problem liegt. Also es passiert ja nicht stündlich oder täglich sondern vielleicht so 1-3x die Woche.