Привет, Вагнер,

Я попробовал клонировать контейнер в другой мостик и смонтировать другую папку (чтобы не запутать бэкапы), и он регулярно зависал. Сегодня вечером попробую восстановить тот же контейнер 101 и посмотрю, зависнет ли он через несколько секунд. Никаких задач не выполнялось, когда я пробовал его остановить, и это происходит детерминированно. А вот выключение происходит быстро.

Если это может помочь, я пробовал запустить `strace lxc-stop -n 101 --kill`, и он зависает здесь:

```
connect(3, {sa_family=AF_UNIX, sun_path=@"/var/lib/lxc/101/command"}, 27) = 0
getpid()                                = 2624506
getuid()                                = 0
getgid()                                = 0
sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=16}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, cmsg_data={pid=2624506, uid=0, gid=0}}], msg_controllen=32, msg_flags=0}, MSG_NOSIGNAL) = 16
recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\0\0\0\0\0\2\0\0\0\0\0\0\0", iov_len=16}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 16
close(3)                                = 0
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path=@"/var/lib/lxc/101/command"}, 27) = 0
getpid()                                = 2624506
getuid()                                = 0
getgid()                                = 0
sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=16}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, cmsg_data={pid=2624506, uid=0, gid=0}}], msg_controllen=32, msg_flags=0}, MSG_NOSIGNAL) = 16
recvmsg(3,

// ЖДЕМ НЕСКОЛЬКО МИНУТ, recvmsg завершен //

recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="", iov_len=16}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 0
close(3)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++
```

Я прикреплю весь вывод `strace`.

Я попытался вручную выключить 2 ВМ и 2КТ, работающие на моем PVE, и это заняло меньше 40 секунд:

```
Code: time pve-bulk shutdown --vm-list=103,104 --ct-list=101,105
```

```
ct101 : shutdown has succeeded
ct105 : shutdown has succeeded
vm103 : shutdown has succeeded
vm104 : shutdown has succeeded
```

```
real    0m39.423s
user    0m1.684s
sys     0m0.204s (pve-bulk calls qm/pct shutdown)
```

Это те ВМ/КТ, которые работали, когда я сделал выключение. Есть какие-нибудь логи, чтобы проверить, что происходит?

Привет, Вагнер, процедура выключения системы выполняет стоп или выключение для CTs/VMs? Я заметил, что выключение, которое должно занимать больше времени, завершается за 40 секунд, а если я выполняю стоп для работающих CTs и VMs, то оно зависает на остановке CT 101 на несколько минут. Я думал, что процедура выключения PVE использует команду shutdown для корректного завершения работы работающих CTs и VMs, а не команду stop, которая может повредить файловую систему VM при немедленной остановке. Если она использует команду stop, нам всегда следует делать чистое выключение всего, что работает на хосте, прежде чем запускать выключение на PVE, верно? Кстати, если выключение PVE выполняет стоп для всего вместо выключения, моя проблема может быть связана с тем, что CT 101 не выключается сразу (ШЕСТЬ минут для стопа, 2 секунды для выключения):

Код: root@pve:~# time pct shutdown 101
                                                                                                                                                                                                       
real    0m2.862s
user    0m0.461s
sys     0m0.034s
root@pve:~# pct start 101
root@pve:~# pct status 101
status: running
root@pve:~# time pct stop 101
                                                                                                                                                                                                       
real    6m6.311s
user    0m0.500s
sys     0m0.075s Follows the config of the CT101
Код: root@pve:~# cat /etc/pve/lxc/101.conf
#**Proxmox Backup Server**
arch: amd64
cores: 6
features: nesting=1
hostname: ProxmoxBackupServer
memory: 4096
mp1: /mnt/pve/sata_disk/pbs_backups,mp=/pbs_backups
net0: name=eth0,bridge=vmbr0,firewall=1,gw=10.0.0.254,hwaddr=CA:CE:16:FC:86:01,ip=10.0.0.5/24,type=veth
onboot: 1
ostype: debian
rootfs: local-lvm:vm-101-disk-0,size=32G
searchdomain: mynetwork
startup: order=1
swap: 512

