Вот потому и "странные ответы". Чтобы натолкнуть человека на толковое формулирование задачи. А то пока есть ощущение попытки вытащить некое легаси из вмвари.

У меня тоже) Думаю, какую-то хуету задумал коллега. Потому и спросил)

Добрый день, опенстек задеплоин с помощью kolla-ansible и пробую на прямю вольюм подключит по iscsiadm, но получаю (iscsid)[root@compute1 /]# iscsiadm -m node -T iqn.2010-10.org.openstack:volume-b7153c6f-df87-4165-b974-911b4848f5ad -p 192.168.100.133 --login Logging in to [iface: default, target: iqn.2010-10.org.openstack:volume-b7153c6f-df87-4165-b974-911b4848f5ad, portal: 192.168.100.133,3260] iscsiadm: Could not login to [iface: default, target: iqn.2010-10.org.openstack:volume-b7153c6f-df87-4165-b974-911b4848f5ad, portal: 192.168.100.133,3260]. iscsiadm: initiator reported error (24 - iSCSI login failed due to authorization failure) iscsiadm: Could not log into all portals Никто не практиковал такое или подскажет, почему логин фейлится?

В базе синдера волюм посмотри - там есть поле provider_auth и в нем записан логин и пароль на таргет

Вопрос не тупой, но спросил не очень понятно, судя по ответам) Можно вот так: https://docs.openstack.org/nova/latest/cli/nova-serialproxy.html

Оу Ньютон, это какой год ?

Спасибо за ответ! Попробую покопать в эту сторону. Я пока что нашёл только вот такой вариант - https://docs.openstack.org/newton/user-guide/cli-access-instance-through-a-console.html Но, это не com-порт, само-собой.

А тебе для чего удаленный доступ к serial консоли?

Есть виртуалка, на ней крутится какой-то виртуальный роутер, который иногда требует (пере)настройки. У него есть mgmt0, понятное дело, но, если вдруг отвалился, или его испортили - надо как-то либо к локальной консоли (по аналогии с vmware) - напрямую присоединиться, либо к com-порту. Раньше это работало на kvm, там всё просто - либо virsh console, либо telnet на заранее перенаправленный порт. Теперь поднимают это же в openstack, хотелось бы понимать, можно ли сделать это с минимальными кастомизациями и, желательно, без двойной авторизации (сначала в openstack - потом в самой vm).

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

Да, но тогда авторизация на openstack делаться будет, а это дополнительный геморрой - не технический, организационный.

А как ты без авторизации хочешь доступ получать?

в идеале - чтобы была только внутренняя авторизация самой виртуалки. Ну и да, роутер плюётся и в графическую консоль и в com-порт.

И какой там организационный геморрой то?)

я не думаю, что команду, которая админит роутер впустят в кишки опенстака :).

Ну вот. Этого и не дадут сделать, скорее всего.

Зачем в кишки? Через политики или app credentials команде сетевиков можно оставить минимум прав

А в браузере открыть novnc консоль тоже не дадут?)

Я думаю, сам факт локального логина по ssh вызовет паранойю. Тем более, если надо будет что-то крутить, чтобы virsh заработал для их юзера. А если ещё и виртуалка мигрирует между compute хостами - ещё сложнее становится.

Но в целом ясно. Тоталитаризм, безопасники судаки и могут только бумажки, а операторы облака или не знают как сделать или не могут из-за безопасной безопасности)

Тебе не надо никуда логиниться. Тебе надо как обычному пользователю через api или консольным клиентом получить ссылку на novnc консоль и дальше в браузере ее открыть.

Ну вот, чтобы ссылку получить - надо же для начала пройти авторизацию в самом openstack, я же правильно понимаю?

Да. Но там же гибкие политики и можно пользователю вообще все запретить кроме получения ссылки на консоль.

Ну, значит, если нет других вариантов - остаётся этот. А он, кстати, только на гуёвую консоль умеет редиректить, или на com-порт тоже?

