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

RSS

Виртуальная машина Ubuntu не запускается, когда клонируется на LVM-хранилище общего доступа по протоколу iSCSI, а на локальном хранилище все нормально., Proxmox Виртуальная Среда

lost_avocado

Guest

08.02.2024 16:49:00

Привет! Возникли проблемы при развертывании VM из шаблона на LVM-хранилище общего доступа (iSCSI). Уверен, что все работало нормально пару недель назад. Когда клонирую тот же шаблон на локальное хранилище, проблем нет. Это 4-узловая кластеризация, созданная как POC и на данный момент с no-sub лицензией. Надеюсь, это можно будет исправить, но это немного затормозило процесс. Другие VM на том же хранилище работают нормально, запускаются и мигрируют без проблем. Попробовал несколько действий, вроде изменения дисков с iSCSI на IDE, virtio, а также изменил параметры машины. Пока ничего не помогает. У кого-нибудь сталкивались с подобными проблемами в последнее время? Буду очень благодарен за любые советы.

VM запускается, потом останавливается и выдает оболочку... Прекратил ждать устройства корневой файловой системы.

Общие проблемы:

* Boot args (cat /proc/cmdline)
* Проверить rootdelay= (достаточно ли долго система ждала?)
* Отсутствующие модули (cat /proc/modules; ls /dev)

ВНИМАНИЕ! LABEL=cloudimg-rootfs не существует. Переход в оболочку!

BusyBox v1.30.1 (Ubuntu 1:1.30.1-7ubuntu3) встроенная оболочка (ash)

Конфигурация VM:

:~# qm config 6001

agent: 1

boot: order=ide2;scsi0;ide0;net0

cipassword: **********

ciuser: admin

cores: 2

cpu: kvm64

ide0: SAS-1:vm-6001-cloudinit,media=cdrom,size=4M

ide2: none,media=cdrom

ipconfig0: ip=dhcp

memory: 2048

meta: creation-qemu=8.1.5,ctime=1707403862

name: 6001-iscsi-slettes

nameserver: 1.1.1.1

net0: virtio=BC:24:11:78:C6:4E,bridge=vmbr0,firewall=1

numa: 0

ostype: l26

scsi0: SAS-1:vm-6001-disk-0,size=10G

scsihw: virtio-scsi-pci

searchdomain:

serial0: socket

smbios1: uuid=56fc8a0e-a43c-47b1-b172-a3ee98e97f0d

sockets: 1

vga: serial0

vmgenid: 9c4ffbb0-78ae-4311-ac48-75da6739919d

pveversion -v

proxmox-ve: 8.1.0 (running kernel: 6.5.11-8-pve)

pve-manager: 8.1.4 (running version: 8.1.4/ec5affc9e41f1d79)

proxmox-kernel-helper: 8.1.0

pve-kernel-6.2: 8.0.5

proxmox-kernel-6.5: 6.5.11-8

proxmox-kernel-6.5.11-8-pve-signed: 6.5.11-8

proxmox-kernel-6.5.11-7-pve-signed: 6.5.11-7

proxmox-kernel-6.2.16-20-pve: 6.2.16-20

proxmox-kernel-6.2: 6.2.16-20

pve-kernel-6.2.16-3-pve: 6.2.16-3

ceph-fuse: 17.2.7-pve2

corosync: 3.1.7-pve3

criu: 3.17.1-2

dnsmasq: 2.89-1

frr-pythontools: 8.5.2-1+pve1

glusterfs-client: 10.3-5

ifupdown2: 3.2.0-1+pmx8

ksm-control-daemon: 1.4-1

libjs-extjs: 7.0.0-4

libknet1: 1.28-pve1

libpdxmox-acme-perl: 1.5.0

libpdxmox-backup-qemu0: 1.4.1

libpdxmox-rs-perl: 0.3.3

libpve-access-control: 8.0.7

libpve-apiclient-perl: 3.3.1

libpve-common-perl: 8.1.0

libpve-guest-common-perl: 5.0.6

libpve-http-server-perl: 5.0.5

libpve-network-perl: 0.9.5

libpve-rs-perl: 0.8.8

libpve-storage-perl: 8.0.5

libspice-server1: 0.15.1-1