Небольшое обновление.. Я провел следующие тесты с CT101, без восстановления из бэкапов:
- Попробовал удалить NFS datastore, на который указывает контейнер PBS => ничего не изменилось.
- Переместил интерфейс net0 с vmbr0 на vmbr1, где он недоступен никому (PVE не может его опросить) => он останавливается через несколько секунд.

Так что похоже, что очень медленная остановка происходит, когда он на vmbr0, и возможно он застрял на каких-то сетевых соединениях (от PVE?). Как только я запускаю команду остановки, я не могу его обнаружить в сети, так что кажется странным, что он застрял на чем-то, связанном с сетью. Кстати, даже если остановка CT101 занимает так много времени, это не должно влиять на процедуру выключения, ведь обычное выключение CT101 занимает всего несколько секунд (это действительно то, чего я не понимаю, выключение должно быть медленнее, чем остановка). Если есть что-то еще, что я могу попробовать, просто скажите, и я протестирую.

Привет, я использую vmbr0 в качестве основного моста для подключения ВМ к моей домашней сети. Он поддерживает VLAN, так как одна из ВМ помечает свой трафик. Затем есть два других моста, используемых для внутренней связи между некоторыми ВМ/контейнерами. Тот факт, что перемещение сети PBS CT101 в другой vmbr приводит к тому, что он почти сразу же останавливается, заставил меня подумать, что он поддерживается в активном состоянии подключением извне, например, подключением от PVE. Поэтому я попробовал оставить PBS в vmbr0, но заблокировать всю связь извне с помощью брандмауэра CT101, и ничего не изменилось. Затем я установил политику вывода брандмауэра в REJECT и перезагрузил CT101: остановка CT101 без разрешенной исходящей связи происходит почти немедленно, следовательно, какая-то сетевая связь блокирует процесс остановки. Как только я запускаю pct stop 101, процесс lxc-start переходит в состояние D (в то время как в PBS CT перед запуском остановки процессов в состоянии D нет):

Код: root@pve:~# ps aux | grep "lxc.*101" | grep -v grep
root     3192525  0.0  0.0   3952  3208 ?        Ds   11:47   0:00 /usr/bin/lxc-start -F -n 101
root     3193084  0.0  0.0  91256  7988 ?        S    11:47   0:00 /usr/bin/termproxy 5900 --path /vms/101 --perm VM.Console -- /usr/bin/dtach -A /var/run/dtach/vzctlconsole101 -r winch -z lxc-console -n 101 -e -1
root     3193088  0.0  0.0   2280   588 pts/1    Ss+  11:47   0:00 /usr/bin/dtach -A /var/run/dtach/vzctlconsole101 -r winch -z lxc-console -n 101 -e -1
root     3193089  0.0  0.0   2412    84 ?        Ss   11:47   0:00 /usr/bin/dtach -A /var/run/dtach/vzctlconsole101 -r winch -z lxc-console -n 101 -e -1
root     3193090  0.0  0.0   3884  2640 pts/3    Ss+  11:47   0:00 lxc-console -n 101 -e -1
root     3193102  0.0  0.0   3884  2804 pts/0    S+   11:47   0:00 lxc-stop -n 101 --kill

Это мой файл /etc/network/interfaces:

Код:
auto lo
iface lo inet loopback

iface eno1 inet manual
   ethernet-wol g
   post-up /usr/bin/logger -p debug -t ifup "Disabling segmentation offload for eno1" && /sbin/ethtool -K $IFACE tso off gso off && /usr/bin/logger -p debug -t ifup "Disabled offload for eno1"

auto vmbr0
iface vmbr0 inet static
   address 10.0.0.4/24
   gateway 10.0.0.254
   bridge-ports eno1 eno2
   bridge-stp off
   bridge-fd 0
   bridge-vlan-aware yes
   bridge-vids 2-4094

iface wlp0s20f3 inet manual

iface eno2 inet manual

auto vmbr1
iface vmbr1 inet manual
   bridge-ports none
   bridge-stp off
   bridge-fd 0

