Massenmigration | conntrack state migration not supported

[superwinni2]

Hallo

ich habe ein Proxmox Cluster.
Wenn ich meine VMs händisch von Maschine1 auf Maschine2 migriere so funktioniert dies auch mit conntrack:

2026-11-09 16:24:25 use dedicated network address for sending migration traffic (10.46.24.34)
2026-11-09 16:24:25 starting migration of VM 177 to node 'pmve4' (10.46.24.34)
2026-11-09 16:24:25 starting VM 177 on remote node 'pmve4'
2026-11-09 16:24:29 start remote tunnel
2026-11-09 16:24:29 ssh tunnel ver 1
2026-11-09 16:24:29 starting online/live migration on tcp:10.46.24.34:60001
2026-11-09 16:24:29 set migration capabilities
2026-11-09 16:24:29 migration downtime limit: 100 ms
2026-11-09 16:24:29 migration cachesize: 1.0 GiB
2026-11-09 16:24:29 set migration parameters
2026-11-09 16:24:29 start migrate command to tcp:10.46.24.34:60001
2026-11-09 16:24:30 migration active, transferred 1.1 GiB of 8.0 GiB VM-state, 1.1 GiB/s
2026-11-09 16:24:31 migration active, transferred 2.2 GiB of 8.0 GiB VM-state, 1.1 GiB/s
2026-11-09 16:24:32 migration active, transferred 3.3 GiB of 8.0 GiB VM-state, 1.1 GiB/s
2026-11-09 16:24:33 migration active, transferred 4.4 GiB of 8.0 GiB VM-state, 1.1 GiB/s
2026-11-09 16:24:34 migration active, transferred 5.5 GiB of 8.0 GiB VM-state, 1.1 GiB/s
2026-11-09 16:24:35 migration active, transferred 6.5 GiB of 8.0 GiB VM-state, 1.1 GiB/s
2026-11-09 16:24:37 average migration speed: 1.0 GiB/s - downtime 206 ms
2026-11-09 16:24:37 migration completed, transferred 7.6 GiB VM-state
2026-11-09 16:24:37 migration status: completed
2026-11-09 16:24:37 stopping migration dbus-vmstate helpers
2026-11-09 16:24:37 migrated 0 conntrack state entries
2026-11-09 16:24:39 flushing conntrack state for guest on source node
2026-11-09 16:24:42 migration finished successfully (duration 00:00:17)
TASK OK

Mache ich dies jedoch über eine Massenmigration kommt, dass dies nicht supported ist.

2026-11-09 16:24:20 conntrack state migration not supported or disabled, active connections might get dropped
2026-11-09 16:24:20 use dedicated network address for sending migration traffic (10.46.24.34)
2026-11-09 16:24:20 starting migration of VM 174 to node 'pmve4' (10.46.24.34)
2026-11-09 16:24:20 starting VM 174 on remote node 'pmve4'
2026-11-09 16:24:23 start remote tunnel
2026-11-09 16:24:24 ssh tunnel ver 1
2026-11-09 16:24:24 starting online/live migration on tcp:10.46.24.34:60000
2026-11-09 16:24:24 set migration capabilities
2026-11-09 16:24:24 migration downtime limit: 100 ms
2026-11-09 16:24:24 migration cachesize: 1.0 GiB
2026-11-09 16:24:24 set migration parameters
2026-11-09 16:24:24 start migrate command to tcp:10.46.24.34:60000
2026-11-09 16:24:25 migration active, transferred 1.1 GiB of 6.0 GiB VM-state, 1.1 GiB/s
2026-11-09 16:24:26 migration active, transferred 2.2 GiB of 6.0 GiB VM-state, 1.1 GiB/s
2026-11-09 16:24:27 migration active, transferred 3.3 GiB of 6.0 GiB VM-state, 1.1 GiB/s
2026-11-09 16:24:28 migration active, transferred 4.4 GiB of 6.0 GiB VM-state, 1.1 GiB/s
2026-11-09 16:24:29 average migration speed: 1.2 GiB/s - downtime 67 ms
2026-11-09 16:24:29 migration completed, transferred 5.8 GiB VM-state
2026-11-09 16:24:29 migration status: completed
2026-11-09 16:24:33 migration finished successfully (duration 00:00:13)
TASK OK

Gibt es einen Weg wie dies auch über die Massenmigration klappt?

 

[Bu66as]

Die Massenmigration gibt das Flag für die conntrack-Übernahme wohl nicht mit. Beim normalen Migrate-Dialog setzt die GUI with-conntrack-state mit, der Bulk-Endpoint migrateall macht das aber AFAIK nicht. Darum kommt gleich am Anfang die Meldung "not supported or disabled" und am Ende fehlt auch das "migrated X conntrack state entries".

Als Workaround kannst du die VMs in einer Schleife auf der CLI migrieren:

for id in 174 175 176; do qm migrate $id pmve4 --online --with-conntrack-state 1; done

Bin mir beim Parameternamen nicht 100% sicher, schau vorher kurz mit qm help migrate nach, ob der bei deiner Version so heißt. Welche Version läuft bei dir genau (pveversion -v)? Wenn das auf dem aktuellen Stand immer noch so ist, würd ich dafür einen Bug bzw. Feature-Request im Proxmox-Bugzilla aufmachen. Das sollte eigentlich einheitlich laufen.

 

