Migration einert VM scheitert in PVE 6.0

thz

Member
Jul 31, 2015
26
2
23
Terra
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

Member
Jul 31, 2015
26
2
23
Terra
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

Proxmox Staff Member
Staff member
Aug 1, 2018
522
40
28
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

Member
Jul 31, 2015
26
2
23
Terra
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

Proxmox Staff Member
Staff member
Aug 1, 2018
522
40
28
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

Member
Jul 31, 2015
26
2
23
Terra
> 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

Proxmox Staff Member
Staff member
Aug 1, 2018
522
40
28
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

Member
Jul 31, 2015
26
2
23
Terra
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

Member
Jul 31, 2015
26
2
23
Terra
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

Proxmox Staff Member
Staff member
Aug 1, 2018
522
40
28
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

Member
Jul 31, 2015
26
2
23
Terra
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

Proxmox Staff Member
Staff member
Aug 1, 2018
522
40
28
Wurde etwas an der SSH Config geändert? Diese zusätzlichen Control Sequences sollten da nicht sein.
 

thz

Member
Jul 31, 2015
26
2
23
Terra
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.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE and Proxmox Mail Gateway. We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get your own in 60 seconds.

Buy now!