Просто возвращаюсь к этому вопросу... Это всё ещё проблема, и мне трудно разобраться, как её решить. Я долгое время прихрамывал, но мне нужно добавить 5 новых узлов, и я хочу убедиться, что это будет решено, прежде чем я это сделаю. На данный момент 5 узлов находятся в различных состояниях. Есть ли способ исправить это, не убивая активную среду? Могу ли я восстановить ключи? Возможно, стоит упомянуть, что я также запускаю CEPH на всех этих узлах. (если это важно). Буду признателен за любую помощь. Спасибо, Дэн.

Больше информации... На одном узле "сломленного кластера" я удалил "известные хосты" в локальной папке ssh. Затем я выполнил живую миграцию виртуальной машины с одного узла на этот узел. Это прошло успешно. После этого я попыталсяlive мигрировать обратно на оригинальный узел, но это не удалось. После восстановления "известных хостов" в локальной папке ssh я снова смог успешно мигрировать виртуальную машину обратно. Так что, похоже, в моем случае живая миграция зависит от файла известных хостов в локальной папке ssh для моего сломленного кластера. В работающем кластере в этой папке нет файлов "известных хостов". Добавлю, что я использую выделенный интерфейс миграции в сломанном кластере, а в рабочем кластере его нет, если это имеет значение. Как же мне это исправить? Спасибо! Дан

