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

Простой гостей убирается не «магией apt», а rolling: проверить кластер → мигрировать VM с pve1 → apt только на этом узле → reboot если нужно → дождаться corosync → следующий узел. Не dist-upgrade на всех сразу. Репозиторий: enterprise или no-subscription, не смесь хаоса.

Одиночный узел без кластера без простоя не обновить, если ядро требует reboot — только HA/второй хост.

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

Это плановая работа, не авария. Отличия от поломок:

ЦельНе путать с
Патч qemu/pve-managerGUI лёг после кривого apt
Reboot узлаУзел выпал если забыли migrate
Кворум на время rebootпри двух узлах без QDevice — quorum

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

  1. Патч всех узлов параллельно.
  2. VM с local disk и PCI не мигрировали.
  3. Потеря кворума на 2-node.
  4. Сломанный репозиторий, недоустановленный пакет, GUI мёртв.
  5. Ceph/OSD на том же узле без drain (если Ceph есть — отдельный runbook).

Диагностика

Полный чеклист: проверка перед изменениями. Минимум:

pveversion -v
pvecm status
pvesm status
qm list
pvesm status
zpool status rpool
lvs
systemctl is-active pveproxy pvedaemon pve-cluster corosync

Репозитории:

grep -r . /etc/apt/sources.list /etc/apt/sources.list.d/ | grep -v '^#'
apt-get update
apt-get -s dist-upgrade

Симуляция -s обязательна: смотрите, не удалится ли pve-manager.

HA/local disk/passthrough — список VM, которые не уедут live. Для них — окно stop.

Решение

1. Подготовка

Backup свежий (PBS/vzdump). Окно. Сообщение пользователям, если есть non-migratable VM. На 2-node: QDevice или принятый риск no-quorum на reboot (лучше не).

2. Освободить pve1

Мигрируйте 101 и остальных на pve2 (миграция). На pve1 qm list пустой running.

3. Обновить один узел

apt-get update
apt-get dist-upgrade
pveversion -v

Подписки: enterprise URL с ключом. no-subscription — соответствующий list. Не подключайте случайные PPA.

4. Reboot если ядро/загрузчик

reboot

С BMC дождитесь SSH. Затем:

pvecm status
pvesm status
systemctl is-active pveproxy pvedaemon pve-cluster corosync

5. Вернуть нагрузку и повторить на pve2

Мигрируйте обратно при желании. Повторите шаги на следующем узле.

Одиночный узел

Простой равен reboot. Снизьте: сначала apt без reboot, если ядро не менялось; guest running переживут обновление userland с оговорками qemu — читайте changelog. Для qemu часто нужен restart VM позже.

Репозитории, reboot-needed и порядок HA

Перед apt-get dist-upgrade на pve1 убедитесь, что не включены одновременно enterprise и no-subscription на одни и те же пакеты в конфликте. pve-no-subscription vs pve-enterprise — выберите одну политику.

pveversion -v
apt-get -s dist-upgrade | grep -E 'pve-manager|qemu-server|corosync|Need to get'
ls /var/run/reboot-required 2>/dev/null || true
ha-manager status 2>/dev/null | head

Если reboot-required после apt — не мигрируйте VM обратно на этот узел до reboot. Иначе получите «полупатченный» qemu.

HA: поставьте узел pve1 в maintenance/evacuate (штатные действия HA manager), чтобы ресурсы не вернулись на него во время reboot. После online снимите maintenance.

Запись changelog: что вошло в 8.3.x (qemu, kernel). Известные notes про migration mixed-version прочитайте до того, как pve2 ещё 8.2, а pve1 уже 8.3. Короткое окно смеси допустимо; не добавляйте третий узел в апдейт в тот же час.

Не обновляйте firmware HBA в том же окне, что и PVE kernel, без отдельного плана. Слишком много переменных на один rollback.

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

Все узлы pveversion на целевом 8.3.x. pvecm status quorate. VM 101 running, сеть, диск. GUI 8006. Тестовая миграция туда-обратно. apt-get -s dist-upgrade без сюрпризов. Нет failed юнитов systemctl --failed.

После reboot pve1 не считайте узел готовым по SSH login. Обязательны pvecm status, pvesm status и zpool status rpool (если ZFS). Только потом migrate VM обратно. Если pve-cluster отстаёт на минуту — подождите, не pvecm expected.

Для no-subscription держите зеркало доступным в окно: apt-get update в начале окна, не в конце, когда VM уже съехали и откатываться поздно. Подписка enterprise: ключ не должен истечь в день патча — это выглядит как «сломался apt».

Смешанный кластер оставьте только на часы rolling. Третий узел не патчьте, пока два не зелёные по чеклисту health-check.

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

  • unmet dependencies: не reboot, apt-get -f install, не смешанные major репы.
  • Узел не вошёл в кластер: corosync.
  • После ядра не грузится: boot, GRUB previous kernel.
  • VM не едет: local/passthrough — добейте офлайн в окне.
  • Ceph HEALTH_ERR — не продолжайте rolling гипервизора, пока не разберёте OSD.

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

  • Подписка или осознанный no-subscription.
  • Регулярные маленькие окна, не год патчей сразу.
  • Кластер из трёх узлов, не два без QDevice.
  • Шаблон VM без passthrough для езды.
  • Changelog PVE перед окном.
  • apt-get update в начале окна, пока есть путь отката; не патчить firmware HBA в том же слоте, что kernel.
  • После reboot узла — полный health-check, и только потом обратная миграция VM на pve1.

FAQ

apt upgrade vs dist-upgrade?

На PVE обычно dist-upgrade (полное решение зависимостей метапакетов). upgrade может недоставить.

Можно ли обновлять, пока VM на узле?

Userland иногда да, ядро — нет без reboot. Live kernel patch не штатный путь PVE.

Смешанный 8.2 и 8.3 на время rolling?

Коротко да, это смысл rolling. Не оставляйте на недели без нужды.

Нужен ли pve8to9?

Нет для 8.2→8.3. Это другой мажор.

Отключать HA на время?

Имеет смысл, чтобы HA не таскала VM на патчущийся узел. Верните после.

Можно ли apt-get dist-upgrade через GUI «Upgrade» сразу на трёх узлах?

Нет. GUI на каждом узле — тот же apt. Параллельный клик = одновременный reboot-risk и потеря кворума. Один узел, migrate, reboot, проверка, следующий.