Разобьем задачу на составляющие: Как на WAN порт принять тегированный трафик и, сняв с него метку, раздать через bridge со всем маскарадингом итд?
ЗЫ Условие - на этот порт приходит еще несколько VLAN.

Скинь модель  QNAP.

TS-431

Может где то что-то упускаешь

Само собой. Но вот где? С одной стороны - обе ноды в кластере практически идентичны. И подключение должно происходить на уровне кластера. Но новая нода чего то не подсасывает и не может присоединить. На команду  iscsiadm -m node -l ALL - iscsiadm: No records found говорит. На попытку сканировать портал по IP - говорит "портал не обнаружен".

---

Updated: 08 September 2023, 14:51:05

---

Какая то вообще непонятная для меня е.б.о.л.а:

root@hv3:/etc/iscsi# iscsiadm -m discovery -t sendtargets -p 10.0.7.50:3260
iscsiadm: No portals found
root@hv3:/etc/iscsi# iscsiadm -m discovery
10.0.7.50:3260 via sendtargets
10.0.77.50:3260 via sendtargets

На первую команду - Типа портала не вижу
А на вторую выдает, что есть как бы два ресурса
Пытаюсь увидеть его с другой Windows машины - тоже не видит. Короче говоря ниоткуда не подключится. Я так подозреваю, что если от старой ноды его отключить - он уже обратно тоже не подключится.

Ввел в кластер новую ноду. Она подхватила все общие хранилища, кроме iSCSI-таргета поднятого на QNAP. Причем подключилось хранилище nfs на том же QNAP, но никак не присоединить iSCSI-target.
На старой ноде видно, что на нем лежит диск виртуалки в виде LUN, а на новой ноде - само хранилище как бы присутствует, но диска на нем нет. При попытке перемещения виртуальной машины на новую ноду (при условии что ее диск как бы лежит на этом iSCSI-t и переместить нужно только конфигурации) выдает ошибку:

07 08:10:43 starting migration of VM 102 to node 'hv3' (10.0.77.10)
 07 08:10:43 copying disk images
 07 08:10:43 starting VM 102 on remote node 'hv3'
 07 08:10:44 volume 'qnap:0.0.2.scsi-36e843b66d8944d7d5b06d4b0edb72dd2' does not exist
 07 08:10:44 ERROR: online migrate failure - command '/usr/bin/ssh -o 'BatchMode=yes' root@10.0.77.10 qm start 102 --skiplock --migratedfrom hv2 --migration_type secure --stateuri unix --machine pc-i440fx-2.9' failed: exit code 255
 07 08:10:44 aborting phase 2 - cleanup resources
 07 08:10:44 migrate_cancel
 07 08:10:45 ERROR: migration finished with problems (duration 00:00:03)
TASK ERROR: migration problems

На старой ноде это хранилище еще присутствует как два подключенных блочных устройства: типа в конце всех дисков присутствуют sdf1 и sdg1 размером 4Тб - размер таргета. На новой ноде таких устройств не видно.
На старой ноде командой pvesm iscsiscan --portal <ip_QNAP> - выдает длинное имя таргета, адреса и порты (типа мультипас)
На новой эта команда вообще не выполняется - выходит с ошибкой:

root@hv3:/dev/disk/by-id# pvesm iscsiscan --portal 10.0.77.50
iscsiadm: No portals found
command '/usr/bin/iscsiadm --mode discovery --type sendtargets --portal 10.0.77.50' failed: exit code 21

Если вбросить еще некоторое количество данных: то у QNAP два адреса на двух vlana'ах 10.0.7.50 и  10.0.77.50 - оба адреса пингуются с обеих нод и ноды по обоим вланам видят друг друга.

Основной вопрос: это ошибка авторизации на таргете? Ошибка синхронизации на новой ноде? Как так получается, что при одинаковых настройках файрвола (iptables на обоих нодах дефолтный) одна нода видит таргет, а вторая - нет?
 

Цитата: Gekko от 04 сентября 2023, 03:27:21

mirror.yandex.ru/debian/dists/jessie

http://archive.debian.org/debian/

Спасибо! Уже нашел. Нашел, установил openvswitch и успел положить сетевые интерфейы.
Хотел сделать бонд из двух интерфейсов и засунуть все в бридж. Назначил влани и тоже засунул их в бридж. Перезагрузил и... нихрена не применилось. Осталось все в interfaces.new. А interfaces вообще тал каким то дефолтным и пустым. Сейчас переименовал этот new в осровной - хотя бы доступ по ssh появился. Но вот web-морда proxmox пока так и не проявилась. Придется вс править из консоли.