lvm2: 2.03.16-2

lxc-pve: 5.0.2-4

lxcfs: 5.0.3-pve4

novnc-pve: 1.4.0-3

proxmox-backup-client: 3.1.4-1

proxmox-backup-file-restore: 3.1.4-1

proxmox-kernel-helper: 8.1.0

proxmox-mail-forward: 0.2.3

proxmox-mini-journalreader: 1.4.0

proxmox-widget-toolkit: 4.1.3

pve-cluster: 8.0.5

pve-container: 5.0.8

pve-docs: 8.1.3

pve-edk2-firmware: 4.2023.08-3

pve-firewall: 5.0.3

pve-firmware: 3.9-1

pve-ha-manager: 4.0.3

pve-i18n: 3.2.0

pve-qemu-kvm: 8.1.5-2

pve-xtermjs: 5.3.0-3

qemu-server: 8.0.10

smartmontools: 7.3-pve1

spiceterm: 3.3.0

swtpm: 0.8.0+pve1

vncterm: 1.8.0

zfsutils-linux: 2.2.2-pve1

lost_avocado

Guest

05.03.2024 10:50:00

Когда сужаем область поиска, NFS и Ceph работают нормально. Клонирование шаблона Ubuntu из хранилища NFS в то же хранилище работает отлично... и последующее live-клонирование этой ВМ в хранилище iSCSI тоже работает нормально. Но когда пытаюсь клонировать тот же шаблон напрямую в хранилище iSCSI, все падает. Прекратил ждать, когда найдется устройство корневой файловой системы. Типичные проблемы:
- Boot args (cat /proc/cmdline)
- Проверить rootdelay= (система достаточно долго ждала?)
- Отсутствующие модули (cat /proc/modules; ls /dev)
ВНИМАНИЕ! LABEL=cloudimg-rootfs не существует. Переход в оболочку! Кажется, процесс клонирования как-то испортил диск, а хранилище iSCSI в порядке. Есть ли способ отладить этот процесс? В чем разница между клонированием из шаблона и клонированием из работающей ВМ? Буду очень признателен за любые советы.

lost_avocado

Guest

06.03.2024 19:18:00

Когда делаем qemu-img compare, получаем 'Content mismatch at offset 4096!' между оригинальным шаблонным диском и новым диском виртуальной машины. Вижу эту ошибку как при qm clone, так и при qm importdisk на iscsi datastore. Единственный способ поднять виртуальную машину на iscsi datastore — создать её сначала на ceph или nfs, а потом использовать добрый старый cp для замены импортированного проблемного диска. Похоже, дело в чём-то связанном с qemu-img.

lost_avocado

Guest

07.03.2024 10:06:00

Процедура воспроизведения. Оригинальный дисковый файл: /dev/SAS-1/vm-150-disk-0.
qm clone 150 4202 --full --storage SAN-A --target pve4 --name Ubuntu-iscsi-1
qm clone 150 4201 --full --storage TRUENAS --target pve4 --name Ubuntu-NFS-1
nfs vm disk: /mnt/pve/TRUENAS/images/4201/vm-4201-disk-0.raw
qemu-img compare /dev/SAS-1/vm-150-disk-0 /mnt/pve/TRUENAS/images/4201/vm-4201-disk-0.raw
Изображения идентичны.
iscsi vm disk: /dev/SAS-1/vm-4202-disk-0
qemu-img compare /dev/SAS-1/vm-150-disk-0 /dev/SAS-1/vm-4202-disk-0
Несовпадение содержимого с offset 4096!
dd if=/mnt/pve/TRUENAS/images/4201/vm-4201-disk-0.raw of=/dev/SAS-1/vm-4202-disk-0 status=progress
2358632960 bytes (2.4 GB, 2.2 GiB) copied, 296 s, 8.0 MB/s
4612096+0 records in 4612096+0 records out
2361393152 bytes (2.4 GB, 2.2 GiB) copied, 296.656 s, 8.0 MB/s
qemu-img compare /dev/SAS-1/vm-150-disk-0 /dev/SAS-1/vm-4202-disk-0
Изображения идентичны. (скорость снижена до 100Mb, на всякий случай, чтобы избежать ошибок)

