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

Live migrate не может возобновить работу., Proxmox Виртуальная Среда

effeeue05

Guest

24.06.2024 18:39:00

У большинства наших гостей происходит сбой при возобновлении после live-миграции с одного узла на другой. Похоже, что это происходит со всеми гостями; новый гость изначально не сталкивается с этой проблемой, но после неизвестного периода времени проблема проявляется. Ошибка, которую мы видим, выглядит так: "tunnel replied 'ERR: resume failed - VM XXX qmp command 'query-status' failed - got timeout' to command 'resume XXX'". Эта проблема наблюдалась в Proxmox 7 и сохраняется после обновления до Proxmox 8. Я могу вручную возобновить гостя после возникновения ошибки. Кажется, что процесс пытается возобновить гостя до того, как он готов к возобновлению на новом узле.

Код:
proxmox-ve: 8.2.0 (running kernel: 6.8.4-3-pve)
pve-manager: 8.2.2 (running version: 8.2.2/9355359cd7afbae4)
proxmox-kernel-helper: 8.1.0
proxmox-kernel-6.8: 6.8.4-3
proxmox-kernel-6.8.4-3-pve-signed: 6.8.4-3
proxmox-kernel-6.8.4-2-pve-signed: 6.8.4-2
ceph-fuse: 17.2.7-pve3
corosync: 3.1.7-pve3
criu: 3.17.1-2
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx8
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-4
libknet1: 1.28-pve1
libproxmox-acme-perl: 1.5.1
libproxmox-backup-qemu0: 1.4.1
libproxmox-rs-perl: 0.3.3
libpve-access-control: 8.1.4
libpve-apiclient-perl: 1.3.2
libpve-cluster-api-perl: 1.0.6
libpve-cluster-perl: 1.0.6
libpve-common-perl: 1.2.1
libpve-guest-common-perl: 1.1.1
libpve-http-server-perl: 1.1.0
libpve-network-perl: 0.9.8
libpve-rs-perl: 0.8.8
libpve-storage-perl: 1.2.1
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 6.0.0-1
lxcfs: 6.0.0-pve2
novnc-pve: 1.4.0-3
proxmox-backup-client: 3.2.2-1
proxmox-backup-file-restore: 3.2.2-1
proxmox-kernel-helper: 8.1.0
proxmox-mail-forward: 0.2.3
proxmox-mini-journalreader: 1.4.0
proxmox-offline-mirror-helper: 0.6.6
proxmox-widget-toolkit: 4.2.3
pve-cluster: 1.0.6
pve-container: 1.1.10
pve-docs: 1.2.2
pve-edk2-firmware: 4.2023.08-4
pve-esxi-import-tools: 0.7.0
pve-firewall: 1.0.7
pve-firmware: 1.11-1
pve-ha-manager: 1.0.4
pve-i18n: 1.2.2
pve-qemu-kvm: 1.1.5-6
pve-xtermjs: 1.3.0-3
qemu-server: 1.2.1
smartmontools: 1.7.3-pve1
spiceterm: 1.3.0
swtpm: 1.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 1.2.3-pve2

Любая помощь в выяснении этой проблемы была бы очень кстати.

effeeue05

Guest

09.07.2024 20:09:00

Если бы не было дисков, то и "возобновлять" было бы нечего. Однако, я перенес тестовый VM на локальные диски и выполнил пару миграций, и они мигрируют/возобновляются отлично. Как можно отладить, почему тома rbd и/или связанные с ними снапшоты вызывают эту проблему?

fiona

Guest

10.07.2024 10:04:00

Да, это было бы. Виртуальная машина на целевом хосте всегда запускается в режиме предварительного запуска, получает данные миграции с состоянием ВМ и ОЗУ и нуждается в последующем возобновлении. Пожалуйста, предоставь файл /etc/pve/storage.cfg. Судя по отсутствию пакета ceph в выводе pveversion, я предполагаю, что это внешний кластер, а не управляемый Proxmox VE? Что показывает ceph -s на Ceph-ноде? Какую версию Ceph вы используете?

effeeue05

Guest

10.07.2024 18:58:00

Кластер:
id: <ommitted>
health: HEALTH_OK

сервисы:
mon: 5 демонов, узел кворума node12,node13,node15,node2,node8 (возраст 9d)
mgr: node2(активен, с 8w), standbys: node12, node8, node13, node15
mds: 1/1 демона работает, 1 hot standby
osd: 432 osd: 432 up (с 8w), 432 in (с 3M)
rbd-mirror: 1 демон активен (1 хост)

данные:
volumes: 1/1 здоровых
pools: 6 пулов, 8784 pgs
objects: 79.79M объектов, 245 TiB
usage: 739 TiB использовано, 770 TiB / 1.5 PiB доступно
pgs: 8784 активных+чистых

io:
client: 300 MiB/s rd, 376 MiB/s wr, 9.02k op/s rd, 10.48k op/s wr

Код: cat /etc/pve/storage.cfg
dir: local
path /var/lib/vz
content backup,vztmpl,iso

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

rbd: rbd
content rootdir,images
krbd 1
monhost x.x.x.71:6789;x.x.x.77:6789;x.x.x.81:6789;x.x.x.82:6789;x.x.x.84:6789
pool rbd
username <omitted>

cifs: imports
path /mnt/pve/imports
server x.x.x.245
share proxmox-imports
content iso
prune-backups keep-all=1
username <omitted>

cifs: backups
path /mnt/pve/backups
server x.x.x.245
share proxmox-backups
content backup,images
prune-backups keep-all=1
username <omitted>

Всё верно; это внешний кластер Ceph. Приведенная выше информация – это то, что вы запросили.

fiona

Guest

11.07.2024 13:09:00

Кажется, это связано с большим количеством OSD (которые и раньше вызывали разные проблемы). Нужно понять, что именно делает экземпляр QEMU на целевом узле между завершением миграции и возможностью отреагировать на команду query-status. По быстрому взгляду, он очищает внутреннее состояние миграции и активирует блочные диски, но это должно быть очень быстро. В случае образов librbd он также инвалидирует кэш. Однако, вы используете krbd 1, поэтому образы подключаются как необработанные блочные устройства, а не через librbd.

EDIT: Есть обратный вызов для инвалидации кэша как для необработанных блочных устройств, так и для образов librd (т.е. при использовании krbd 0). Все равно, проверьте, меняет ли отключение krbd поведение?

Можно также попробовать отредактировать функцию vm_resume в /usr/share/perl5/PVE/QemuServer.pm на целевом узле миграции, а именно увеличить тайм-аут для команды query-status примерно так:

Code: sub vm_resume {
my ($vmid, $skiplock, $nocheck) = @_;

PVE::QemuConfig->lock_config($vmid, sub {
my $res = mon_cmd($vmid, 'query-status'); Code: sub vm_resume {
my ($vmid, $skiplock, $nocheck) = @_;

PVE::QemuConfig->lock_config($vmid, sub {
my $res = mon_cmd($vmid, 'query-status', timeout => 30);

После этого нужно перезагрузить systemctl reload-or-restart pvedaemon.service pveproxy.service, чтобы API-обработчики получили изменения.

effeeue05 Guest	#6 0 12.07.2024 14:51:00 Если я выключу krbd, это вступит в силу сразу или только после миграции? Есть ли способ узнать, что соединение использует librbd вместо krbd? Я тоже попробую изменить таймаут и потом отпишусь.

Читают тему

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