Ссылка на serial консоль будет через websocket. Нужна какая-то реализация websocket клиента, как в ссылке что я кидал. Терминальным эмулятором напрямую по ней не цепанешься. Смотри. Вот про app credentials: https://docs.openstack.org/keystone/latest/user/application_credentials.html Можно сгенерировать себе типа промежуточный токен, не давая доступ к пользователю в опенстеке напрямую. И через access rules разрешить только получать доступ к консолям. https://docs.openstack.org/api-ref/compute/#get-serial-console-os-getserialconsole-action-deprecated https://docs.openstack.org/api-ref/compute/?expanded=get-serial-console-os-getserialconsole-action-deprecated-detail,create-console-detail#create-console

Ссылка на serial консоль будет через websocket. Нужна какая-то реализация websocket клиента, как в ссылке что я кидал. Терминальным эмулятором напрямую по ней не цепанешься. Смотри. Вот про app credentials: https://docs.openstack.org/keystone/latest/user/application_credentials.html Можно сгенерировать себе типа промежуточный токен, не давая доступ к пользователю в опенстеке напрямую. И через access rules разрешить только получать доступ к консолям. https://docs.openstack.org/api-ref/compute/#get-serial-console-os-getserialconsole-action-deprecated https://docs.openstack.org/api-ref/compute/?expanded=get-serial-console-os-getserialconsole-action-deprecated-detail,create-console-detail#create-console

Ссылка на serial консоль будет через websocket. Нужна какая-то реализация websocket клиента, как в ссылке что я кидал. Терминальным эмулятором напрямую по ней не цепанешься. Смотри. Вот про app credentials: https://docs.openstack.org/keystone/latest/user/application_credentials.html Можно сгенерировать себе типа промежуточный токен, не давая доступ к пользователю в опенстеке напрямую. И через access rules разрешить только получать доступ к консолям. https://docs.openstack.org/api-ref/compute/#get-serial-console-os-getserialconsole-action-deprecated https://docs.openstack.org/api-ref/compute/?expanded=get-serial-console-os-getserialconsole-action-deprecated-detail,create-console-detail#create-console

Ох. Надеюсь, им будет хватать гуёвой консоли...

Я же тебе вот, сообщением выше скинул реализацию клиента)

Да это понятно, я просто хочу обойтись минимальным количеством сущностей. Хрен его знает, откуда они будут пытаться ломиться на эту консоль и с какими локальными правами... Как бы то ни было - спасибо за наводку :)

virsh console с гипервизора так и продолжает работать, пользуйтесь ею, если нравится

virsh console с гипервизора так и продолжает работать, пользуйтесь ею, если нравится

А что делает параметр OS-DCF:diskConfig под капотом? https://docs.openstack.org/api-ref/compute/?expanded=create-server-detail#:~:text=255%20bytes%20each.-,OS%2DDCF%3AdiskConfig,-(Optional) По описанию всё понятно, но как то это работать не хочет. Логически должно в клауд-инит добавлять growpart: mode: off. Если руками в юзер_дату пишу,то всё нормально. И в коде не могу найти, на что это влияет. Со стороны АПИ всё понятно, этот параметр берётся, добавляется и.т.д. а вот со стороны конечного исполнения не вижу, на что виляет.

Могу ошибаться монтирует /dev/sr0

Это конфиг_драйв его монтирует :)

Если у тебя нет dhcp конфиг драйв например настроит тебе сеть

А что делает параметр OS-DCF:diskConfig под капотом? https://docs.openstack.org/api-ref/compute/?expanded=create-server-detail#:~:text=255%20bytes%20each.-,OS%2DDCF%3AdiskConfig,-(Optional) По описанию всё понятно, но как то это работать не хочет. Логически должно в клауд-инит добавлять growpart: mode: off. Если руками в юзер_дату пишу,то всё нормально. И в коде не могу найти, на что это влияет. Со стороны АПИ всё понятно, этот параметр берётся, добавляется и.т.д. а вот со стороны конечного исполнения не вижу, на что виляет.

Это не для локальных ли дисков опция

создай вольюм из image с опцие и без, потом подцепи и посмотри что внутри полйчаетс

зззздрасьте)

В ней нет проблем с опенстаком? 😂

как то диск нужно готовить при добавлении в OSD ?