Больше информации: Я все еще не понимаю, почему это произошло... но теперь я подозреваю, что это связано с тем, что, похоже, нет никакой SSH-связи для сети выделенного кластера? Запуск на моей сети выделенного кластера (по умолчанию) (НЕУДАЧА): Код: # /usr/bin/ssh -v -o 'BatchMode=yes' root@192.X.X.X /bin/true OpenSSH_6.7p1 Debian-5+deb8u4, OpenSSL 1.0.1t 3 мая 2016 debug1: Чтение конфигурационных данных /root/.ssh/config debug1: Чтение конфигурационных данных /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config строка 19: Применение опций для * debug1: Подключение к 192.X.X.X [192.X.X.X] порт 22. debug1: Соединение установлено. debug1: permanently_set_uid: 0/0 debug1: файл идентификации /root/.ssh/id_rsa type 1 debug1: key_load_public: Нет такого файла или каталога debug1: файл идентификации /root/.ssh/id_rsa-cert type -1 debug1: key_load_public: Нет такого файла или каталога debug1: файл идентификации /root/.ssh/id_dsa type -1 debug1: key_load_public: Нет такого файла или каталога debug1: файл идентификации /root/.ssh/id_dsa-cert type -1 debug1: key_load_public: Нет такого файла или каталога debug1: файл идентификации /root/.ssh/id_ecdsa type -1 debug1: key_load_public: Нет такого файла или каталога debug1: файл идентификации /root/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: Нет такого файла или каталога debug1: файл идентификации /root/.ssh/id_ed25519 type -1 debug1: key_load_public: Нет такого файла или каталога debug1: файл идентификации /root/.ssh/id_ed25519-cert type -1 debug1: Включение兼容性 режима для протокола 2.0 debug1: Локальная строка версии SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u4 debug1: Версия удаленного протокола 2.0, версия удаленного ПО OpenSSH_6.7p1 Debian-5+deb8u4 debug1: совпадение: OpenSSH_6.7p1 Debian-5+deb8u4 pat OpenSSH* compat 0x04000000 debug1: SSH2_MSG_KEXINIT отправлено debug1: SSH2_MSG_KEXINIT получено debug1: kex: сервер->клиент aes128-ctr umac-64-etm@openssh.com none debug1: kex: клиент->сервер aes128-ctr umac-64-etm@openssh.com none debug1: отправка SSH2_MSG_KEX_ECDH_INIT debug1: ожидание SSH2_MSG_KEX_ECDH_REPLY debug1: Ключ хоста сервера: ECDSA BLAH BLAH BLAH Проверка ключа хоста не удалась. Запуск на сети ВМ (УСПЕШНО): Код: # /usr/bin/ssh -v -o 'BatchMode=yes' root@10.X.X.X /bin/true OpenSSH_6.7p1 Debian-5+deb8u4, OpenSSL 1.0.1t 3 мая 2016 debug1: Чтение конфигурационных данных /root/.ssh/config debug1: Чтение конфигурационных данных /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config строка 19: Применение опций для * debug1: Подключение к 10.X.X.X [10.X.X.X] порт 22. debug1: Соединение установлено. debug1: permanently_set_uid: 0/0 debug1: файл идентификации /root/.ssh/id_rsa type 1 debug1: key_load_public: Нет такого файла или каталога debug1: файл идентификации /root/.ssh/id_rsa-cert type -1 debug1: key_load_public: Нет такого файла или каталога debug1: файл идентификации /root/.ssh/id_dsa type -1 debug1: key_load_public: Нет такого файла или каталога debug1: файл идентификации /root/.ssh/id_dsa-cert type -1 debug1: key_load_public: Нет такого файла или каталога debug1: файл идентификации /root/.ssh/id_ecdsa type -1 debug1: key_load_public: Нет такого файла или каталога debug1: файл идентификации /root/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: Нет такого файла или каталога debug1: файл идентификации /root/.ssh/id_ed25519 type -1 debug1: key_load_public: Нет такого файла или каталога debug1: файл идентификации /root/.ssh/id_ed25519-cert type -1 debug1: Включение兼容性 режима для протокола 2.0 debug1: Локальная строка версии SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u4 debug1: Версия удаленного протокола 2.0, версия удаленного ПО OpenSSH_6.7p1 Debian-5+deb8u4 debug1: совпадение: OpenSSH_6.7p1 Debian-5+deb8u4 pat OpenSSH* compat 0x04000000 debug1: SSH2_MSG_KEXINIT отправлено debug1: SSH2_MSG_KEXINIT получено debug1: kex: сервер->клиент aes128-ctr umac-64-etm@openssh.com none debug1: kex: клиент->сервер aes128-ctr umac-64-etm@openssh.com none debug1: отправка SSH2_MSG_KEX_ECDH_INIT debug1: ожидание SSH2_MSG_KEX_ECDH_REPLY debug1: Ключ хоста сервера: RSA BLAH BLAH BLAH debug1: Хост '10.X.X.X' известен и соответствует RSA ключу хоста. debug1: Найден ключ в /etc/ssh/ssh_known_hosts:8 debug1: SSH2_MSG_NEWKEYS отправлено debug1: ожидание SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS получено debug1: SSH2_MSG_SERVICE_REQUEST отправлено debug1: SSH2_MSG_SERVICE_ACCEPT получено debug1: Методы аутентификации, которые могут продолжаться: publickey, password debug1: Следующий метод аутентификации: publickey debug1: Предложение RSA публичного ключа: /root/.ssh/id_rsa debug1: Сервер принимает ключ: pkalg ssh-rsa blen 279 debug1: Аутентификация прошла успешно (publickey). Аутентифицирован до 10.X.X.X ([10.X.X.X]:22). debug1: канал 0: новый [client-session] debug1: Запрос no-more-sessions@openssh.com debug1: Вход в интерактивную сессию. debug1: Отправка окружения. debug1: Отправка env LANG = en_US.UTF-8 debug1: Отправка команды: /bin/true debug1: client_input_channel_req: канал 0 rtype exit-status ответ 0 debug1: client_input_channel_req: канал 0 rtype eow@openssh.com ответ 0 debug1: канал 0: свободен: client-session, nchannels 1 Передано: отправлено 3056, получено 2164 байт, за 0.0 секунды Байты в секунду: отправлено 694091.8, получено 491496.9 debug1: Статус выхода 0 Чтобы было понятно, если я SSH с хоста, с которого хочу мигрировать, на хост, на который хочу мигрировать, и принимаю запись ECDSA ключа (что добавляет ключ в файл known_hosts в ~/.ssh/known_hosts), миграция сработает на выделенном кластере. Похоже, что ключ ECDSA должен быть добавлен в кластерный /etc/pve/priv/known_hosts... но, похоже, этого не происходит. Я следовал этому руководству для настройки сети выделенного кластера: https://pve.proxmox.com/wiki/Separate_Cluster_Network Теперь что? <D>

Итак, вот краткий обзор того, где я сейчас нахожусь: я создал оригинальный кластер, следуя инструкциям Proxmox, с одним диапазоном IP. После дополнительных исследований я узнал, что Proxmox рекомендует отдельную сеть кластера, так что я следовал их инструкциям, чтобы настроить corosync на втором диапазоне IP. После этого изменения я обнаружил, что миграция не работает. После некоторых расследований я выяснил, что проверка SSH-хоста была нарушена. Погрузившись в проблему глубже, я пришел к выводу, что самое простое решение — создать новый ssh_known_hosts в /etc/pve/priv с новыми IP-адресами. Похоже, что у Proxmox (по крайней мере, на момент создания и настройки моей среды около года назад) нет механизма или документации для аккуратного обновления clustered know_hosts при переходе на выделенную кластерную или миграционную среду. Не знаю, так ли это до сих пор, но теперь, когда я полностью понимаю проблему, я добавлю еще 5 узлов в свой кластер и дам знать, если это все еще актуально. Если да, открою тикет. Всего хорошего, <D>