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

ПВЕ неожиданные перезагрузки., Proxmox Виртуальная Среда

c3sro

Guest

15.04.2024 08:34:00

Привет, PVE-узел неожиданно перезагрузился. Факты о PVE:

* Ядро: Linux 6.5.13-5-pve
* Хранилище: 2xSSD (ZFS Raid 1)
* CPU: AMD Ryzen 9 7950X3D (16 ядер)
* RAM: 128GB

Сбои начались после добавления еще одной ВМ, которая выполняет некое виртуализацию в виртуализации (VirtualBox внутри PVE). ВМ на PVE-узле:

* 6x ВМ с 4 CPU каждая (тип процессора: host)
* 1x ВМ с 8 CPU, выполняющая некую виртуализацию (тип процессора: host)

В общем, PVE-узел перегружен CPU (32 vCPU, 16 ядер CPU, 32 потока CPU). Вся остальная загрузка ресурсов (RAM, дисковое пространство) низкая и не перегружена.

Примерно между 5 минутами и 24 часами PVE-узел неожиданно перезагружается. В journalctl или /var/log/ нет записей о сбое (только загрузка PVE-узла с проверкой файловой системы).

Предпринятые шаги для решения проблемы:

* Включены и протестированы дамп ядра при сбое: дамп ядра не записывается
* Отключена автоматическая перезагрузка, если не удалось записать дамп ядра: все равно автоматически перезагружается
* Провайдер провел стресс-тест всех компонентов: проблем не обнаружено
* Добавлен пользовательский тип CPU (x86-64-v4 с флагом svm) (см. https://forum.proxmox.com/threads/sudden-bulk-stop-of-all-vms.139500/#post-642039): все равно сбоит/перезагружается
* Уменьшено общее количество vCPU до 8 (см. https://forum.proxmox.com/threads/sudden-bulk-stop-of-all-vms.139500/post-643308): PVE-узел больше не сбоит

Несмотря на то, что обходной путь с уменьшением общего количества vCPU помог стабилизировать систему, это все равно не является для меня приемлемым решением, поскольку много CPU ресурсов простаивают, и гибкость PVE-узла довольно ограничена.

Основная проблема, с которой я сталкиваюсь сейчас, — это то, что я не могу определить первопричину проблемы. Проблема в ядре? Неисправный CPU? Неисправный блок питания? ...

У кого-нибудь были похожие проблемы и как вы их решили? Есть ли какие-нибудь еще идеи, как найти первопричину?

fiona Guest	#2 0 15.04.2024 11:38:00 Привет! У тебя установлены последние обновления BIOS и микрокод процессора? У тебя какие-нибудь особые настройки, связанные с процессором, включены в BIOS? Стоит попробовать ядро 6.8 (opt-in).

c3sro

Guest

15.04.2024 11:51:00

Обновления BIOS управляются поставщиком, так что я ничего не могу изменить (Pro WS 665-ACE, BIOS 1711 10/06/2023). Сервер работает на микрокоде версии 0x0a601206, что является последней доступной версией для этого CPU. Насколько мне известно, в BIOS нет никаких специальных настроек (опять же, они в основном управляются поставщиком). Есть ли какие-то конкретные настройки, которые мне стоит проверить? Возможно, стоит попробовать ядро 6.8. Вы знаете какие-нибудь исправления для вложенной виртуализации в 6.6 - 6.8?

fiona Guest	#4 0 15.04.2024 12:38:00 Я не знаю, какая у тебя проблема конкретно, поэтому, к сожалению, у меня нет никаких конкретных предложений. И еще раз, я не знаю никаких конкретных проблем.

c3sro

Guest

22.04.2024 11:51:00

Обновление: провайдер заменил весь сервер (новый CPU, память, блок питания, материнская плата и т.д.). К сожалению, сервер все равно регулярно падает. Учитывая, что некоторые пользователи сообщают о похожих проблемах (https://forum.proxmox.com/threads/sudden-bulk-stop-of-all-vms.139500/page-2), думаю, что причина не в каком-то бракованном оборудовании (материнская плата, память и т.д.) или неправильной настройке BIOS. Гораздо вероятнее, что проблема в CPU AMD Ryzen 9 7950X3D. Это может быть какой-то баг CPU, ошибка Microcode или просто проблема с ядром. Я понятия не имею, как выяснить причину этих случайных сбоев.

JerryOH Guest	#6 0 26.04.2024 14:44:00 У нас та же проблема на 5 серверах с Ryzen 9 7950x3d: каждый случайным образом зависает, и консоль входа в Proxmox тоже перестаёт отвечать.

Christoph Lechleitner Guest	#7 0 29.04.2024 15:04:00 У нас было несколько перезагрузок и зависаний на Intel NUC с процессорами i5 и i7. Мы обновимся до 8.2 (ядро 6.8) через пару недель и надеемся, что проблема исчезнет…

c3sro Guest	#8 0 03.05.2024 15:30:00 После обновления с PVE 8.1 на 8.2 сервер больше не вылетает. Всё равно не представляю, в чём была причина проблемы.

c3sro

Guest

10.05.2024 12:04:00

Проблема всё ещё остаётся... Было 14 дней стабильной работы, а сервер снова упал. Примерно через 15 минут после первого падения с PVE 8.2 произошёл второй. Так что, в общем, обновление до PVE 8.2 проблему не решило. Я понятия не имею, почему две недели всё работало нормально, но особенно второй сбой сразу после первого только доказывает, что проблема всё ещё существует.

Christoph Lechleitner

Guest

#10

22.05.2024 14:33:00

Наш NUC на базе i5 7-го поколения перезагружается почти каждые 24 часа, с PVE 8.2. Отладка через netconsole не дала никаких полезных данных. Попробуйте, например, `journalctl -b -1 -n 50`, чтобы посмотреть, что там есть:

```
May 21 01:55:20 pvehq02 systemd[1]: Stopping user@0.service - User Manager for UID 0...
May 21 01:55:20 pvehq02 systemd[1737042]: Activating special unit exit.target...
May 21 01:55:20 pvehq02 systemd[1737042]: Stopped target default.target - Main User Target.
May 21 01:55:20 pvehq02 systemd[1737042]: Stopped target basic.target - Basic System.
May 21 01:55:20 pvehq02 systemd[1737042]: Stopped target paths.target - Paths.
May 21 01:55:20 pvehq02 systemd[1737042]: Stopped target sockets.target - Sockets.
May 21 01:55:20 pvehq02 systemd[1737042]: Stopped target timers.target - Timers.
May 21 01:55:20 pvehq02 systemd[1737042]: Closed dirmngr.socket - GnuPG network certificate management daemon.
May 21 01:55:20 pvehq02 systemd[1737042]: Closed gpg-agent-browser.socket - GnuPG cryptographic agent and passphrase cache (access for web browsers).
May 21 01:55:20 pvehq02 systemd[1737042]: Closed gpg-agent-extra.socket - GnuPG cryptographic agent and passphrase cache (restricted).
May 21 01:55:20 pvehq02 systemd[1737042]: Closed gpg-agent-ssh.socket - GnuPG cryptographic agent (ssh-agent emulation).
May 21 01:55:20 pvehq02 systemd[1737042]: Closed gpg-agent.socket - GnuPG cryptographic agent and passphrase cache.
May 21 01:55:20 pvehq02 systemd[1737042]: Removed slice app.slice - User Application Slice.
May 21 01:55:20 pvehq02 systemd[1737042]: Reached target shutdown.target - Shutdown.
May 21 01:55:20 pvehq02 systemd[1737042]: Finished systemd-exit.service - Exit the Session.
May 21 01:55:20 pvehq02 systemd[1737042]: Reached target exit.target - Exit the Session.
May 21 01:55:20 pvehq02 systemd[1]: user@0.service: Deactivated successfully.
May 21 01:55:20 pvehq02 systemd[1]: Stopped user@0.service - User Manager for UID 0.
May 21 01:55:20 pvehq02 systemd[1]: Stopping user-runtime-dir@0.service - User Runtime Directory /run/user/0...
May 21 01:55:20 pvehq02 systemd[1]: run-user-0.mount: Deactivated successfully.
May 21 01:55:20 pvehq02 systemd[1]: user-runtime-dir@0.service: Deactivated successfully.
May 21 01:55:20 pvehq02 systemd[1]: Stopped user-runtime-dir@0.service - User Runtime Directory /run/user/0.
May 21 01:55:20 pvehq02 systemd[1]: Removed slice user-0.slice - User Slice of UID 0.
May 21 01:55:20 pvehq02 systemd[1]: user-0.slice: Consumed 2.979s CPU time.
```

Что-то перезагружает систему намеренно? У нас были жалобы на карты Intel e1000, поэтому мы попробовали `ethtool -K eno1 tx off rx off`, но это не помогло. Последний лог изменился:

```
May 22 00:50:08 pvehq02 sshd[486038]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
May 22 00:50:08 pvehq02 systemd-logind[652]: New session 2571 of user root.
May 22 00:50:08 pvehq02 systemd[1]: Started session-2571.scope - Session 2571 of User root.
May 22 00:50:08 pvehq02 sshd[486038]: pam_env(sshd:session): deprecated reading of user environment enabled
May 22 00:50:09 pvehq02 sshd[486038]: Received disconnect from 192.168.13.17 port 52422:11: disconnected by user
May 22 00:50:09 pvehq02 sshd[486038]: Disconnected from user root 192.168.13.17 port 52422
May 22 00:50:09 pvehq02 sshd[486038]: pam_unix(sshd:session): session closed for user root
May 22 00:50:09 pvehq02 systemd[1]: session-2571.scope: Deactivated successfully.
May 22 00:50:09 pvehq02 systemd-logind[652]: Session 2571 logged out. Waiting for processes to exit.
May 22 00:50:09 pvehq02 systemd-logind[652]: Removed session 2571.
```

c3sro

Guest

#11

22.05.2024 15:21:00

Думаю, баг, влияющий на систему, о котором речь в этой теме, связан с проблемой, специфичной для конкретного процессора (см. https://forum.proxmox.com/threads/sudden-bulk-stop-of-all-vms.139500/page-3#post-664460), что приводит к жёсткому зависанию. У вас, похоже, другая проблема, потому что у вас нет этого конкретного процессора, и ваша система была выключена корректно (хотя и непреднамеренно).

kernull

Guest

#12

13.12.2024 02:59:00

Кто-нибудь что-то обнаружил в последнее время по этой проблеме? Я только что заметил, что сегодня мой сервер сам перезагрузился, пока я им пользовался – тоже сборка на 7950X3D... Код: Dec 12 00:00:15 pve systemd[1]: Starting dpkg-db-backup.service - Daily dpkg database backup service...
Dec 12 00:00:15 pve systemd[1]: Starting logrotate.service - Rotate log files...
Dec 12 00:00:15 pve systemd[1]: dpkg-db-backup.service: Deactivated successfully.
Dec 12 00:00:15 pve systemd[1]: Finished dpkg-db-backup.service - Daily dpkg database backup service.
Dec 12 00:00:15 pve systemd[1]: Reloading pveproxy.service - PVE API Proxy Server...
Dec 12 00:00:16 pve pveproxy[281830]: send HUP to 1355
Dec 12 00:00:16 pve pveproxy[1355]: received signal HUP
Dec 12 00:00:16 pve pveproxy[1355]: server closing
Dec 12 00:00:16 pve pveproxy[1355]: server shutdown (restart)

fiona

Guest

#13

13.12.2024 10:28:00

Привет, исходная проблема решена в более новых версиях ядра: https://forum.proxmox.com/threads/sudden-bulk-stop-of-all-vms.139500/post-718198. Кажется, что система не перезагрузилась жёстко. Скорее всего, служба pveproxy просто перезапустилась. Это, например, может происходить во время обновления.

kernull

Guest

#14

17.12.2024 15:04:00

Прости, я ошибся, ты прав... Похоже, у меня проблема с одним гостем, и я подумал, что перезагружается весь бокс. Из-за какой-то причины, этот единственный гость с Win10 и passthru PCIe GPU постоянно перезагружается, будто случайно, и я не знаю почему. Ballooning отключен, и сразу после перезагрузки в логах задач Proxmox появляется "bulk start VMs" по какой-то причине... Я всё ещё пытаюсь найти время, чтобы разобраться. Буду благодарен за любые идеи или предложения, где можно посмотреть. Спасибо за внимание!

fiona

Guest

#15

18.12.2024 10:18:00

Понять, что запускает массовую задачу, может быть хорошим первым шагом. System Logs (в гостевой ОС и на хосте) и Task History — хорошие места, чтобы начать поиск. У вас установлены какие-нибудь сторонние (мониторинговые) скрипты? Не стесняйтесь присылать полные логи, когда ищут такие вещи, лишние глаза никогда не помешают.

kernull

Guest

#16

18.12.2024 15:16:00

У гостя произошёл внезапный сбой питания: система перезагрузилась без корректного завершения работы. Журнал хоста показывает "-- Reboot --", что я честно говоря не могу объяснить... и это происходит, кажется, сразу после авторизации root через pam через веб-интерфейс. Никакой команды перезагрузки никогда не вводилась через CLI. Не уверен, что это может вызывать. Код: Dec 17 03:17:01 pve CRON[373676]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Dec 17 03:17:01 pve CRON[373677]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
Dec 17 03:17:01 pve CRON[373676]: pam_unix(cron:session): session closed for user root
Dec 17 03:17:32 pve pveproxy[364133]: worker exit
Dec 17 03:17:32 pve pveproxy[1361]: worker 364133 finished
Dec 17 03:17:32 pve pveproxy[1361]: starting 1 worker(s)
Dec 17 03:17:32 pve pveproxy[1361]: worker 373761 started
Dec 17 03:19:48 pve pveproxy[373334]: Clearing outdated entries from certificate cache
Dec 17 03:20:12 pve pveproxy[367291]: worker exit
Dec 17 03:20:12 pve pveproxy[1361]: worker 367291 finished
Dec 17 03:20:12 pve pveproxy[1361]: starting 1 worker(s)
Dec 17 03:20:12 pve pveproxy[1361]: worker 374179 started
Dec 17 03:23:16 pve pveproxy[373761]: Clearing outdated entries from certificate cache
Dec 17 03:26:15 pve pvedaemon[1351]: <root@pam> successful auth for user 'root@pam'
-- Reboot --

[\CODE]

Буду признателен за любые идеи/советы!
Спасибо!

BTca

Guest

#17

18.12.2024 22:52:00

К сведению: У нас 100% проблема с PROXMOX и процессором Ryzen 9 7950X3D. У нас несколько Proxmox-серверов, и ЧЕТЫРЕ сервера работают с процессором "Ryzen 9 7950X3D" — у нас только проблемы. Мы перепробовали ВСЁ, что только можно было: меняли материнские платы, блоки питания, новую память (разного бренда), меняли M.2, заменяли сетевую плату (несколько разных брендов, даже Intel). Естественно, следили за тем, чтобы были установлены последние обновления, последняя прошивка для M.2, последняя прошивка Broadcom, когда мы пробовали один из них, и всегда обновляли Proxmox. В КАЖДОМ случае мы дожидались сбоя, прежде чем заменять или пробовать что-то, чтобы быть уверенными, что это решит проблему. Проблема возникает на ЧЕТЫРЕХ разных машинах, и единственное, что их объединяет — это процессор "Ryzen 9 7950X3D". Теперь мы пробуем другие процессоры. Я в ярости, потому что НИКТО не хочет брать на себя ответственность за это, и мы потратили более 100 часов на IT, пытаясь это исправить.

narrateourale

Guest

#18

18.12.2024 23:00:00

В общем, из чистого любопытства, сколько слотов памяти заполнено и с какой скоростью она настроена? У меня нет этого конкретного Ryzen CPU, но были похожие проблемы, когда все 4 слота RAM были заполнены и активирован профиль XMP. Только после того, как я установил память на базовую скорость без какого-либо профиля XMP, машина стала стабильной. Если посмотреть спецификации (связность), там указаны следующие максимальные скорости памяти в зависимости от того, сколько слотов заполнено:

BTca

Guest

#19

19.12.2024 00:58:00

Интересная информация, спасибо за ответ и любые дополнительные советы, которые вы можете дать. Будем пробовать всё. Сейчас используем 96 ГБ общей памяти DDR5-A1 и DDR5-A2, используем G.Skill Flare X5. Перед заменой памяти у нас была Corsair DDR5-6400, и, конечно, это не работало, поэтому мы заменили её на вышеуказанную. ВОПРОС: Наш специалист по железу сказал, что 5600 снизит тактовую частоту, если спецификация 5200, и BIOS показывает память как DDR5-5200.

narrateourale Guest	#20 0 19.12.2024 01:15:00 По личному опыту: если заполнить все 4 слота DIMM и установить более быструю XMP-профиль (по умолчанию 3600), то всё, что выше — это разгон с профилем, — может привести к тому, что один хост с AMD 7900X начнёт странно себя вести и периодически перезагружаться без видимой причины. Если снизить скорость RAM до 3600 или даже немного медленнее, машина работает стабильно. Другая машина с похожей конфигурацией спокойно справляется с большей скоростью RAM. Предполагаю, что особенно при заполнении всех слотов DIMM и использовании высокой скорости памяти, качество контроллера памяти в CPU имеет значение: некоторые справляются больше, некоторые — нет. Также не уверен, прошло уже некоторое время, но memtest с более высокой скоростью памяти/XMP-профилем не вызывал ли каких-либо ошибок. Но если этого ещё не делали, то стоит рассмотреть возможность запуска memtest.

Читают тему

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