Тема: PVE 8.4.1 Single Node: Persistent Ghost Node & VMs После Восстановления – Невозможно Переиспользовать ID (Подробное Описание Предпринятых Шагов)
Приветствую сообщество Proxmox,
Обращаюсь за помощью с упрямым несоответствием состояния пользовательского интерфейса на одном узле Proxmox VE 8.4.1 (используется репозиторий pve-no-subscription). После восстановления из критического повреждения /etc/pve я остался с "призрачными" записями, которые не позволяют мне переиспользовать мои оригинальные ID виртуальных машин, несмотря на обшижную отладку.
**Изначальная ситуация и восстановление:**
Хост (Cloud9.Proxmox.10) испытал критическую ошибку, при которой /etc/pve (управляемый pmxcfs) был поврежден и не монтировался. Восстановление включало остановку служб PVE, перемещение поврежденного /etc/pve в сторону, создание нового пустого /etc/pve и использование чистой /var/lib/pve-cluster/config.db (оригинальные и резервные копии также были непригодны). Это успешно запустило pmxcfs и основные службы.
**Решенные вторичные проблемы:**
* **Внутренние ошибки Cert 596:** Постоянные ошибки проверки сертификата (596) были устранены путем запуска `sudo pvecm updatecerts --force`. (Примечание: /usr/sbin/pvekey файл, похоже, отсутствует в пакетах 8.4.1, но команда сработала).
* **Внешний HTTPS:** Обеспечен доступ через путем копирования сертификатов Let's Encrypt в /etc/pve/nodes/Cloud9/pveproxy-ssl.\* и использования записи в /etc/hosts для клиента.
* **Подключение PBS:** Изначальные ошибки "Network Unreachable" при подключении к PBS были исправлены путем отключения проксирования Cloudflare для хоста PBS.
* **Видимость хранилища:** Объём ZFS хранилища данных (rpool/data) изначально не был доступен в пользовательском интерфейсе. Это было исправлено путем удаления ( `sudo pvesm remove data`) и повторного добавления ( `sudo pvesm add zfspool data ...`) определения хранилища через командную строку.
* **Сбой создания снимков:** Ошибки "Out of space" при создании снимков были устранены путем удаления ненужных ZFS резерваций с томов дисков виртуальных машин (`sudo zfs set refreservation=none ...`).
**Восстановление виртуальных машин:**
ВМ 111 и 112 были успешно восстановлены из резервных копий PBS с использованием новых ID (9111, 9112) сначала на локальное хранилище, а затем перемещены в хранилище данных, когда оно стало доступно. Эти ВМ работают корректно.
**Существующая проблема:**
Несмотря на решение вышеперечисленных проблем, пользовательский интерфейс остается непоследовательным:
* Дерево пользовательского интерфейса отображает две записи узлов:
* **Cloud9** (Заглавная C): Правильный, активный узел, содержащий работающие ВМ 9111 и 9112 и правильно настроенное хранилище.
* **cloud9** (Строчная c): "Призрачная" запись узла, вероятно, из состояния до повреждения.
* Под "призрачной" записью узла cloud9 пользовательский интерфейс перечисляет оригинальные ВМ: 111, 112, 178. Эти "призрачные" ВМ не существуют: их .conf файлы подтверждено удалены из /etc/pve/nodes/Cloud9/qemu-server/. `sudo qm list` отображает только активные ВМ (9111, 9112). Файл /etc/pve/.vmlist на системе отсутствует.
**Влияние на функциональность:**
Система ошибочно полагает, что ID 111 и 112 все еще в использовании из-за этих "призрачных" записей. Я не могу переименовать мои активные ВМ (9111, 9112) обратно в их оригинальные, желаемые ID (111, 112). Попытка восстановления с использованием этих ID также не удается.
**Предприняты исчерпывающие шаги по устранению неполадок (специфичные для "призраков" - после исправления 596):**
* Многократные перезапуски pve-cluster, pvedaemon, pveproxy.
* Полная перезагрузка хоста.
* Расширенная очистка кэша/хранилища браузера (жесткая перезагрузка, приватные окна, очистка данных сайта через инструменты разработчика).
* Подтверждено удаление .conf файлов "призрачных" ВМ.
* Подтверждено, что вывод `qm list` корректен.
* Попытка сбросить состояние кластера путем удаления /etc/pve/.clusterlog и /etc/pve/.version и перезапуска служб.
* Проверена наличие файла /etc/pve/.vmlist (подтверждено отсутствие, поэтому нельзя отредактировать).
* Вынуждены пересканировать хранилище (`pvesm scan zfs`) и повторно добавить определение хранилища.
* Проверены разрешения ZFS (`zfs allow -u www-data ...`).
* Осуществлен поиск любых остаточных файлов, содержащих ID "призрачных" ВМ, используя `find /etc/pve/nodes/Cloud9/ -type f \( -name "*111*" ... \)`. Ничего не найдено, кроме (уже удаленных) конфигураций активных ВМ в течение короткого периода.
* Проверены недавние логи служб PVE (journalctl) - нет очевидных ошибок, связанных с несоответствием состояния после исправления 596.
**Запрос на помощь экспертов:**
Похоже, что мы исчерпали стандартные шаги по устранению неполадок для очистки несоответствующего состояния пользовательского интерфейса. Поскольку "призрачный" узел и ВМ сохраняются и предотвращают переиспользование оригинальных ID ВМ:
* Существует ли еще какой-нибудь кэш, индексный файл или запись в базе данных в системе Proxmox (помимо .vmlist), которые могут хранить эту устаревшую информацию об узле/ВМ?
* Существуют ли какие-либо команды `pvesh` или другие инструменты низкого уровня, которые можно использовать для принудительного запроса и потенциально очистки этих конкретных "призрачных" записей из внутреннего состояния кластера?
* Может ли это быть известная ошибка в PVE 8.4.1, связанная с переименованием узла или восстановлением из повреждения, которая требует специального обходного пути или исправления?
* Можете ли вы предоставить какие-либо рекомендации по более продвинутым методам для окончательной очистки этих "призрачных" записей и разрешения переиспользования ID ВМ?
Спасибо за ваше время и опыт!
Приветствую сообщество Proxmox,
Обращаюсь за помощью с упрямым несоответствием состояния пользовательского интерфейса на одном узле Proxmox VE 8.4.1 (используется репозиторий pve-no-subscription). После восстановления из критического повреждения /etc/pve я остался с "призрачными" записями, которые не позволяют мне переиспользовать мои оригинальные ID виртуальных машин, несмотря на обшижную отладку.
**Изначальная ситуация и восстановление:**
Хост (Cloud9.Proxmox.10) испытал критическую ошибку, при которой /etc/pve (управляемый pmxcfs) был поврежден и не монтировался. Восстановление включало остановку служб PVE, перемещение поврежденного /etc/pve в сторону, создание нового пустого /etc/pve и использование чистой /var/lib/pve-cluster/config.db (оригинальные и резервные копии также были непригодны). Это успешно запустило pmxcfs и основные службы.
**Решенные вторичные проблемы:**
* **Внутренние ошибки Cert 596:** Постоянные ошибки проверки сертификата (596) были устранены путем запуска `sudo pvecm updatecerts --force`. (Примечание: /usr/sbin/pvekey файл, похоже, отсутствует в пакетах 8.4.1, но команда сработала).
* **Внешний HTTPS:** Обеспечен доступ через путем копирования сертификатов Let's Encrypt в /etc/pve/nodes/Cloud9/pveproxy-ssl.\* и использования записи в /etc/hosts для клиента.
* **Подключение PBS:** Изначальные ошибки "Network Unreachable" при подключении к PBS были исправлены путем отключения проксирования Cloudflare для хоста PBS.
* **Видимость хранилища:** Объём ZFS хранилища данных (rpool/data) изначально не был доступен в пользовательском интерфейсе. Это было исправлено путем удаления ( `sudo pvesm remove data`) и повторного добавления ( `sudo pvesm add zfspool data ...`) определения хранилища через командную строку.
* **Сбой создания снимков:** Ошибки "Out of space" при создании снимков были устранены путем удаления ненужных ZFS резерваций с томов дисков виртуальных машин (`sudo zfs set refreservation=none ...`).
**Восстановление виртуальных машин:**
ВМ 111 и 112 были успешно восстановлены из резервных копий PBS с использованием новых ID (9111, 9112) сначала на локальное хранилище, а затем перемещены в хранилище данных, когда оно стало доступно. Эти ВМ работают корректно.
**Существующая проблема:**
Несмотря на решение вышеперечисленных проблем, пользовательский интерфейс остается непоследовательным:
* Дерево пользовательского интерфейса отображает две записи узлов:
* **Cloud9** (Заглавная C): Правильный, активный узел, содержащий работающие ВМ 9111 и 9112 и правильно настроенное хранилище.
* **cloud9** (Строчная c): "Призрачная" запись узла, вероятно, из состояния до повреждения.
* Под "призрачной" записью узла cloud9 пользовательский интерфейс перечисляет оригинальные ВМ: 111, 112, 178. Эти "призрачные" ВМ не существуют: их .conf файлы подтверждено удалены из /etc/pve/nodes/Cloud9/qemu-server/. `sudo qm list` отображает только активные ВМ (9111, 9112). Файл /etc/pve/.vmlist на системе отсутствует.
**Влияние на функциональность:**
Система ошибочно полагает, что ID 111 и 112 все еще в использовании из-за этих "призрачных" записей. Я не могу переименовать мои активные ВМ (9111, 9112) обратно в их оригинальные, желаемые ID (111, 112). Попытка восстановления с использованием этих ID также не удается.
**Предприняты исчерпывающие шаги по устранению неполадок (специфичные для "призраков" - после исправления 596):**
* Многократные перезапуски pve-cluster, pvedaemon, pveproxy.
* Полная перезагрузка хоста.
* Расширенная очистка кэша/хранилища браузера (жесткая перезагрузка, приватные окна, очистка данных сайта через инструменты разработчика).
* Подтверждено удаление .conf файлов "призрачных" ВМ.
* Подтверждено, что вывод `qm list` корректен.
* Попытка сбросить состояние кластера путем удаления /etc/pve/.clusterlog и /etc/pve/.version и перезапуска служб.
* Проверена наличие файла /etc/pve/.vmlist (подтверждено отсутствие, поэтому нельзя отредактировать).
* Вынуждены пересканировать хранилище (`pvesm scan zfs`) и повторно добавить определение хранилища.
* Проверены разрешения ZFS (`zfs allow -u www-data ...`).
* Осуществлен поиск любых остаточных файлов, содержащих ID "призрачных" ВМ, используя `find /etc/pve/nodes/Cloud9/ -type f \( -name "*111*" ... \)`. Ничего не найдено, кроме (уже удаленных) конфигураций активных ВМ в течение короткого периода.
* Проверены недавние логи служб PVE (journalctl) - нет очевидных ошибок, связанных с несоответствием состояния после исправления 596.
**Запрос на помощь экспертов:**
Похоже, что мы исчерпали стандартные шаги по устранению неполадок для очистки несоответствующего состояния пользовательского интерфейса. Поскольку "призрачный" узел и ВМ сохраняются и предотвращают переиспользование оригинальных ID ВМ:
* Существует ли еще какой-нибудь кэш, индексный файл или запись в базе данных в системе Proxmox (помимо .vmlist), которые могут хранить эту устаревшую информацию об узле/ВМ?
* Существуют ли какие-либо команды `pvesh` или другие инструменты низкого уровня, которые можно использовать для принудительного запроса и потенциально очистки этих конкретных "призрачных" записей из внутреннего состояния кластера?
* Может ли это быть известная ошибка в PVE 8.4.1, связанная с переименованием узла или восстановлением из повреждения, которая требует специального обходного пути или исправления?
* Можете ли вы предоставить какие-либо рекомендации по более продвинутым методам для окончательной очистки этих "призрачных" записей и разрешения переиспользования ID ВМ?
Спасибо за ваше время и опыт!
