Короткий ответ

До любых изменений на pve1 (патч, диск, vmbr0, CPU type) сохраните проверяемый baseline: версии, кворум, storage, ZFS/LVM, список VM, факт успешного backup 101, свободное место. Красный pvesm, DEGRADED rpool или no quorum — работы переносятся, чинится первопричина.

Этот текст не «починка». Нашли сбой — уходите в тематическую статью.

Симптомы и как отличить

Нужен чеклист, если:

  • предстоит обновление;
  • замена диска ZFS;
  • правка сети;
  • «в GUI всё зелёное», а CLI не смотрели.

Не замена диагностики аварии: если VM уже не стартует — старт, не этот чеклист как лечение.

Возможные причины

  1. Не заметили no quorum / один узел уже offline.
  2. Thin 95%, snapshot во время работ.
  3. Backup failed три ночи, узнали после порчи.
  4. Нет BMC, сеть правили по SSH.
  5. PCI VM не едет, простой не заложен.

Это причины не проверять, не причины «как устроен PVE».

Диагностика

Каталог заявки, плейсхолдеры подставьте. На каждом узле кластера.

1. Версии и службы

pveversion -v
systemctl status pveproxy pvedaemon pve-cluster --no-pager
systemctl is-active corosync
hostnamectl
timedatectl

Разъезд pveversion между узлами — зафиксируйте, не начинайте второй апдейт вслепую.

2. Кластер

pvecm status
pvecm nodes

Нужно Quorate: Yes, все узлы видны. Иначе quorum / узел выпал.

3. Storage и диски

pvesm status
lvs -a
vgs
zpool status rpool
df -h

Все боевые storage active. Thin Data%/Meta% с запасом. ZFS не DEGRADED (degraded).

4. VM

qm list
qm config 101
qm status 101

Отметьте: onboot, HA, hostpci, local vs shared disk, cpu:.

5. Backup

Последний успешный vzdump/PBS для критичных VM, место на backup storage, не failed в Task history. Если красный — vzdump или PBS до патча.

6. Сеть (если будете трогать)

ip -br addr
cat /etc/network/interfaces
bridge link

BMC/IPMI проверен входом, не «пингуется».

Решение

Работы можно начинать, если:

  • quorum OK;
  • pvesm status без неожиданных inactive;
  • нет DEGRADED/FAULTED, который вы не планировали чинить этим же окном;
  • backup критичных VM не старше политики (например 24 ч) и last job OK;
  • есть план миграции/простоя для каждой VM на затрагиваемом узле;
  • BMC доступен.

Нельзя, если любое из: no quorum, backup fail без разбора, Data% ≈ 100, неизвестно, куда поедет 101.

Зафиксируйте команду отката: предыдущее ядро GRUB, копия interfaces, не «снимки всех прод-VM на час работ» как единственный план.

Что сохранить в заявку и пороги «стоп-работы»

Складывайте выводы так, чтобы другой дежурный повторил сравнение после окна:

mkdir -p /root/change-$(date +%F)
pveversion -v | tee /root/change-$(date +%F)/pveversion.txt
pvecm status | tee /root/change-$(date +%F)/pvecm.txt
pvesm status | tee /root/change-$(date +%F)/pvesm.txt
zpool status rpool | tee /root/change-$(date +%F)/zpool.txt
lvs -a | tee /root/change-$(date +%F)/lvs.txt
qm list | tee /root/change-$(date +%F)/qm.txt

Пороги но-го (пример политики, зафиксируйте свои): Data% thin ≥ 85%; ZFS errors ненулевые; last backup critical VM старше SLA; pvecm не quorate; systemctl --failed с pve-cluster/corosync. GUI «зелёный» при любом из этих — всё равно стоп.

Отдельно список VM на pve1: кто live-migrate, кто только stop, кто passthrough. Без списка обновление без простоя превращается в сюрприз в 03:00.

Проверьте BMC логином, не ping: «iLO отвечает ICMP, но консоль Java мертва» вы узнаете, когда ifreload уже ушёл. Для работ на vmbr0 это обязательный пункт, не опция.

Как проверить, что проблема устранена

После работ повторите тот же набор команд, сравните с файлами заявки:

pveversion -v
pvecm status
pvesm status
zpool status rpool
lvs
qm status 101

Версии целевые, quorum да, VM running, ping гостя, GUI. Backup job после окна не развален (иногда патч qemu меняет freeze — проверьте один тестовый backup).

Добавьте в baseline сеть и backup одной командой-напоминанием: last task OK для 101, ping шлюза с pve1, вход BMC. Если правите storage — pvesm status до и после плюс lvs/zpool. Если правите кластер — pvecm status до/после.

Чеклист бесполезен, если его не сравнивают. Сохраняйте diff -u каталогов change-ДАТА после окна. Расхождение qm list (пропала VM) — инцидент, не «наверное HA». Расхождение pveversion — ожидаемо только для узла, который только что патчили.

Не включайте в одно окно: apt, replace диска ZFS и перестройку vmbr0. Один риск на окно, остальное — стоп по чеклисту.

Если не помогло

Чеклист «зелёный», а изменение всё равно убило сервис: значит не сняли узкий факт (passthrough, VLAN на втором узле, QDevice). Дополните шаблон заявки. Не расширяйте окно вторым рискованным шагом (и диск, и сеть, и apt).

Профилактика

  • Регулярный сбор того же baseline по cron в закрытый лог.
  • Мониторинг quorum, pvesm, SMART, failed backup.
  • Шаблон change: что трогаем, кто rollback.
  • Не работать без BMC на management-мосте.
  • Тестовая миграция раз в месяц, не только в патч.

FAQ

Достаточно ли «в GUI всё зелёное»?

Нет. GUI не показывает Meta% thin, stale fingerprint PBS, steal. CLI обязателен.

Нужен ли snapshot перед apt?

Не вместо backup VM. Снимок хоста ZFS bootfs — по вашей схеме root, не замена PBS гостей.

Сколько времени занимает чеклист?

На 2–3 узлах — минуты, если команды уже в скрипте. Экономит часы отката.

Проверять Ceph этим же списком?

Если Ceph есть — добавьте ceph -s в обязательные. Этот раздел про PVE VM/storage классики.

Можно ли чеклист со «здорового» узла удалённо?

pvecm и pvesm частично да. zpool/lvs — локально на узле с дисками. Не пропускайте узел, который будете reboot.

Нужно ли zpool scrub в чеклисте перед каждым apt?

Не обязательно scrub в каждом окне: он сам нагрузка. Смотрите zpool status на ошибки и DEGRADED. Scrub — по расписанию, не как «ещё одна галочка перед патчем», если статус уже ONLINE без ошибок.