Возможно ли добавить какие-нибудь параметры проверки при qm clone или использовать другую версию qemu?
qemu-system-x86_64 --version
QEMU emulator version 8.1.5 (pve-qemu-kvm_8.1.5-3)
Copyright © 2003-2023 Fabrice Bellard and the QEMU Project developers

lost_avocado

Guest

11.03.2024 10:24:00

Может быть, это связано с размером физического и логического сектора? У NFS физический и логический размер сектора 512 против 512/4096 байт (512e) у iSCSI. Не могу найти опцию для установки qemu sectorsize где-либо, только старая ветка багов. https://bugzilla.proxmox.com/show_bug.cgi?id=3282 NFS: fdisk -l /mnt/pve/TRUENAS/images/4202/vm-4202-disk-0.raw Диск /mnt/pve/TRUENAS/images/4202/vm-4202-disk-0.raw: 2.2 GiB, 2361393152 bytes, 4612096 sectors Единицы измерения: сектора по 1 * 512 = 512 байт Размер сектора (логический/физический): 512 байт / 512 байт Размер I/O (минимальный/оптимальный): 512 байт / 512 байт Тип дисковой метки: gpt iSCSI: fdisk -l /dev/mapper/SAS--1-vm--4201--disk--0 Диск /dev/mapper/SAS--1-vm--4201--disk--0: 2.2 GiB, 2361393152 bytes, 4612096 sectors Единицы измерения: сектора по 1 * 512 = 512 байт Размер сектора (логический/физический): 512 байт / 4096 байт Размер I/O (минимальный/оптимальный): 4096 байт / 1048576 байт Тип дисковой метки: gpt

LnxBil Guest	#6 0 12.03.2024 08:40:00 Можешь, пожалуйста, выяснить, в чём же конкретно несоответствие?

fabian

Guest

12.03.2024 08:41:00

1. Не могли бы вы также предоставить ваш storage.cfg?
2. Что за iscsi target?
3. Не могли бы вы также выложить ваш lvm.conf, пожалуйста?
4. Не могли бы вы также выложить лог задачи клонирования и вывод journalctl, охватывающий период времени, когда выполнялось клонирование? Спасибо!

lost_avocado

Guest

12.03.2024 09:27:00

Пришлось все делать заново, так как предыдущие ВМ были удалены, но все равно при клонировании на iSCSI datastore появляется повреждение диска, но теперь другое смещение: "Content mismatch at offset 117497856!". Это, кажется, не мешает загрузке Ubuntu, но я уверен, что Windows ВМ загрузиться не сможет.

1. storage.cfg
```
iscsi: Lenovo4200-1
portal 10.1.x.x
target iqn.2002-09.com.lenovo:01.array.00c0ff3b2e24
content none

iscsi: Lenovo4200-2
portal 10.2.x.x
target iqn.2002-09.com.lenovo:01.array.00c0ff3b2e24
content none
```

lvm: SAN-A
vgname SAS-1
content images
shared 1 2. Целевой iSCSI - конфигурация Lenovo DS4200 с мультипутями.

3. lvm.conf (насколько я вижу, все закомментировано, за исключением последних строк в этом файле)
```
devices {
# added by pve-manager to avoid scanning ZFS zvols and Ceph rbds
# global_filter=["r|/dev/zd.*|"]
global_filter=["r|/dev/zd.*|","r|/dev/rbd.*|"]
}
```

