Да, работаю над этим ^_^ . (Сейчас работаю над добавлением внешней qcow2-снимок для общего lvm тоже для san array). Для внутреннего снимка, думаю, это сделано намеренно: iops замораживаются до тех пор, пока снимок полностью не удалён.

Привет, похоже, у меня та же самая проблема. Обычно, когда мы создаем снимок перед обновлениями в ВМ, а затем удаляем его, если все прошло успешно, это занимало всего несколько секунд. Сегодня я снова сделал то же самое, но при удалении снимка ВМ зависла на 2 минуты, пока снимок наконец не был удален. Я подумал, что это странно, и провел тест на другой ВМ, и там проблема была еще хуже. ВМ зависла до истечения времени ожидания команды удаления снимка. После истечения времени ожидания команды удаления снимка снимок все еще был указан, а ВМ находилась в заблокированном состоянии. Я смог ее разблокировать, но затем, когда попытался удалить снимок снова, появилась ошибка, и ВМ снова заблокировалась. При попытке удалить снимок из командной строки qemu сообщил, что он не существует в соответствующем файле qcow2. Но в файле <vmid>.conf все еще была запись о снимке, поэтому я удалил ее вручную, и все вернулось в норму. Похоже, что с моментами в последних релизах что-то не так. Хранилище – это NFS-шара на быстром Huawei SAN, и у нас никогда не было таких проблем со снимками раньше. Пример конфигурации ВМ: Code: agent: 1
bios: ovmf
boot: order=scsi0
cores: 12
cpu: SandyBridge
efidisk0: Huawei_NFS:121/vm-121-disk-0.qcow2,size=128K
machine: q35
memory: 12228
name: es-node03
net0: virtio=5E:32:B0:13:AB:50,bridge=vmbr0,tag=10
numa: 1
ostype: l26
protection: 1
scsi0: Huawei_NFS:121/vm-121-disk-1.qcow2,discard=on,iothread=1,size=40G,ssd=1
scsi1: Huawei_NFS:121/vm-121-disk-2.qcow2,discard=on,iothread=1,size=300G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=5c3d90f9-90cf-4761-9c7e-f3aa7d1ae38a
sockets: 1
tablet: 0
vga: qxl
vmgenid: 44b49263-be54-46d4-b5ef-953f8f80b3f7 Быстрый и грязный тест записи на хранилище: Code: root@pm04:/mnt/pve/Huawei_NFS# dd if=/dev/zero of=test bs=4k oflag=direct count=1000
1000+0 records in
1000+0 records out
4096000 bytes (4.1 MB, 3.9 MiB) copied, 0.244436 s, 16.8 MB/s Code: root@pm04:/mnt/pve/Huawei_NFS# dd if=/dev/zero of=test bs=1024k oflag=direct count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 2.03062 s, 516 MB/s Code: pve-manager 7.2-5
Linux pm04 5.15.35-3-pve #1 SMP PVE 5.15.35-6 (Fri, 17 Jun 2022 13:42:35 +0200) x86_64 GNU/Linux Есть какие-нибудь идеи?

Прости за такой поздний ответ. У меня та же проблема, независимо от объема хранилища. Я пробовал с NFS, локальным хранилищем и LVM-iSCSI. При создании снимка я не делал дамп оперативной памяти. @tanfoglionet, к сожалению, у меня нет никакой информации, и я так и не смог разобраться в этом...

Ну, по крайней мере, у меня так произошло только после того, как я дал снапшоту несколько часов/дней. Так что, когда ты удаляешь снапшот, я бы предположил, что происходит консолидация, и это "замораживает" машину. Попробуй создать снапшот, дай ему постоять 1-2 дня, а потом удали.

Еще не доступно, нацеливаюсь на pve9.0. (надо сначала сделать какое-то масштабное внутреннее изменение управления блоками в QEMU, прежде чем это можно будет сделать).