Migration einert VM scheitert in PVE 6.0

thz · Aug 29, 2019

Ich habe 3 Nodes mit PVE 6.0 und Ceph. Das System läuft mit Debian 10 und den Buster-Paketen von pve. Ich hatte es von Proxmox 5.x geupdated. Die Konfiguration vorher (Debian stretch) war nur Basis. Mit dem Update auf pve 6 habe ich auch ceph installiert und die OSDs (mit crypt) eingerichtet.

Es funktioniert soweit auch alles, soweit ich das überblicke, bis auf die Migration einer VM auf einen anderen Node.
Starte ich die online migration kommt als erstes in dem Fenster:

Code:

no content

Als Fehlermeldung steht dann:
TASK ERROR: command '/usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=pve01-b' root@192.168.100.101 pvecm mtunnel -migration_network 192.168.100.100/25 -get_migration_ip' failed: internal error: unexpected output from mtunnel

Code:

TASK ERROR: command '/usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=node2' root@192.168.1.11 pvecm mtunnel -migration_network 192.168.1.10/24 -get_migration_ip' failed: internal error: unexpected output from mtunnel

Für Ceph gibt es ein eigenes Netz mit extra Interfaces. Über dieses Netz (192.169.1.0/24) läuft corosync und alles was mit synchronisation zu tun hat. Eine gleiche Konfiguration habe ich mit 3 anderen Nodes, allerdings läuft da noch pve 5.4 drauf.

Ich weiß gerade nicht mehr weiter und finde nichts hilfreiches zu der Fehlermeldung bezüglich "mtunnel"

Achja ..., das "migration_network" habe ich in der Datei /etc/pve/datacenter.cfg manuell auf 192.168.1.0/24 gestellt. Aber auch dann geht es nicht und endet mit der obigen Fehlermeldung (nur eben anderem network).

thz · Aug 29, 2019

Eine Lösung ist offenbar, die Zeile

Code:

migration: network=192.168.1.0/24,type=secure

aus der Datei /etc/pve/datacenter.cfg zu entfernen. Danach klappt die Migration auf einen anderen Node sofort.

Im Webinterface findet man diese Stelle in "Rechenzentrum" -> Optionen -> Migration Settings.

Wozu ist diese Option und offenbar macht sie nicht das, was der Name suggeriert.

mira · Aug 29, 2019

Bitte den Befehl /usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=node2' root@192.168.1.11 manuell ausführen und schauen ob es eine Fehlermeldung gibt.

thz · Sep 2, 2019

Es gibt keine Meldung bei diesem Kommando. Hatte mal noch -v dazu genommen. Aber auch nichts.

Wie gesagt, wenn ich das oben beschriebene mache, also die Zeile lösche, geht es.

mira · Sep 2, 2019

Die ssh Verbindung funktioniert also problemlos mit dem Befehl? Welches Netzwerk wird by default genommen?
Poste bitte die corosync config (/etc/pve/corosync.conf), die datacenter config und /etc/network/interfaces (falls public IPs drin sind, maskieren).

thz · Sep 2, 2019

> cat /etc/pve/corosync.conf

Code:

logging {
  debug: off
  to_syslog: yes
}

nodelist {
  node {
    name: node01
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 192.168.1.10
  }
  node {
    name: node02
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 192.168.1.11
  }
  node {
    name: node03
    nodeid: 3
    quorum_votes: 1
    ring0_addr: 192.168.1.12
  }
}

quorum {
  provider: corosync_votequorum
}

totem {
  cluster_name: proxmox
  config_version: 3
  interface {
    linknumber: 0
  }
  ip_version: ipv4-6
  secauth: on
  version: 2
}

> cat /etc/pve/datacenter.cfg

Code:

keyboard: de

> cat /etc/network/interfaces

Code:

allow-vmbr0 bond0
iface bond0 inet manual
    ovs_bonds eno1 eno2
    ovs_type OVSBond
    ovs_bridge vmbr0
    mtu 9000
    ovs_options lacp=active bond_mode=balance-tcp other_config:lacp-time=fast
        pre-up ( ip link set eno1 mtu 9000 && ip link set eno2 mtu 9000 )