4. Журнал и лог задачи клонирования
```
root@pve4:~# journalctl --since 09:04
Mar 12 09:04:02 pve4 pmxcfs[2649]: [status] notice: received log
Mar 12 09:04:02 pve4 pmxcfs[2649]: [status] notice: received log
Mar 12 09:04:02 pve4 pmxcfs[2649]: [status] notice: received log
Mar 12 09:04:03 pve4 qm[2119485]: <root@pam> starting task UPID:pve4:002057D6:0374CF95:65F00C73:qmclone:105:root@pam:
Mar 12 09:04:06 pve4 kernel: nfs: server x.x.x.x not responding, timed out
Mar 12 09:04:07 pve4 qm[2119485]: <root@pam> end task UPID:pve4:002057D6:0374CF95:65F00C73:qmclone:105:root@pam: OK
Mar 12 09:04:12 pve4 kernel: sd 6:0:0:0: alua: supports implicit TPGS
Mar 12 09:04:12 pve4 kernel: sd 6:0:0:0: alua: device naa.600c0ff0003b1e68e23f5b6501000000 port group 0 rel port 1
Mar 12 09:04:12 pve4 kernel: sd 7:0:0:0: alua: supports implicit TPGS
Mar 12 09:04:12 pve4 kernel: sd 7:0:0:0: alua: device naa.600c0ff0003b1e68e23f5b6501000000 port group 1 rel port 7
Mar 12 09:04:12 pve4 kernel: sd 8:0:0:0: alua: supports implicit TPGS
Mar 12 09:04:12 pve4 kernel: sd 8:0:0:0: alua: device naa.600c0ff0003b1e68e23f5b6501000000 port group 0 rel port 3
Mar 12 09:04:12 pve4 kernel: sd 9:0:0:0: alua: supports implicit TPGS
Mar 12 09:04:12 pve4 kernel: sd 9:0:0:0: alua: device naa.600c0ff0003b1e68e23f5b6501000000 port group 1 rel port 5
```

Создание полного клона диска ide0 (TRUENAS:105/vm-105-cloudinit.raw)
Логический том "vm-4201-cloudinit" создан.
Создание полного клона диска scsi0 (TRUENAS:105/base-105-disk-0.raw)
Стирание сигнатуры GPT на /dev/SAS-1/vm-4201-disk-0.
Стирание сигнатуры GPT на /dev/SAS-1/vm-4201-disk-0.
Стирание сигнатуры PMBR на /dev/SAS-1/vm-4201-disk-0.
Логический том "vm-4201-disk-0" создан.
Перенесено 0.0 Б из 2.2 GiB (0.00%)
Перенесено 24.8 MiB из 2.2 GiB (1.10%)
.....
Перенесено 2.2 GiB из 2.2 GiB (100.00%)
Перенесено 2.2 GiB из 2.2 GiB (100.00%)
ЗАДАЧА ОКОНЧЕНА

fabian

Guest

12.03.2024 09:59:00

Слушай, а что насчет lvmconfig --typeconfig full devices/issue_discards? Мог бы ты попробовать сделать тестовое клонирование ВМ с очень маленьким диском и сравнить LV источника и клона? А потом, может, повторишь этот эксперимент, но сначала полностью запишешь объем данных на исходном томе перед клонированием? Мне кажется, что проблема в твоем хранилище (боксе), он как-то странно себя ведет, возможно, с пустотами или дискардами.

lost_avocado

Guest

#10

12.03.2024 10:17:00

Спасибо за ответ, LnxBil. В последнем клоне расхождение было на другом смещении. Если сделать дамп в шестнадцатеричном формате для этого смещения, то получится вот такой результат. Если это вообще имеет смысл, но это уж слишком для меня. Смещение 117497856: 0700e000: ffff ffff ffff ffff ffff ffff ffff ffff ................. Спасибо, что посмотрел в этом, Fabian. Попробуем эти тесты и посмотрим, найдём ли что-нибудь. Отпишусь позже.

LnxBil

Guest

#11

12.03.2024 13:03:00

Вопросы Фабиана и мои идут в одном направлении. Хотелось бы узнать данные о несовпадениях на обоих дисках. Вывод, который вы предоставили, "все единицы". Информация о другом хранилище тоже была бы не помешала.

lost_avocado

Guest

#12

12.03.2024 14:05:00

Спасибо за ответ, вот ещё одна попытка, смещение другое, как вы видите. Несоответствие содержимого со смещением 114294784! Код: xxd -s 114294784 -l 16 /mnt/pve/TRUENAS/images/105/base-105-disk-0.raw
06d00000: 0000 0000 0000 0000 0000 0000 0000 0000 ................

xxd -s 114294784 -l 16 /dev/mapper/SAS--1-vm--4205--disk--0
06d00000: 0a11 0603 0000 0001 2000 0000 0000 0000 ........ ....... Диск Truenas по NFS и шаблон.

LnxBil Guest	#13 0 12.03.2024 14:15:00 Это подтверждает аргумент Фабиана о том, что есть проблема с правильной очисткой пространства.

lost_avocado

