+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

[РЕШЕНО]Иногда живая миграция завершается сбоем из-за ошибки утверждения QEMU, Proxmox Виртуальная Среда

stuartthebruce

Guest

13.12.2025 23:36:00

Тестирование нового кластера PVE9 с высокоскоростными (2x400G LACP) сетевыми подключениями показало, что живая миграция больших виртуальных машин периодически завершается неудачей с ошибкой QEMU[949247]: kvm: ../util/bitmap.c:167: bitmap_set: Assertion `start >= 0 && nr >= 0' failed. Сначала предполагали, что проблема связана с сетевым сбоями PBS в последних ядрах, так как частота ошибки действительно зависит от версии ядра — не было успешных миграций с 6.14.0-{1,2}-pve, а с более старшими или новыми ядрами сбои происходили примерно в одном случае из нескольких. Однако, как указала @fiona в https://forum.proxmox.com/threads/s...o-pve-9-1-1-and-pbs-4-0-20.176444/post-823442, эта ошибка с Assertion в QEMU не должна вызываться проблемами с TCP receive buffer в ядре.

Вот дополнительная информация на примере неудачной миграции ВМ (1ТБ памяти/2ТБ локального хранилища) между хостами hov1 и hov2. Замечу, что при всех тестах сбои происходили только во время миграции 1ТБ памяти, а с миграцией 2ТБ локального хранилища проблем не было, так что считаю сеть стабильной.

Конфигурация ВМ:
root@hov1:~# qm config 102
allow-ksm: 0
balloon: 0
boot: order=scsi0;ide2;net0
cores: 96
cpu: host
hotplug: disk,network,usb,cpu
ide2: none,media=cdrom
memory: 1048576
meta: creation-qemu=10.0.2,ctime=1761354940
name: node2412.cluster.ldas.cit
net0: virtio=BC:24:11:D3:10:A8,bridge=vmbr0,queues=32
numa: 1
ostype: l26
rng0: source=/dev/urandom
scsi0: local-zfs:vm-102-disk-0,format=raw,iothread=1,size=2T
scsihw: virtio-scsi-single
smbios1: uuid=20721900-0449-43a2-aec7-41c44ce7a68d
sockets: 1
vcpus: 96
vmgenid: 6b1b9d99-097c-4b3f-a290-f7d79b89160e

Версии ПО на hov1:
root@hov1:~# pveversion -v
proxmox-ve: 9.1.0 (работает на ядре 6.17.11-2-test-pve)
pve-manager: 9.1.2 (версия: 9.1.2/9d436f37a0ac4172)
proxmox-kernel-helper: 9.0.4
proxmox-kernel-6.17.11-2-test-pve: 6.17.11-2
proxmox-kernel-6.17.11-1-test-pve: 6.17.11-1
proxmox-kernel-6.17.4-1-pve-signed: 6.17.4-1
proxmox-kernel-6.17: 6.17.4-1
proxmox-kernel-6.17.2-2-pve-signed: 6.17.2-2
proxmox-kernel-6.17.2-1-pve-signed: 6.17.2-1
proxmox-kernel-6.14: 6.14.11-4
proxmox-kernel-6.14.11-4-pve: 6.14.11-4
proxmox-kernel-6.14.8-2-pve-signed: 6.14.8-2
amd64-microcode: 3.20250311.1
ceph: 19.2.3-pve2
ceph-fuse: 19.2.3-pve2
corosync: 3.1.9-pve2
criu: 4.1.1-1
frr-pythontools: 10.4.1-1+pve1
ifupdown2: 3.3.0-1+pmx11
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libknet1: не установлен корректно
libproxmox-acme-perl: 1.7.0
libproxmox-backup-qemu0: 2.0.1
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.0.4
libpve-apiclient-perl: 3.4.2
libpve-cluster-api-perl: 9.0.7
libpve-cluster-perl: 9.0.7
libpve-common-perl: 9.1.0
libpve-guest-common-perl: 6.0.2
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.2.3
libpve-rs-perl: 0.11.3
libpve-storage-perl: 9.1.0
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 6.0.5-3
lxcfs: 6.0.4-pve1
novnc-pve: 1.6.0-3
proxmox-backup-client: 4.1.0-1
proxmox-backup-file-restore: 4.1.0-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.2.1
proxmox-kernel-helper: 9.0.4
proxmox-mail-forward: 1.0.2
proxmox-mini-journalreader: 1.6
proxmox-offline-mirror-helper: 0.7.3
proxmox-widget-toolkit: 5.1.2
pve-cluster: 9.0.7
pve-container: 6.0.18
pve-docs: 9.1.1
pve-edk2-firmware: 4.2025.05-2
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.4
pve-firmware: 3.17-2
pve-ha-manager: 5.0.8
pve-i18n: 3.6.5
pve-qemu-kvm: 10.1.2-4
pve-xtermjs: 5.5.0-3
qemu-server: 9.1.1
smartmontools: 7.4-pve1
spiceterm: 3.4.1
swtpm: 0.8.0+pve3
vncterm: 1.9.1
zfsutils-linux: 2.3.4-pve1

Версии ПО на hov2:
root@hov2:~# pveversion -v
proxmox-ve: 9.1.0 (работает на ядре 6.17.11-2-test-pve)
pve-manager: 9.1.2 (версия: 9.1.2/9d436f37a0ac4172)
proxmox-kernel-helper: 9.0.4
proxmox-kernel-6.17.11-2-test-pve: 6.17.11-2
proxmox-kernel-6.17.11-1-test-pve: 6.17.11-1
proxmox-kernel-6.17.4-1-pve-signed: 6.17.4-1
proxmox-kernel-6.17: 6.17.4-1
proxmox-kernel-6.17.2-2-pve-signed: 6.17.2-2
proxmox-kernel-6.17.2-1-pve-signed: 6.17.2-1
proxmox-kernel-6.14.11-4-pve-signed: 6.14.11-4
proxmox-kernel-6.14: 6.14.11-4
proxmox-kernel-6.14.8-2-pve-signed: 6.14.8-2
amd64-microcode: 3.20250311.1
ceph: 19.2.3-pve2
ceph-fuse: 19.2.3-pve2
corosync: 3.1.9-pve2
criu: 4.1.1-1
frr-pythontools: 10.4.1-1+pve1
ifupdown2: 3.3.0-1+pmx11
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libknet1: не установлен корректно
libproxmox-acme-perl: 1.7.0
libproxmox-backup-qemu0: 2.0.1
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.0.4
libpve-apiclient-perl: 3.4.2
libpve-cluster-api-perl: 9.0.7
libpve-cluster-perl: 9.0.7
libpve-common-perl: 9.1.0
libpve-guest-common-perl: 6.0.2
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.2.3
libpve-rs-perl: 0.11.3
libpve-storage-perl: 9.1.0
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 6.0.5-3
lxcfs: 6.0.4-pve1
novnc-pve: 1.6.0-3
proxmox-backup-client: 4.1.0-1
proxmox-backup-file-restore: 4.1.0-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.2.1
proxmox-kernel-helper: 9.0.4
proxmox-mail-forward: 1.0.2
proxmox-mini-journalreader: 1.6
proxmox-offline-mirror-helper: 0.7.3
proxmox-widget-toolkit: 5.1.2
pve-cluster: 9.0.7
pve-container: 6.0.18
pve-docs: 9.1.1
pve-edk2-firmware: 4.2025.05-2
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.4
pve-firmware: 3.17-2
pve-ha-manager: 5.0.8
pve-i18n: 3.6.5
pve-qemu-kvm: 10.1.2-4
pve-xtermjs: 5.5.0-3
qemu-server: 9.1.1
smartmontools: 7.4-pve1
spiceterm: 3.4.1
swtpm: 0.8.0+pve3
vncterm: 1.9.1
zfsutils-linux: 2.3.4-pve1

К логу задачи по неудачной миграции и журналу journalctl приложены логи с обоих узлов за время сбоя.

stuartthebruce Guest	#2 0 27.02.2026 01:47:00 Похоже, патч из внешнего репозитория был применён 17 февраля. Есть сборка для тестирования?

fiona

Guest

02.03.2026 10:51:00

Вы можете использовать кнопку «Редактировать тему» в правом верхнем углу и выбрать префикс [РЕШЕНО]. Если не получится, дайте знать, и я сделаю это сам (если я правильно помню, такое бывает, когда тема слишком старая и обычные пользователи уже не могут её редактировать).

stuartthebruce Guest	#4 0 02.03.2026 16:11:00 Я не вижу кнопку «Редактировать ветку»,

fiona Guest	#5 0 03.03.2026 10:12:00 Хорошо, я сейчас выбрал префикс.

pchecinski

Guest

05.02.2026 11:27:00

Привет, есть ли возможность подтолкнуть кого-нибудь, чтобы исправили это хотя бы в тестовой ветке? Уже около двух месяцев нельзя использовать live migrate, и всё это начало довольно сильно раздражать, приходится искать обходные пути.

fiona Guest	#7 0 05.02.2026 13:09:00 Привет, я только что отправил патч.

stuartthebruce

Guest

28.12.2025 00:27:00

Я выявил эту ошибку срабатывания утверждения в QEMU при живой миграции Linux-виртуальных машин, которые динамически создают файловые системы на локальном zpool гипервизора с LVM во время миграции. Это известно как ограничение QEMU? Обратите внимание, если я переношу LVM на общее хранилище ceph, проблем нет; кроме того, я не видел сбоев у Linux-VM, которые не создают и не удаляют логические тома на локальном хранилище гипервизора во время миграции.

fiona

Guest

05.01.2026 16:18:00

Привет, этот баг пока не известен, и я не видел, чтобы кто-то ещё о нём жаловался. Чтобы убедиться, что я правильно понял вашу конфигурацию: виртуальный диск для ВМ хранится на ZFS/Ceph-хранилище на хосте, а внутри ВМ используется LVM, который часто создаёт и удаляет логические тома? Можешь также поделиться частью из /etc/pve/storage.cfg, относящейся к ZFS-хранилищу? Сбой всегда происходит во время миграции состояния ВМ (RAM)? То есть после того, как первичное зеркалирование диска уже завершилось и все задания 'mirror' готовы? Есть ли у вас тестовая ВМ для воспроизведения проблемы (например, клон существующей ВМ)? Сообщение об ошибке, к сожалению, ничего толком не говорит. Можно получить полный бэктрейс через GDB. Установи отладчик и отладочные символы командой apt install pve-qemu-kvm-dbgsym gdb и подключи GDB перед миграцией с помощью команды: gdb --ex 'set pagination off' --ex 'handle SIGUSR1 noprint nostop' --ex 'handle SIGPIPE noprint nostop' --ex 'c' -p $(cat /run/qemu-server/<ID>.pid), где <ID> — это ID ВМ. Если произойдёт сбой, ты увидишь ошибку в интерфейсе GDB и сможешь там выполнить t a a bt для получения бэктрейса. И для уверенности (раз ты пока единственный, кто сообщил о проблеме) не мог бы ты запустить memtest во время следующего окна технического обслуживания? ПРИМЕЧАНИЕ: забыл добавить команду GDB для получения бэктрейса.

stuartthebruce

Guest

#10

05.01.2026 17:12:00

Хорошо знать. Ты случайно не в курсе, поддерживает ли upstream QEMU динамическое создание/удаление LVM во время live migration? Образ диска ВМ/гостя хранится либо на HV как локальный ZFS zvol (там и проявляется проблема), либо на Ceph RBD (проблема не возникает); и проблема с ZFS появляется только если ВМ/гость активно создаёт или удаляет LVM во время live migration.
Код:
root@hov1:~# cat /etc/pve/storage.cfg
dir: local
path /var/lib/vz
content iso,vztmpl,backup

zfspool: local-zfs
pool rpool/data
content rootdir,images
sparse 1

pbs: pbs-hov
datastore hov
server pbs.ldas.cit
content backup
fingerprint e2:9b:2b:27:cc:2d:63:41:20:c8:03:0e:9b:48:ec:6d:15:b9:d8:fd:e2:7d:6e:a0:a5:de:c5:25:e9:af:2b:29
prune-backups keep-all=1
username root@pam

zfspool: optane-zfs
pool optane-zfs
content images,rootdir
mountpoint /optane-zfs
sparse 0

rbd: ceph-rbd
content images,rootdir
krbd 1
pool ceph-rbd

rbd: optane-rbd
content images,rootdir
krbd 1
pool optane-rbd

zfspool: micron-zfs
pool micron-zfs
content rootdir,images
mountpoint /micron-zfs
nodes hov4,hov1,hov5,hov3,hov2

Да. Да. Да. У меня это воспроизводится по желанию на любом из 5 разных ВМ, где до сих пор наблюдалась эта проблема. И я готов перенастроить эти ВМ, изменив BIOS/Machine/SCSI Controller/... чтобы дальше сузить проблему, если понадобится. Попробую этим заняться позже сегодня.
Я воспроизвёл эту проблему на 5 из 5 новых серверов корпоративного класса, у всех с ECC и без каких-либо сообщений о корректировках одиночных битовых ошибок при интенсивном стресс-тестировании памяти с помощью `/usr/bin/stress`.
Спасибо, что нашли время разобраться в этом.

stuartthebruce

Guest

#11

06.01.2026 00:24:00

Первая попытка под gdb воспроизвела сбой с таким выводом задачи и приложенным бэктрейсом из gdb

Код:
2026-01-05 13:52:02 миграция активна, передано 163.9 ГиБ из 1.0 ТиБ состояния ВМ, 1.8 ГиБ/с
2026-01-05 13:52:03 миграция активна, передано 165.7 ГиБ из 1.0 ТиБ состояния ВМ, 1.8 ГиБ/с
2026-01-05 13:52:04 миграция активна, передано 167.4 ГиБ из 1.0 ТиБ состояния ВМ, 1.7 ГиБ/с
query migrate не удался: VM 104 qmp команда 'query-migrate' не выполнена — истекло время ожидания

2026-01-05 14:52:05 query migrate не удался: VM 104 qmp команда 'query-migrate' не выполнена — истекло время ожидания

fiona

Guest

#12

12.01.2026 14:23:00

Спасибо! Трассировка GDB показывает, что это случилось во время операции записи нулей. Мне удалось воспроизвести проблему, отправляя много мелких запросов на удаление с помощью кода:
for i in {0..1000000}
do off=$(expr 512 '*' $i); blkdiscard -z -o $off -l 4096 /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1
done внутри виртуальной машины во время миграции. Я займусь этим.

fiona Guest	#13 0 12.01.2026 16:43:00 Патч отправлен в исходный репозиторий на проверку: https://lore.kernel.org/qemu-devel/20260112152544.261923-1-f.ebner@proxmox.com/T/

stuartthebruce Guest	#14 0 15.01.2026 00:53:00 Есть ли исправленная версия в тестовом репозитории или планируется дождаться обновления от разработчиков?

fiona Guest	#15 0 15.01.2026 10:54:00 Я также отправил патч вниз по цепочке, но его всё равно нужно будет проверить, прежде чем применить: https://lore.proxmox.com/pve-devel/20260112155940.298273-1-f.ebner@proxmox.com/T/

Neobin Guest	#16 0 27.02.2026 06:41:00 Обе исправления включены в pve-qemu-kvm версии 10.1.2-7: [1], которая уже доступна в pve-no-subscription. (Про pve-enterprise не в курсе.) [1] https://git.proxmox.com/?p=pve-qemu.git;a=commitdiff;h=a7c7a6b2b1aa75360d914b252dfcb05506ce590b

pchecinski Guest	#17 0 27.02.2026 11:00:00 Могу подтвердить, что проблема больше не возникает после перезагрузки исходных виртуальных машин с новой версией pve-qemu-kvm — живая миграция работает отлично, без сбоев.

stuartthebruce Guest	#18 0 27.02.2026 18:57:00 Теперь это работает и у меня. Большое спасибо!

stuartthebruce Guest	#19 0 27.02.2026 19:00:00 Есть ли какой-то способ отметить этот вопрос как решённый или закрытый от имени создателя темы?

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры