Grundik
openstack network show ID | grep -E 'provider:'
Alexander
openstack network show ID | grep -E 'provider:'
openstack network show public | grep -E 'provider:'
| provider:network_type | vlan |
| provider:physical_network | physnet1 |
| provider:segmentation_id | 40 |
Grundik
сеть правильно заведена вроде
Alexander
создавал так
openstack network create --provider-network-type vlan \
--provider-physical-network physnet1 \
--provider-segment 40 \
--external \
--share \
public
Alexander
на controller и compute есть системные интерфейсы в 40м vlan-е типа
17: cl-hpv-public@lan-bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 2c:76:8a:54:2c:f7 brd ff:ff:ff:ff:ff:ff
inet 192.168.142.46/24 brd 192.168.142.255 scope global noprefixroute cl-hpv-public
valid_lft forever preferred_lft forever
Alexander
на роутере из этой же подсети 192.168.142.1, на ВМ 192.168.142.126
NS 🇷🇺
на роутере из этой же подсети 192.168.142.1, на ВМ 192.168.142.126
а роутер стоит где то в инфе, не сущность в опенстеке?
NS 🇷🇺
не сущность. аппаратный
в сек группах тогда пинги разреши, я в каком то релизе сталкивался с такой херней
Alexander
на controller и compute есть системные интерфейсы в 40м vlan-е типа
17: cl-hpv-public@lan-bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 2c:76:8a:54:2c:f7 brd ff:ff:ff:ff:ff:ff
inet 192.168.142.46/24 brd 192.168.142.255 scope global noprefixroute cl-hpv-public
valid_lft forever preferred_lft forever
через него сижу по ssh на controller и compute
NS 🇷🇺
чисто для проверки
Alexander
в сек группах тогда пинги разреши, я в каком то релизе сталкивался с такой херней
вроде есть
openstack security group rule list 5336c39c-7f66-4a2c-a43b-13c1e53abd56
+--------------------------------------+-------------+-----------+-----------+------------+-----------+--------------------------------------+----------------------+
| ID | IP Protocol | Ethertype | IP Range | Port Range | Direction | Remote Security Group | Remote Address Group |
+--------------------------------------+-------------+-----------+-----------+------------+-----------+--------------------------------------+----------------------+
| 1f745439-3f68-487f-b4a5-39d93fb1ee4d | tcp | IPv4 | 0.0.0.0/0 | 8000:8000 | ingress | None | None |
| 2d151041-d76d-4896-82b0-dfa8f0f1badd | None | IPv4 | 0.0.0.0/0 | | ingress | 5336c39c-7f66-4a2c-a43b-13c1e53abd56 | None |
| 3809a882-dc02-407b-8a67-51cb6aa6060d | None | IPv6 | ::/0 | | ingress | 5336c39c-7f66-4a2c-a43b-13c1e53abd56 | None |
| 55e08995-b85e-43bc-8c00-3fb4b4471c5f | tcp | IPv4 | 0.0.0.0/0 | 8080:8080 | ingress | None | None |
| 62819be4-ddb8-4645-84c2-145f1f3c480f | tcp | IPv4 | 0.0.0.0/0 | 22:22 | ingress | None | None |
| 92536936-2185-4026-8c12-25f986c6996d | None | IPv6 | ::/0 | | egress | None | None |
| a1d7d416-a8e3-433d-a255-2469d49d37c6 | icmp | IPv4 | 0.0.0.0/0 | | ingress | None | None |
| bfff0817-8ece-40dd-bfc9-eb13ebee8082 | None | IPv4 | 0.0.0.0/0 | | egress | None | None |
+--------------------------------------+-------------+-----------+-----------+------------+-----------+--------------------------------------+----------------------+
Grundik
вм создана на какой сети? на
public?
Grundik
ересь)
Grundik
external сеть не для вм)
Alexander
external сеть не для вм)
какая для ВМ? чтобы ВМ разместить в физической сети в каком ниб vlan-е?
в голове еще не нарисовалась принципиальная картина ovs решения, поэтому пока творожу
NS 🇷🇺
какая для ВМ? чтобы ВМ разместить в физической сети в каком ниб vlan-е?
в голове еще не нарисовалась принципиальная картина ovs решения, поэтому пока творожу
да просто паблик с шаред убери, или хотя бы просто паблик.
NS 🇷🇺
но это опять таки не должно повлиять на проблему
Alexander
да просто паблик с шаред убери, или хотя бы просто паблик.
сейчас так, но ничего не изменилось
openstack network show public
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
| admin_state_up | UP |
| availability_zone_hints | |
| availability_zones | nova |
| created_at | 2025-03-31T09:10:47Z |
| description | |
| dns_domain | None |
| id | 96503d11-0619-4cc4-a034-be1b7ab25f78 |
| ipv4_address_scope | None |
| ipv6_address_scope | None |
| is_default | False |
| is_vlan_qinq | None |
| is_vlan_transparent | None |
| mtu | 1500 |
| name | public |
| port_security_enabled | True |
| project_id | fc62ab838b57404886155fccb725c311 |
| provider:network_type | vlan |
| provider:physical_network | physnet1 |
| provider:segmentation_id | 40 |
| qos_policy_id | None |
| revision_number | 3 |
| router:external | External |
| segments | None |
| shared | False |
| status | ACTIVE |
| subnets | 1563adf4-c4db-47fc-b04d-1c456805e6a8 |
| tags | |
| updated_at | 2025-04-01T14:55:24Z |
+---------------------------+--------------------------------------+
Alexander
может тут что не так?
cat /etc/kolla/neutron-server/ml2_conf.ini
[ml2]
type_drivers = flat,vlan,vxlan
tenant_network_types = vxlan
mechanism_drivers = openvswitch,l2population
extension_drivers = port_security
[ml2_type_vlan]
network_vlan_ranges = physnet1:1:4094
[ml2_type_flat]
flat_networks = *
[ml2_type_vxlan]
vni_ranges = 1:1000
Grundik
создай еще одну вм, между 2мя вм будут пинги?
NS 🇷🇺
сейчас так, но ничего не изменилось
openstack network show public
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
| admin_state_up | UP |
| availability_zone_hints | |
| availability_zones | nova |
| created_at | 2025-03-31T09:10:47Z |
| description | |
| dns_domain | None |
| id | 96503d11-0619-4cc4-a034-be1b7ab25f78 |
| ipv4_address_scope | None |
| ipv6_address_scope | None |
| is_default | False |
| is_vlan_qinq | None |
| is_vlan_transparent | None |
| mtu | 1500 |
| name | public |
| port_security_enabled | True |
| project_id | fc62ab838b57404886155fccb725c311 |
| provider:network_type | vlan |
| provider:physical_network | physnet1 |
| provider:segmentation_id | 40 |
| qos_policy_id | None |
| revision_number | 3 |
| router:external | External |
| segments | None |
| shared | False |
| status | ACTIVE |
| subnets | 1563adf4-c4db-47fc-b04d-1c456805e6a8 |
| tags | |
| updated_at | 2025-04-01T14:55:24Z |
+---------------------------+--------------------------------------+
ну я и сказал, что это не повлияет на проблему ... это больше для спокойствия тех, кому не приходилось говно системы проектировать :D
Alexander
создай еще одну вм, между 2мя вм будут пинги?
да, пингуются. но по dhcp не получают IP, статикой назначил
Grundik
а где dhcp агенты?
Grundik
ну и сразу вопрос а для сабнета dhcp включен?
Alexander
а где dhcp агенты?
похоже на controler
(kolla-venv) [root@cl-cntrl ~]# docker ps|grep dhcp
1fa3623ce51f quay.io/openstack.kolla/neutron-dhcp-agent:master-rocky-9 "dumb-init --single-…" 5 days ago Up 5 days (healthy) neutron_dhcp_agent
Grundik
на контроллеры тоже подан влан этот?
Alexander
ну и сразу вопрос а для сабнета dhcp включен?
Илья | 😶☮️🐸
Смотрите tcpdump, гадание в чате не привнесет никаких результатов
Илья | 😶☮️🐸
Важно помнить, dhcp крутится в своём неймспейсе (ip netns)
Alexander
единственно смущает статус DOWN ovs интерфейсов на compute и controller
8: lan-bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master ovs-system state UP group default qlen 1000
link/ether d8:5e:d3:41:86:20 brd ff:ff:ff:ff:ff:ff
13: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether c6:a7:1e:11:5d:c4 brd ff:ff:ff:ff:ff:ff
14: br-tun: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 36:2c:91:96:40:4e brd ff:ff:ff:ff:ff:ff
15: br-ex: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether d8:5e:d3:41:86:20 brd ff:ff:ff:ff:ff:ff
16: br-int: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 66:16:e5:1a:10:42 brd ff:ff:ff:ff:ff:ff
20: qbrfef02bf7-d6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether d2:bc:de:e8:3c:a1 brd ff:ff:ff:ff:ff:ff
21: qvofef02bf7-d6@qvbfef02bf7-d6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master ovs-system state UP group default qlen 1000
link/ether 22:54:fc:6a:ea:f9 brd ff:ff:ff:ff:ff:ff
inet6 fe80::2054:fcff:fe6a:eaf9/64 scope link
valid_lft forever preferred_lft forever
22: qvbfef02bf7-d6@qvofef02bf7-d6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master qbrfef02bf7-d6 state UP group default qlen 1000
link/ether d2:bc:de:e8:3c:a1 brd ff:ff:ff:ff:ff:ff
inet6 fe80::d0bc:deff:fee8:3ca1/64 scope link
valid_lft forever preferred_lft forever
23: tapfef02bf7-d6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master qbrfef02bf7-d6 state UNKNOWN group default qlen 1000
link/ether fe:16:3e:4d:40:58 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc16:3eff:fe4d:4058/64 scope link
valid_lft forever preferred_lft forever
[root@cl-hpv-1 ~]#
Grundik
они и будут в DOWN
Илья | 😶☮️🐸
Он может быть каким угодно, ибо ими не линух управляет
Artemy
Или cinder-volume active-active.
Там суть в том что у всех volume одни и те же hostname.
Но для надежности, отсутствия рейсов и всякой хероты нужен еще бекэнд координации. Не обязательно, но желательно.
Нет. У них разные хостнеймы но одинаковое имя синдер-кластера и операции выполняются всеми активными нодами кластера
Илья | 😶☮️🐸
@odivlad с DHCP баг кстати пофиксили, но ещё не вмержили в мастер
Илья | 😶☮️🐸
Там теперь другая проблема, что часть инстансов теряет связность даже при L3 сети, когда все роуты уходят в бордер и приходят прямо в интерфейс виртуалки, без кучи флуда ARP
Vladislav
Видел)
Alexander
неа
тут https://docs.openstack.org/neutron/2024.2/admin/deploy-ovs-provider.html пишут
Essentially, all networks use a single OVS integration bridge with different internal VLAN tags. The internal VLAN tags almost always differ from the network VLAN assignment in the Networking service.
Указываю, т.к. еще не знаю на сколько дока отличается от реальности и сырости релиза.
icewolf
icewolf
а бридж.. это мост, и топают по этому мосту пакеты в vxlan
icewolf
Такие дела
Alexander
Смотрите tcpdump, гадание в чате не привнесет никаких результатов
на аппаратном роутере arp запросы есть от ВМ
10:24:51.777689 ARP, Request who-has 192.168.142.1 tell 192.168.142.10, length 42
10:24:51.777701 ARP, Reply 192.168.142.1 is-at 48:5b:39:a2:98:9a (oui Unknown), length 28
попробовал ВМ засунуть в другой vlan, пинги пошли при условии что в порт ВМ прописал allowed address pairs. Но в этом vlan-не этот номер не проходит.
Stanley
Может тупой вопрос, но при попытке миграции волума выключенной ВМ получаю ошибку:
ERROR oslo_messaging.rpc.server novaclient.exceptions.Conflict: Cannot 'swap_volume' instance
Пишут, что это типа "нормально", но во первых, я не могу найти кусок кода который дает этот эксепшен, а во вторых - сфигали вообще такое ограничение?
J
Может тупой вопрос, но при попытке миграции волума выключенной ВМ получаю ошибку:
ERROR oslo_messaging.rpc.server novaclient.exceptions.Conflict: Cannot 'swap_volume' instance
Пишут, что это типа "нормально", но во первых, я не могу найти кусок кода который дает этот эксепшен, а во вторых - сфигали вообще такое ограничение?
Так и должно быть.
Миграции/ретайпы ток на включенном, на горячую, потому что этим qemu занимается.
J
Может тупой вопрос, но при попытке миграции волума выключенной ВМ получаю ошибку:
ERROR oslo_messaging.rpc.server novaclient.exceptions.Conflict: Cannot 'swap_volume' instance
Пишут, что это типа "нормально", но во первых, я не могу найти кусок кода который дает этот эксепшен, а во вторых - сфигали вообще такое ограничение?
Эт если про rbd бекэнд говорить. За остальные точно не скажу)
Stanley
Так и должно быть.
Миграции/ретайпы ток на включенном, на горячую, потому что этим qemu занимается.
Пока логики не улавливаю. Чем включенный от выключенного волума отличается? И опять же, не могу найти код :(
Stanley
а, кажется начинает доходить. Типа Нова не узнает о том, что синдер перетащил волум, если ВМ выключена?
J
а, кажется начинает доходить. Типа Нова не узнает о том, что синдер перетащил волум, если ВМ выключена?
Нет, логика в том что ретайп делается через qemu block-job. Скорее всего через drive mirror, но я не смотрел)
Если вм выключена, процесс qemu не работает, копирование делать некому.
Два ваианта миграции есть:
1. Приаттаченный том мигрируем, тогда это будет через block-job и нужно чтобы ВМ была active\paused, короче, чтобы qemu процесс этой машины был запущен
2. Не приаттаченный том. В этом случае будет миграция через rbd migrate
Вроде, не напиздел)
J
Нет, логика в том что ретайп делается через qemu block-job. Скорее всего через drive mirror, но я не смотрел)
Если вм выключена, процесс qemu не работает, копирование делать некому.
Два ваианта миграции есть:
1. Приаттаченный том мигрируем, тогда это будет через block-job и нужно чтобы ВМ была active\paused, короче, чтобы qemu процесс этой машины был запущен
2. Не приаттаченный том. В этом случае будет миграция через rbd migrate
Вроде, не напиздел)
@Outlingo
Если минутка есть, подскажи, пожалуйста.
J
Пока логики не улавливаю. Чем включенный от выключенного волума отличается? И опять же, не могу найти код :(
Вот гляди как qemu умеет, оказывается. Чо там только нет.
https://qemu-project.gitlab.io/qemu/interop/live-block-operations.html
Stanley
То есть, in-use этими занимается qemu, а available - синдер?
J
То есть, in-use этими занимается qemu, а available - синдер?
Ну типа того.
https://opendev.org/openstack/cinder/src/commit/0b165a3f3ce49a25d6257f266aac702e28213590/cinder/volume/drivers/rbd.py#L2293
J
Жесть... Розовые очки бьются стекла внутрь :(
А чо такого то?
Довольно разумно и круто, как по мне.
Stanley
Пардон, все еще не догоняю логики. Сделали сервис, который работает с блочкой - так пусть он ВСЕ операции делает с дисками
Stanley
in-use и availabl - это ж просто статус в базе...
Grundik
Пардон, все еще не догоняю логики. Сделали сервис, который работает с блочкой - так пусть он ВСЕ операции делает с дисками
давайте оторвем кролику уши) ведь он ходит только лапами))
Grundik
Статус в бд означает статус в бд
ну так меняй статус в БД )) а что там реально только богу бедет известно)
Artemy
in-use и availabl - это ж просто статус в базе...
Слово "них.я" пишется слитно, а "не так" раздельно (ц)
J
Жесть... Розовые очки бьются стекла внутрь :(
Не просто статус.
Логика примерно такая:
У nova нет статусов и абстракций для того чтобы отслеживать еще и статус задач по cinder томам.
Допустим, ты на выключенной ВМ начал миграцию тома. Как уведомить об этом nova, чтобы она не дала запустить вм? Что должен возвращать nova-api? Не охуеет ли владелец вм от того что не может стартануть свою вм несколько часов?
Плюс возможные рейс кондишены когда cinder инициировал миграцию, нова еще не получила ноификацию и одновременно отправлена была команда на включение.
Stanley
Не просто статус.
Логика примерно такая:
У nova нет статусов и абстракций для того чтобы отслеживать еще и статус задач по cinder томам.
Допустим, ты на выключенной ВМ начал миграцию тома. Как уведомить об этом nova, чтобы она не дала запустить вм? Что должен возвращать nova-api? Не охуеет ли владелец вм от того что не может стартануть свою вм несколько часов?
Плюс возможные рейс кондишены когда cinder инициировал миграцию, нова еще не получила ноификацию и одновременно отправлена была команда на включение.
Ну то что нова с синдером не общается на тему волумов - это я понял. Но это как бы такое себе
Stanley
Это как односторонний синдер, который говорит "сделай мне таргет", а потом не проверяет есть ли он или отвалился
Stanley
Не люблю я системы без обратной связи, карочи
J
А так выходит безопасно.
Если хочешь миграцию оффлайн - детачишь том, все уверены что теперь то ничо не случится и что его можно залочить на время миграции.
А не хочешь оффлайн - вот тебе через blockjob. Онлайн миграцию средствами ceph не сделали потому что непонятно как сделать консистентно это не включая в процесс qemu.
Stanley
А так выходит безопасно.
Если хочешь миграцию оффлайн - детачишь том, все уверены что теперь то ничо не случится и что его можно залочить на время миграции.
А не хочешь оффлайн - вот тебе через blockjob. Онлайн миграцию средствами ceph не сделали потому что непонятно как сделать консистентно это не включая в процесс qemu.
Да все понятно как сделать - ленивые жопы просто. Хотя о чем это я... Сам такой же :(
J
Да все понятно как сделать - ленивые жопы просто. Хотя о чем это я... Сам такой же :(
Больше не лень, а бюрократия)
Много новшеств в nova нужно впиливать, причем для каждого бекэнда.
Поэтому и не стали так делать. Тем более это ж nova.
Там любимые их мантры "у меня всё работает", "непонятен юзкейс" и "нихачу мержить и переносить на следующий релизный цикл, abandon due to closed merge window", приходите в следующем году, мы вам заново мозги выебем всей процедурой пропихивания вашего кода.
Stanley
Такая же шняга в синдере. Потому и нехай будет говно написанное индусами шесть лет назад и дающая багу
Stanley
Сейчас тот же lvm backend весь мозг сожрал. Обвесил чекерами и забил. Хотя правильней было б в мастера замержить
Kostiantyn
Пардон, все еще не догоняю логики. Сделали сервис, который работает с блочкой - так пусть он ВСЕ операции делает с дисками
Я бы воспринимал это как «сервис, который предоставляет блочное устройство»
А работать с ним может nova, horizon (отображая волюмы), используя API
Здесь лучше проглядывается принцип единой ответственности в архитектуре, и этим легче в итоге управлять
Stanley
Ага, вместо того, чтобы сделать небольшую проверку (а лучше блокировку) запуска ВМ на время миграции волума - распилили миграцию между кему и синдером. Управлять стало "легче", ага
J