auto vmbr999
iface vmbr999 inet manual
   bridge-ports none
   bridge-stp off
   bridge-fd 0

В PBS нет процессов в состоянии D:

Код: root@ProxmoxBackupServer:~# ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.2 165652  9832 ?        Ss   Nov28   0:00 /sbin/init
root          53  0.0  0.2  32004 10936 ?        Ss   Nov28   0:00 /lib/systemd/systemd-journald
systemd+      64  0.0  0.1  16052  6896 ?        Ss   Nov28   0:00 /lib/systemd/systemd-networkd
systemd+      79  0.0  0.2  24112 11752 ?        Ss   Nov28   0:00 /lib/systemd/systemd-resolved
message+      82  0.0  0.0   8092  4176 ?        Ss   Nov28   0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofor
root          83  0.0  0.1  14008  6916 ?        Ss   Nov28   0:00 /lib/systemd/systemd-logind
root         126  0.0  0.4 512040 20320 ?        Ssl  Nov28   1:41 /usr/lib/x86_64-linux-gnu/proxmox-backup/proxmox-backup-
backup       154  0.0  0.8 1325144 34460 ?       Ssl  Nov28   1:52 /usr/lib/x86_64-linux-gnu/proxmox-backup/proxmox-backup-
root         238  0.0  0.0   3748  2376 ?        Ss   Nov28   0:00 /usr/sbin/cron -f
root         241  0.0  0.0   2508  1712 pts/0    Ss+  Nov28   0:00 /sbin/agetty -o -p -- \u --noclear --keep-baud console 1
root         242  0.0  0.0   2508  1652 pts/1    Ss+  Nov28   0:00 /sbin/agetty -o -p -- \u --noclear --keep-baud tty2 1152
root         243  0.0  0.0   2508  1652 pts/2    Ss+  Nov28   0:00 /sbin/agetty -o -p -- \u --noclear --keep-baud tty3 1152
root         311  0.0  0.1  40052  4808 ?        Ss   Nov28   0:00 /usr/lib/postfix/sbin/master -w
postfix      313  0.0  0.1  40356  6788 ?        S    Nov28   0:00 qmgr -l -t unix -u
postfix      989  0.0  0.1  40308  6720 ?        S    09:09   0:00 pickup -l -t unix -u -c
root        1029  0.0  0.2  14520  8824 ?        Ss   10:21   0:00 sshd: root@pts/3
root        1032  0.0  0.1  15068  7664 ?        Ss   10:21   0:00 /lib/systemd/systemd --user
root        1033  0.0  0.0 168608  2656 ?        S    10:21   0:00 (sd-pam)
root        1042  0.0  0.0   4824  4056 pts/3    Ss   10:21   0:00 -bash
root        1049  0.0  0.0   6760  2944 pts/3    R+   10:22   0:00 ps aux

Я немного поэксперинировал, но у меня не получилось воспроизвести эту проблему. Может, у других пользователей есть идеи, что тут происходит.

Привет всем! Думаю, у меня похожая проблема. Установил экземпляр Proxmox на старый ПК с одним узлом, с процессором Intel i5, 24ГБ оперативной памяти и SSD на 2ТБ. Установка прошла успешно, я выделил около 200ГБ для локальной секции для хранения ISO/шаблонов и т.д., а остальное дисковое пространство – для local-lvm для ВМ. Также подключил SMB-шару для резервного копирования. Все работало нормально, пока я не попытался выключить физический хост. Проблема в том, что хост не выключается полностью, а перезагружается и перезапускается. У меня нет ни одной ВМ или CT, так что это не связано с какой-то ВМ, которая не выключается корректно. Я пробовал выключать хост через веб-интерфейс или запускать команду выключения через оболочку, но поведение всегда одно и то же – сервер сам перезагружается вместо того, чтобы выключаться. Единственный способ выключить сервер – принудительно выключить его, нажав кнопку питания 10 секунд. Установил последнюю версию Proxmox 8.2 и обновил репозитории не для enterprise. Буду рад любым советам и предложениям, я новичок в мире виртуализации. Заранее спасибо!
Андреа