Да, верно. Я пробовал "Стоп"... также "Сброс" через некоторое время... но процесс не завершился, пока я не завершил его вручную (или 20-30 минут было недостаточно времени). И кстати: я использую функцию HA, так что менеджер HA тоже участвует в остановке ВМ.

Конечно: Убедитесь, что glusterfs теряет клиентское кворум. Когда у вас есть кластер из трех узлов (настроенный как реплика 2 или подобным образом) и вы затем выключаете две машины... то он теряет клиентское кворум и все должно заблокироваться. Затем (в моих случаях это были просто перезагрузки watchdog, но с плохим таймингом) обе машины снова включились, и кворум снова оказался в наличии... ВМ все равно были заблокированы. Поэтому лучший способ: - Убить две машины... вы должны увидеть, что файловая система переходит в режим только для чтения в ВМ или подобном - Затем снова запустите машины, чтобы вернуть glusterfs - Попробуйте перезапустить ВМ. Кстати, один случай, который у меня был, заключался в том, что одна ВМ вырубилась и "перезагрузилась" из-за проблем с файловой системой, а затем попала в бесконечный цикл загрузки, потому что файловая система была только для чтения... но и это произошло после того, как glusterfs снова начал работать. Поэтому еще одной вещью, которую можно попробовать, может быть "запустить ВМ, пока две машины выключены"... Для меня это была pve 5 до сих пор... сейчас я готовлюсь перейти на 6 в ближайшее время.

Может быть, обновленный Qemu, kvm и подобные в PVE 6 лучше реагируют на такие случаи, как в PVE 5? Код: root@pm1:~# gluster volume info

Имя тома: gv0  
Тип: Распределенный-Репликация  
Идентификатор тома: 64651501-6df2-4106-b330-fdb3e1fbcdf4  
Статус: Запущен  
Количество снимков: 0  
Количество кирпичей: 5 x 3 = 15  
Тип транспорта: tcp  
Кирпичи:  
Кирпич1: 192.168.178.50:/gluster/brick1/gv0  
Кирпич2: 192.168.178.76:/gluster/brick1/gv0  
Кирпич3: 192.168.178.96:/gluster/brick2/gv0  
Кирпич4: 192.168.178.50:/gluster/brick2/gv0  
Кирпич5: 192.168.178.81:/gluster/brick1/gv0  
Кирпич6: 192.168.178.94:/gluster/brick1/gv0  
Кирпич7: 192.168.178.50:/gluster/brick3/gv0  
Кирпич8: 192.168.178.82:/gluster/brick1/gv0  
Кирпич9: 192.168.178.94:/gluster/brick2/gv0  
Кирпич10: 192.168.178.50:/gluster/brick4/gv0  
Кирпич11: 192.168.178.95:/gluster/brick1/gv0  
Кирпич12: 192.168.178.94:/gluster/brick3/gv0  
Кирпич13: 192.168.178.50:/gluster/brick5/gv0  
Кирпич14: 192.168.178.96:/gluster/brick1/gv0  
Кирпич15: 192.168.178.94:/gluster/brick4/gv0  
Опции, переработанные:  
storage.fips-mode-rchecksum: включено  
cluster.choose-local: выключено  
user.cifs: выключено  
features.shard: включено  
cluster.shd-wait-qlength: 10000  
cluster.shd-max-threads: 4  
cluster.locking-scheme: гранулярный  
cluster.data-self-heal-algorithm: diff  
cluster.server-quorum-type: сервер  
cluster.quorum-type: авто  
cluster.eager-lock: включить  
network.remote-dio: включить  
performance.low-prio-threads: 32  
performance.io-cache: выключено  
performance.read-ahead: выключено  
performance.quick-read: выключено  
performance.client-io-threads: выключено  
nfs.disable: включено  
transport.address-family: inet  
cluster.granular-entry-heal: включить  

root@pm1:~# gluster volume get gv0 all | grep quorum  
cluster.quorum-type                     авто  
cluster.quorum-count                    (null)  
cluster.server-quorum-type              сервер  
cluster.server-quorum-ratio             0  
cluster.quorum-reads                    нет

Я все еще использую тип "Replicated" вместо "Distributed-Replicated", но те же настройки кворума для моего кластера Gluster. Пока что остановка ВМ по-прежнему отлично работает, когда файловая система становится только для чтения и возникают ошибки ввода-вывода. Может быть.