Теоретическая часть: «Почему hard — это не круто, а soft — спасение» 🔧

💾 Введение: История одной пятницы

Представьте: пятница, 17:45, вы уже мысленно c пивом в кафешке. И тут тишина... Мониторинг орет красным. Ваш Proxmox кластер из 4 нод превратился в группу статуй. Ни одна VM не отвечает, команды qm list висят, а в логах — таинственные вопросительные знаки на месте дисков.

😱 Диагноз: NFS‑сервер упал, а монтирование было с опцией hard. Все ноды дружно вошли в D‑state (непрерываемый сон) и отказались просыпаться.

Мораль: hard монтирование в NFS — это как клей Moment. Склеивает намертво. И оторвать потом невозможно.

📊 Анатомия проблемы: Почему мы так жили и чем это кончилось

Параметр

Было (классика)

Стало (после реанимации)

Монтирование

/etc/rc.local с hard

Proxmox Storage с soft

Поведение при падении NFS

Кластер встаёт колом

Ошибка, но нода жива

Мониторинг состояния

Нет, всё вручную

Встроенный в PVE

HA реакция

Неадекватная

Корректная

🎯 Главная проблема: Не в том, что NFS падает. А в том, как система реагирует на падение.

📡 Ключевая концепция: Hard vs Soft в NFS

Опция

Поведение

Риски

hard

Бесконечные попытки до успеха

Зависание всех процессов навсегда

soft

Ошибка после таймаута

Приложение получает ошибку, но система жива

🔬 Практическая часть: Как переобуть кластер без потрясений

📋 Ситуация: «Мы так жили, и всё работало... пока не упало»

Исходные данные:

  • 4 ноды Proxmox в кластере

  • NFS смонтирован через /etc/rc.local

  • Опция hard, таймаут 600 секунд

  • VM конфиги используют storage имена data: и ssd:

🎯 Цель: Перевести все ноды на Proxmox Storage с опцией soft без потери данных

Этап 1: «Сначала аудит, потом тушение» — Диагностика

bash

# 🔍 Смотрим, что у нас есть
echo "=== Текущие монтирования ==="
mount | grep nfs

echo "=== Кто чем пользуется ==="
for vmid in $(qm list | awk 'NR>1 {print $1}'); do
    echo "VM $vmid:"
    qm config $vmid | grep -E "(virtio|ide|scsi|sata|efidisk)"
    echo "---"
done

echo "=== Что в Proxmox Storage ==="
pvesm status

Находим сюрпризы:

  • Старое монтирование: /store/nfs/data (hard)

  • Новое монтирование: /mnt/pve/nfs-data (soft)

  • Важно! Это одно и то же NFS‑хранилище, просто видимое по‑разному

Этап 2: «Добавили, но не включили» — Создание новых storage

Правило безопасности: Сначала добавляем новые storage, потом мигрируем, только потом удаляем старые.

bash

# ➕ Добавляем новые storage с правильными опциями
pvesm add nfs nfs-data \
  --path /mnt/pve/nfs-data \
  --server 10.10.10.10 \
  --export /storage/nfs/data \
  --options "vers=4.2,soft,timeo=30,retrans=3,noac" \
  --content images,rootdir

pvesm add nfs nfs-ssd \
  --path /mnt/pve/nfs-ssd \
  --server 10.10.10.20 \
  --export /storage/ssd \
  --options "vers=4.2,soft,timeo=30,retrans=3,noac" \
  --content images,rootdir

⚠️ Важно: Старые storage пока работают. VM даже не заметят, что появилось что‑то новое.

Этап 3: «Миграция — это вам не миграция» — Переезд VM

3.1 План переезда одной ноды

bash

# 1. Выключаем HA (чтобы не убежала)
ha-manager set vm:101 --enabled 0

# 2. Отправляем VM в гости к соседям
qm migrate 101 prxmx-04 --online

# 3. На целевой ноде готовим конфиг
qm stop 101
qm set 101 --virtio0 nfs-data:101/vm-101-disk-1.qcow2
qm set 101 --ide0 nfs-data:101/vm-101-disk-0.qcow2
qm start 101

# 4. Возвращаем на место
qm migrate 101 prxmx-02 --online

3.2 Вариант: «А давайте выключим всё и переделаем» (метод доверия)