#Bonding LAN

allow-vmbr1 bond1
iface bond1 inet manual
    ovs_bonds enp19s0f0 enp19s0f1
    ovs_type OVSBond
    ovs_bridge vmbr1
    mtu 9000
    ovs_options other_config:lacp-time=fast bond_mode=balance-tcp lacp=active
        pre-up ( ip link set enp19s0f0 mtu 9000 && ip link set enp19s0f1 mtu 9000 )
#Bonding HCI net for Ceph and corosync

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

iface enp19s0f0 inet manual

iface enp19s0f1 inet manual

iface eno1 inet manual

iface eno2 inet manual

auto vmbr0
iface vmbr0 inet manual
    ovs_type OVSBridge
    ovs_ports bond0 vmbr0-lan
    mtu 9000

allow-vmbr0 vmbr0-lan
iface vmbr0-lan inet static
    address 10.10.20.10/24
    gateway 10.10.20.1
        ovs_type OVSIntPort
        ovs_bridge vmbr0
        ovs_options tag=20
#Bridge for LAN

auto vmbr1
iface vmbr1 inet static
    address  192.168.1.10
    netmask  255.255.255.0
    ovs_type OVSBridge
    ovs_ports bond1
    mtu 9000
#Bridge HCO net for Ceph and corosync

Die SSH-Verbindung zum anderen Server funktioniert:
root@192.168.1.10:> /usr/bin/ssh -i /root/.ssh/id_rsa root@192.168.1.11
root@192.168.1.11:> _

Steht in "/etc/pve/datacenter.cfg"

Code:

migration: network=192.168.1.0/24,type=secure

drin, dann geht das Migrieren von VMs nicht mehr.

mira · Sep 3, 2019

Konnte es hier lokal leider nicht nachstellen. Poste bitte den Output von 'pveversion -v' von allen Nodes.
Das Migration Netzwerk wurde direkt über die datacenter.cfg eingetragen oder auch übers GUI?

thz · Sep 3, 2019

Alle 3 Nodes laufen mit Debian 10.x (Buster). Der Eintrag in die Datei datacenter.cfg erfolgte per GUI.

Code:

node01: ~/ $ pveversion -v
proxmox-ve: 6.0-2 (running kernel: 5.0.21-1-pve)
pve-manager: 6.0-6 (running version: 6.0-6/c71f879f)
pve-kernel-5.0: 6.0-7
pve-kernel-helper: 6.0-7
pve-kernel-4.15: 5.4-8
pve-kernel-5.0.21-1-pve: 5.0.21-1
pve-kernel-4.15.18-20-pve: 4.15.18-46
ceph: 14.2.2-pve1
ceph-fuse: 14.2.2-pve1
corosync: 3.0.2-pve2
criu: 3.11-3
glusterfs-client: 5.5-3
libjs-extjs: 6.0.1-10
libknet1: 1.11-pve1
libpve-access-control: 6.0-2
libpve-apiclient-perl: 3.0-2
libpve-common-perl: 6.0-4
libpve-guest-common-perl: 3.0-1
libpve-http-server-perl: 3.0-2
libpve-storage-perl: 6.0-7
libqb0: 1.0.5-1
lvm2: 2.03.02-pve3
lxc-pve: 3.1.0-64
lxcfs: 3.0.3-pve60
novnc-pve: 1.0.0-60
openvswitch-switch: 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.0-7
pve-cluster: 6.0-5
pve-container: 3.0-5
pve-docs: 6.0-4
pve-edk2-firmware: 2.20190614-1
pve-firewall: 4.0-7
pve-firmware: 3.0-2
pve-ha-manager: 3.0-2
pve-i18n: 2.0-2
pve-qemu-kvm: 4.0.0-5
pve-xtermjs: 3.13.2-1
qemu-server: 6.0-7
smartmontools: 7.0-pve2
spiceterm: 3.1-1
vncterm: 1.6-1