ЗЫ Дополнение под конец рабочего дня: почему то в веб-интерфейсе настройки сети собрались через жопу. Пришлось все править вручную. Это великое счастье, что еще SSH всплыл, а то бы пришлось бегать - мама не горюй. Короче тупо открыл настройку сети в одной ноде и во второй, и тупо переписал параметры. Плюс под конец я сделал столько попыток законтачить две ноды и столько манипуляций со службами corosync и pve-cluster, что на подсоединяемой ноде пришлось тупо накатить apt instal proxmox-ve. И потом - бесчисленные попытки соединения с неоднократным перевыпуском ключей привели к тому, что при миграции VM с одной ноды на другую теперь ругается на несоответствие ключей.

сен 04 16:54:27 # /usr/bin/ssh -o 'BatchMode=yes' root@10.0.77.10 /bin/true
сен 04 16:54:27 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
сен 04 16:54:27 @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
сен 04 16:54:27 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
сен 04 16:54:27 IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
сен 04 16:54:27 Someone could be eavesdropping on you right now (man-in-the-middle attack)!
сен 04 16:54:27 It is also possible that a host key has just been changed.
сен 04 16:54:27 The fingerprint for the ECDSA key sent by the remote host is
сен 04 16:54:27 0c:fa:ab:27:6c:0a:f7:1d:a8:ad:68:11:1c:44:3f:17.
сен 04 16:54:27 Please contact your system administrator.
сен 04 16:54:27 Add correct host key in /root/.ssh/known_hosts to get rid of this message.
сен 04 16:54:27 Offending RSA key in /etc/ssh/ssh_known_hosts:31
сен 04 16:54:27   remove with: ssh-keygen -f "/etc/ssh/ssh_known_hosts" -R 10.0.77.10
сен 04 16:54:27 ECDSA host key for 10.0.77.10 has changed and you have requested strict checking.
сен 04 16:54:27 Host key verification failed.
сен 04 16:54:27 ERROR: migration aborted (duration 00:00:00): Can't connect to destination address using public key
TASK ERROR: migration aborted

Пришлось вручную удалять

ssh-keygen -f "/etc/ssh/ssh_known_hosts" -R 10.0.77.10

после чего миграция не работает с другой ошибкой:

сен 04 17:33:20 # /usr/bin/ssh -o 'BatchMode=yes' root@10.0.77.10 /bin/true
сен 04 17:33:20 Host key verification failed.
сен 04 17:33:20 ERROR: migration aborted (duration 00:00:01): Can't connect to destination address using public key
TASK ERROR: migration aborted

Что бы привести сертификаты в соответствие нужно зайти на проблемную ноду вручную по ssh^

ssh -o "HostKeyAlias=MyNode1" root@10.0.7.10

Насколько помню, RMM3 весьма древний модуль, когда я имел с ними дело, уже существовал RMM4, а это было давно. Лицензий, вроде, не требует, но сам может не входить в комплект и продаваться отдельно. Вроде, у него свой порт RJ45.
Если правильно вспоминаю, BMC даёт минимальное удалённое управление, типа вкл/выкл и т.п., а RMM - консоль.

Ога, спасибо. Немного почитал - так и есть. Свой порт у него, когда полноценный RMM. Тогда он отдельной такой платкой к задней панели прикручивается портом наружу. А если он RMM-lite, то втыкается в материнку и работает через BMC порт.
 Ну а на счет старости: что имеем - с тем и работаем.

Нет, ты не понял, да кластер можно из двух нод собирать это не запрещено, кворум не будет при двух нодах работать только при трех.

Дык я и говорю - теперь ты видел все: кластер из двух нод, в котором кластерные команды не выполняются по причине отсутствия кворума. 
То есть решение об исключении ноды невозможно принять в виду отсутствия кворума, то бишь - ноды.

Пытаюсь навесить удаленное управление на сервер Интел и немного запутался - есть настройка BMC и есть настройка RMM3. А в чем разница между тем и другим?
И второй вопрос - а через какие порты они работают? BMC - по идее работает через NIC-порт. А RMM3 - через что? Тоже через него? Где то читал, что настраивая оба варианта их нужно раскидать по разным подсетям.
И на задней панели есть какой то порт под RJ45 с обозначением "IOIOI" - это какой то консольный или для управления?
PS И еще вопрос RMM у Intel требует каких то лицензий, как iLO у HP, или он прямо из коробки работает?