[superwinni2]

Workaround via comandozeile wäre meine Alternative.

Der Fehler ist mir schon länger aufgefallen. Mit vielen Proxmox versionen. ist also nichts was früher mal funktioniert hat.

root@pmve2:~# pveversion -v
proxmox-ve: 9.2.0 (running kernel: 7.0.14-26-pve)
pve-manager: 9.2.24 (running version: 9.2.24/66bc407c6d90a67a)
proxmox-kernel-helper: 9.2.0
proxmox-kernel-7.0: 7.0.14-26
proxmox-kernel-7.0.14-26-pve-signed: 7.0.14-26
proxmox-kernel-7.0.14-24-pve-signed: 7.0.14-24
ceph-fuse: 19.2.6-pve4
corosync: 3.1.10-pve3
criu: 4.1.1-1
frr-pythontools: 10.6.1-1+pve3
ifupdown2: 3.3.0-1+pmx12
intel-microcode: 3.20251111.1~deb13u1
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-7
libproxmox-acme-perl: 1.7.2
libproxmox-backup-qemu0: 2.0.3
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.1.2
libpve-apiclient-perl: 3.4.3
libpve-cluster-api-perl: 9.1.7
libpve-cluster-perl: 9.1.7
libpve-common-perl: 9.2.6
libpve-guest-common-perl: 6.0.5
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.6.7
libpve-notify-perl: 9.1.7
libpve-rs-perl: 0.15.3
libpve-storage-perl: 9.1.13
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 7.0.0-2
lxcfs: 7.0.0-pve1
novnc-pve: 1.7.0-2
proxmox-backup-client: 4.2.8-1
proxmox-backup-file-restore: 4.2.8-1
proxmox-backup-restore-image: 1.0.0
proxmox-enterprise-support-keyring: 1.1
proxmox-firewall: 1.2.3
proxmox-kernel-helper: 9.2.0
proxmox-mail-forward: 1.0.3
proxmox-mini-journalreader: 1.7
proxmox-offline-mirror-helper: 0.7.4
proxmox-widget-toolkit: 5.2.10
pve-cluster: 9.1.7
pve-container: 6.1.15
pve-docs: 9.2.13
pve-edk2-firmware: 4.2026.08-1
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.6
pve-firmware: 3.18-8
pve-ha-manager: 5.2.5
pve-i18n: 3.10.0
pve-qemu-kvm: 11.0.3-4
pve-xtermjs: 6.0.0-3
qemu-server: 9.2.13
smartmontools: 7.5-pve2
spiceterm: 3.4.2
swtpm: 0.10.2+pve1
vncterm: 1.9.2
zfsutils-linux: 2.4.4-pve1

root@pmve4:~# pveversion -v
proxmox-ve: 9.2.0 (running kernel: 7.0.14-26-pve)
pve-manager: 9.2.24 (running version: 9.2.24/66bc407c6d90a67a)
proxmox-kernel-helper: 9.2.0
proxmox-kernel-7.0: 7.0.14-26
proxmox-kernel-7.0.14-26-pve-signed: 7.0.14-26
proxmox-kernel-7.0.14-24-pve-signed: 7.0.14-24
ceph-fuse: 19.2.6-pve4
corosync: 3.1.10-pve3
criu: 4.1.1-1
frr-pythontools: 10.6.1-1+pve3
ifupdown2: 3.3.0-1+pmx12
intel-microcode: 3.20251111.1~deb13u1
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-7
libproxmox-acme-perl: 1.7.2
libproxmox-backup-qemu0: 2.0.3
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.1.2
libpve-apiclient-perl: 3.4.3
libpve-cluster-api-perl: 9.1.7
libpve-cluster-perl: 9.1.7
libpve-common-perl: 9.2.6
libpve-guest-common-perl: 6.0.5
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.6.7
libpve-notify-perl: 9.1.7
libpve-rs-perl: 0.15.3
libpve-storage-perl: 9.1.13
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 7.0.0-2
lxcfs: 7.0.0-pve1
novnc-pve: 1.7.0-2
proxmox-backup-client: 4.2.8-1
proxmox-backup-file-restore: 4.2.8-1
proxmox-backup-restore-image: 1.0.0
proxmox-enterprise-support-keyring: 1.1
proxmox-firewall: 1.2.3
proxmox-kernel-helper: 9.2.0
proxmox-mail-forward: 1.0.3
proxmox-mini-journalreader: 1.7
proxmox-offline-mirror-helper: 0.7.4
proxmox-widget-toolkit: 5.2.10
pve-cluster: 9.1.7
pve-container: 6.1.15
pve-docs: 9.2.13
pve-edk2-firmware: 4.2026.08-1
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.6
pve-firmware: 3.18-8
pve-ha-manager: 5.2.5
pve-i18n: 3.10.0
pve-qemu-kvm: 11.0.3-4
pve-xtermjs: 6.0.0-3
qemu-server: 9.2.13
smartmontools: 7.5-pve2
spiceterm: 3.4.2
swtpm: 0.10.2+pve1
vncterm: 1.9.2
zfsutils-linux: 2.4.4-pve1