node02: ~/ $ pveversion -v
proxmox-ve: 6.0-2 (running kernel: 5.0.21-1-pve)
pve-manager: 6.0-6 (running version: 6.0-6/c71f879f)
pve-kernel-5.0: 6.0-7
pve-kernel-helper: 6.0-7
pve-kernel-4.15: 5.4-8
pve-kernel-5.0.21-1-pve: 5.0.21-1
pve-kernel-5.0.18-1-pve: 5.0.18-3
pve-kernel-4.15.18-20-pve: 4.15.18-46
ceph: 14.2.2-pve1
ceph-fuse: 14.2.2-pve1
corosync: 3.0.2-pve2
criu: 3.11-3
glusterfs-client: 5.5-3
libjs-extjs: 6.0.1-10
libknet1: 1.11-pve1
libpve-access-control: 6.0-2
libpve-apiclient-perl: 3.0-2
libpve-common-perl: 6.0-4
libpve-guest-common-perl: 3.0-1
libpve-http-server-perl: 3.0-2
libpve-storage-perl: 6.0-7
libqb0: 1.0.5-1
lvm2: 2.03.02-pve3
lxc-pve: 3.1.0-64
lxcfs: 3.0.3-pve60
novnc-pve: 1.0.0-60
openvswitch-switch: 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.0-7
pve-cluster: 6.0-5
pve-container: 3.0-5
pve-docs: 6.0-4
pve-edk2-firmware: 2.20190614-1
pve-firewall: 4.0-7
pve-firmware: 3.0-2
pve-ha-manager: 3.0-2
pve-i18n: 2.0-2
pve-qemu-kvm: 4.0.0-5
pve-xtermjs: 3.13.2-1
qemu-server: 6.0-7
smartmontools: 7.0-pve2
spiceterm: 3.1-1
vncterm: 1.6-1

node03: ~/ $ pveversion -v
proxmox-ve: 6.0-2 (running kernel: 5.0.21-1-pve)
pve-manager: 6.0-6 (running version: 6.0-6/c71f879f)
pve-kernel-5.0: 6.0-7
pve-kernel-helper: 6.0-7
pve-kernel-4.15: 5.4-8
pve-kernel-5.0.21-1-pve: 5.0.21-1
pve-kernel-4.15.18-20-pve: 4.15.18-46
ceph: 14.2.2-pve1
ceph-fuse: 14.2.2-pve1
corosync: 3.0.2-pve2
criu: 3.11-3
glusterfs-client: 5.5-3
libjs-extjs: 6.0.1-10
libknet1: 1.11-pve1
libpve-access-control: 6.0-2
libpve-apiclient-perl: 3.0-2
libpve-common-perl: 6.0-4
libpve-guest-common-perl: 3.0-1
libpve-http-server-perl: 3.0-2
libpve-storage-perl: 6.0-7
libqb0: 1.0.5-1
lvm2: 2.03.02-pve3
lxc-pve: 3.1.0-64
lxcfs: 3.0.3-pve60
novnc-pve: 1.0.0-60
openvswitch-switch: 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.0-7
pve-cluster: 6.0-5
pve-container: 3.0-5
pve-docs: 6.0-4
pve-edk2-firmware: 2.20190614-1
pve-firewall: 4.0-7
pve-firmware: 3.0-2
pve-ha-manager: 3.0-2
pve-i18n: 2.0-2
pve-qemu-kvm: 4.0.0-5
pve-xtermjs: 3.13.2-1
qemu-server: 6.0-7
smartmontools: 7.0-pve2
spiceterm: 3.1-1
vncterm: 1.6-1

thz · Jul 10, 2020

Gibt es hierzu neue Erkenntnisse?

Ich habe nun einen weiteren 2-Node-Cluster (node08 und node09) mit jeweils lokalem ZFS-Storage.

In der Datei "/etc/pve/datacenter.cfg" steht:

keyboard: de
migration: network=192.168.30.64/26,type=secure

Versuche ich mittels Web-GUI eine VM von einem Node auf den anderen zu migrieren wird es mit dieser Meldung quittiert:

TASK ERROR: command '/usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=node09' root@192.168.30.101 pvecm mtunnel -migration_network 192.168.30.64/26 -get_migration_ip' failed: internal error: unexpected output from mtunnel

Bei einer Migration ohne diese Zeile ("migration: network......") in der Datei "/etc/pve/datacenter.cfg" funktioniert alles.

Die PVE-Version ist folgende:

node08: ~/ $ pveversion -v
proxmox-ve: 6.2-1 (running kernel: 5.4.44-2-pve)
pve-manager: 6.2-6 (running version: 6.2-6/ee1d7754)
pve-kernel-5.4: 6.2-4
pve-kernel-helper: 6.2-4
pve-kernel-5.4.44-2-pve: 5.4.44-2
pve-kernel-5.4.44-1-pve: 5.4.44-1
ceph-fuse: 14.2.9-pve1
corosync: 3.0.4-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: 0.8.35+pve1
libjs-extjs: 6.0.1-10
libknet1: 1.16-pve1
libproxmox-acme-perl: 1.0.4
libpve-access-control: 6.1-1
libpve-apiclient-perl: 3.0-3
libpve-common-perl: 6.1-3
libpve-guest-common-perl: 3.0-10
libpve-http-server-perl: 3.0-5
libpve-storage-perl: 6.1-8
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 4.0.2-1
lxcfs: 4.0.3-pve3
novnc-pve: 1.1.0-1
openvswitch-switch: 2.12.0-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.2-8
pve-cluster: 6.1-8
pve-container: 3.1-8
pve-docs: 6.2-4
pve-edk2-firmware: 2.20200531-1
pve-firewall: 4.1-2
pve-firmware: 3.1-1
pve-ha-manager: 3.0-9
pve-i18n: 2.1-3
pve-qemu-kvm: 5.0.0-4
pve-xtermjs: 4.3.0-1
pve-zsync: 2.0-3
qemu-server: 6.2-3
smartmontools: 7.1-pve2
spiceterm: 3.1-1
vncterm: 1.6-1
zfsutils-linux: 0.8.4-pve1

Viele Grüße

mira · Jul 10, 2020

Was ist der Output wenn der Befehl ssh root@192.168.30.101 pvecm mtunnel -migration_network 192.168.30.64/26 -get_migration_ip ausgeführt wird?

thz · Jul 13, 2020

Die Antwort ist die IP die ich aufrufe sowie offenbar eine "clear"-Sequenze. Ich habe alles mal in eine Datei umgeleitet:

ip: '192.168.30.101'
^[[H^[[2J^[[3J

Rufe ich den Befehl ohne Umleitung auf, wird nichts angezeigt nach dem "kurzen" Login.

mira · Jul 14, 2020

Wurde etwas an der SSH Config geändert? Diese zusätzlichen Control Sequences sollten da nicht sein.

thz · Jul 15, 2020

Nein, die ist so geblieben. Ich habe nun gesehen, dass die Sequenz aus der bash.bashrc kommt:

trap clear 0 #Bildschirm löschen bei logout

Habe die Zeile mal auskommentiert. Nun kommt das:

node08: ~/ $ ssh root@192.168.30.101 pvecm mtunnel -migration_network 192.168.30.64/26 -get_migration_ip
ip: '192.168.30.101'

Ich habe es nun noch einmal getestet und kann folgendes feststellen:

Wenn "trap clear 0" in der /etc/bash.bashrc eingetragen ist, kann keine VM migriert werden, wenn die Zeile

migration: network=192.168.30.64/26,type=secure

in der Datei /etc/pve/datacenter.cfg eingetragen ist.

Ohne "trap clear 0" funktioniert alles wie erwartet.

Search

Search

Migration einert VM scheitert in PVE 6.0

thz

Member

thz

Member

mira

Proxmox Staff Member

thz

Member

mira

Proxmox Staff Member

thz

Member

mira

Proxmox Staff Member

thz

Member

thz

Member

mira

Proxmox Staff Member

thz

Member

mira

Proxmox Staff Member

thz

Member