Когда работает: Если у вас есть окно обслуживания и вы доверяете своим конфигам.

bash

# 1. Выключаем ВСЕ VM на ноде
for vmid in $(qm list | awk 'NR>1 {print $1}'); do
    qm stop $vmid
done

# 2. Меняем storage для всех VM
for vmid in 101 102 103 104 105; do
    # Пример для VM с virtio дисками
    qm set $vmid --virtio0 nfs-data:$vmid/vm-$vmid-disk-0.qcow2
    # ... и так для всех дисков
done

# 3. Включаем обратно
for vmid in 101 102 103 104 105; do
    qm start $vmid
done

🛑 Глава: «Как мы чуть не убили VM 102 и почему unused — зло»

Живой пример из практики:

bash

# ❌ НЕ ДЕЛАЙТЕ ТАК! 
qm set 102 --delete unused0
# Результат: диск физически удалён, VM падает, восстановление из бэкапа

Почему так произошло? В некоторых версиях Proxmox команда qm set VMID --delete unusedN удаляет физический диск без возможности восстановления.

Правильный способ:

bash

# ✅ БЕЗОПАСНЫЙ вариант:
# 1. Отключаем старое хранилище в GUI
# Datacenter → Storage → выбрать data → Edit → отключить (Disable)

# 2. Теперь можно удалять unused записи
sed -i '/^unused[0-9]:/d' /etc/pve/nodes/$(hostname)/qemu-server/$vmid.conf

# 3. Storage data отключено, физический диск не удалится

Этап 4: «Генеральная уборка» — Отключение старого

После того как все VM перешли на новые storage:

bash

# 1. Отключаем старые монтирования
umount /store/nfs/data
umount /store/nfs/ssd
umount /store/nfs/iso

# 2. Чистим rc.local (убираем legacy)
sed -i '/mount -t nfs/d' /etc/rc.local

# 3. Отключаем старые storage в Proxmox
# В GUI: Datacenter → Storage → data → Edit → Disable
# Или через CLI:
pvesm set data --disable
pvesm set ssd --disable

Этап 5: «Чистка хвостов» — Удаление unused записей

bash

# Автоматическая очистка на всех нодах
for NODE in prxmx-01 prxmx-02 prxmx-03 prxmx-04; do
    echo "=== Нода: $NODE ==="
    ssh $NODE "for vmid in \$(qm list | awk 'NR>1 {print \$1}'); do
        if qm config \$vmid | grep -q unused; then
            echo \"  VM \$vmid - чистим...\"
            qm stop \$vmid
            sed -i '/^unused[0-9]:/d' /etc/pve/nodes/\$(hostname)/qemu-server/\$vmid.conf
            qm start \$vmid
        fi
    done"
done

📊 Итоговая таблица: Что было и что стало

Параметр

Было

Стало

Способ монтирования

/etc/rc.local

Proxmox Storage

Опции монтирования

hard,timeo=600

soft,timeo=30,noac

Поведение при падении NFS

Кластер зависает

Ноды живут, VM получают ошибку

Мониторинг

Ручной

Встроенный в PVE

Unused диски

Мусор в конфигах

Почищены

HA работа

Некорректная

Корректная

✅ Чек‑лист успешной миграции

  • Созданы новые storage с soft опциями

  • Все VM переведены на новые storage

  • Старые монтирования отключены

  • /etc/rc.local почищен

  • Unused записи удалены (безопасно!)

  • HA включен обратно

  • Тестовая перезагрузка ноды пройдена

  • Все VM запустились автоматически

🎯 Главные уроки

  1. Никогда не используйте hard монтирование для NFS в Proxmox — это верный способ убить кластер

  2. Сначала добавляем новые storage, потом мигрируем, потом удаляем старые — только так безопасно

  3. unused диски — это ловушка — в вашей версии Proxmox их удаление = удаление физического диска

  4. Всегда отключайте HA перед работой с VM — иначе они разбегутся по кластеру

«Если вы не тестируете свои бэкапы — считайте, что их нет. Если вы не тестируете перезагрузку ноды — считайте, что она не выживет. А если вы используете hard NFS — считайте, что у вас уже был даунтайм, просто вы ещё не знаете когда.» 😄