Guest

#14

12.03.2024 14:36:00

Если я использую dd для копирования одного и того же дискового образа на новый vm, то нет расхождений в содержимом, это всегда согласованно и нормально, каждый раз, когда я это делал. Исходя из этого, я предположил, что дело может быть в процессе клонирования, разве это имеет смысл?

Код:
dd if=/mnt/pve/TRUENAS/images/105/base-105-disk-0.raw of=/dev/mapper/SAS--1-vm--4201--disk--0

4612096+0 records in
4612096+0 records out
2361393152 bytes (2.4 GB, 2.2 GiB) copied, 310.285 s, 7.6 MB/s

root@pve4:~# qemu-img compare /mnt/pve/TRUENAS/images/105/base-105-disk-0.raw /dev/mapper/SAS--1-vm--4201--disk--0

Images are identical.

bbgeek17

Guest

#15

12.03.2024 15:11:00

Учитывая, что сбой, похоже, связан с iSCSI, попробуйте включить iSCSI Digest как для заголовков, так и для данных (если ваша система хранения это поддерживает). Другой вариант — найти минимальный размер образа, который вызывает проблему, и получить сетевой трассировочный файл с источника/клиента и клиента/назначения. По крайней мере, вы сможете указать, кто является источником "неправильных" данных. Blockbridge: ультранизкая задержка, совместно используемое хранилище на базе NVME для Proxmox - https://www.blockbridge.com/proxmox

LnxBil Guest	#16 0 12.03.2024 15:58:00 Я все еще думаю, что это проблема в LVM (как уже заметил @fabian), и, скорее всего, данные нулями не перезатрутся, а просто будут проигнорированы. Может, какая-то "оптимизация"?

bbgeek17

Guest

#17

12.03.2024 16:06:00

Возможно. Или на уровне хранилища, где можно оптимизировать и нули (мы это делаем). Возможно, конкретное это хранилище делает это не совсем правильно. Чтобы исключить PVE из уравнения, можно создать LVM-раздел нужного размера и скопировать сырой образ на него с помощью dd. Сравнивает ли данные при этом корректно? Другой способ - пропустить LVM и скопировать образ напрямую на LUN с помощью dd - сравниваются ли данные (до размера образа) корректно? Можно также использовать "fio" с записью и проверкой, например, с хорошо известным шаблоном, включающим нули. @LnxBil, прочитав также сообщение @fabian, думаю, он указывает на бэкэнд-хранилище, а не на уровень LVM. Но я могу и ошибаться. Кстати, проверив ещё немного, выяснил - LVM никакой оптимизации данных не делает, так что это вряд ли виновато. Blockbridge: Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

fabian

Guest

#18

13.03.2024 10:13:00

Да, подозреваю, что накопитель делает какую-то "неправильную" оптимизацию в отношении дыр или сбросов. Мы сталкивались с подобным раньше с некоторыми проприетарными хранилищами. Простой dd может этого не спровоцировать, так как по умолчанию он не делает sparse copying.

LnxBil

Guest

#19

13.03.2024 10:44:00

Да, возможно, я неправильно понял комментарий про опцию issue_discards. Я думал, что это опция LVM, которая делает сброс данных перед разреженным копированием образа диска. Поэтому я подозревал LVM, но, конечно, основная проблема в хранилище, которое не учитывает это. Если опция discard интерпретируется неправильно и данные на самом деле не обнуляются, то возникает проблема, описанная здесь.

lost_avocado Guest	#20 0 13.03.2024 10:46:00 Это Lenovo DS4200, не самая редкая штука, наверное. Он производится уже несколько лет, подключен к другим системам, и у нас с ним никогда не было проблем. Если я делаю клон (выдает 'Offset mismatch'), потом заполняю диск нулями и удаляю vm, а потом клонирую абсолютно тот же самый шаблон, то образы идентичны. Это проблема бэкенд-хранилища? Разве процесс клонирования не должен это учитывать? Еще кое-что. Я попытался отредактировать файл lvm.conf и раскомментировал параметр "wipe_signatures_when_zeroing_new_lvs = 1", но это ничего не решило. Есть ли возможность как-то заставить qm клон делать дополнительное заполнение дисков нулями?

Читают тему

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