меня очень сильно смущает "ignition: no config provided by user"

в отличие от того же atomic, где cloud-init и никаких ворнингов не сыпется при использовании

вопрос закрыт, нашел хороший мануал по этому варианту федоры

вопрос закрыт, нашел хороший мануал по этому варианту федоры

Скинь, пусть тут будет)

Вдруг кому пригодится.

https://computingforgeeks.com/install-fedora-coreos-fcos-on-kvm-openstack/

Странно почему в instance_metadata нет unique key на key + instance_uuid

Если кому интересно про cinder volume retype ( например @vyacheslav_vershinin) Вот тут (https://docs.openstack.org/cinder/ussuri/admin/blockstorage-volume-migration.html) в доке есть пара интересных комментов в начале: 2. If the volume is not attached, the Block Storage service creates a volume and copies the data from the original to the new volume 3. If the volume is attached to a VM instance, the Block Storage creates a volume, and calls Compute to copy the data from the original to the new volume. Currently this is supported only by the Compute libvirt driver.

Для приаттаченного вольюма к ВМ ретайп делает весёлую вещь - циндер создаёт новый том - назначения, а потом QEMU/KVM перегоняет том без участия циндера. Со стороны нова компьют запуск этого процесса через драйвер либвирта выглядит так: 2021-09-28 14:21:46.714 7 DEBUG nova.compute.manager [req-29436a1a-58c2-46a7-835b-7069451f4cc3 a945d9b8c5f74472b4137d5cf0ac797c a4842d7a6dcc4acd85618a011cfbedd3 - default default] [instance: f9f91de4-e587-4e23-9a9b-db07bbdc543c] swap_volume: Calling driver volume swap with connection infos: new: {'driver_volume_type': 'rbd', 'data': {'name': 'volumes/volume-2aa0a8cd-23a5-44a3-a244-f36c327f3d84', 'hosts': ['192.168.33.42', '192.168.33.43'], 'ports': ['6789', '6789'], 'cluster_name': 'ceph', 'auth_enabled': True, 'auth_username': 'cinder', 'secret_type': 'ceph', 'secret_uuid': '***', 'volume_id': '2aa0a8cd-23a5-44a3-a244-f36c327f3d84', 'discard': True, 'keyring': None, 'qos_specs': None, 'access_mode': 'rw', 'encrypted': False}, 'status': 'reserved', 'instance': 'f9f91de4-e587-4e23-9a9b-db07bbdc543c', 'attached_at': '', 'detached_at': '', 'volume_id': '2aa0a8cd-23a5-44a3-a244-f36c327f3d84', 'serial': '2aa0a8cd-23a5-44a3-a244-f36c327f3d84'}; old: {'driver_volume_type': 'rbd', 'data': {'name': 'volumes/volume-2f5ae2a7-ecd1-4ec5-9c67-8130f9d3aaac', 'hosts': ['192.168.33.22', '192.168.33.23'], 'ports': ['6789', '6789'], 'cluster_name': 'ceph', 'auth_enabled': True, 'auth_username': 'cinder1', 'secret_type': 'ceph', 'secret_uuid': '***', 'volume_id': '2f5ae2a7-ecd1-4ec5-9c67-8130f9d3aaac', 'discard': True, 'keyring': None, 'qos_specs': None, 'access_mode': 'rw', 'encrypted': False}, 'status': 'reserved', 'instance': 'f9f91de4-e587-4e23-9a9b-db07bbdc543c', 'attached_at': '', 'detached_at': '', 'volume_id': '2f5ae2a7-ecd1-4ec5-9c67-8130f9d3aaac', 'serial': '921a1acc-5592-4608-9c1a-c06f4d7266ad'} _swap_volume /usr/lib/python3.6/site-packages/nova/compute/manager.py:7271

Calling driver volume swap with

Ну а в логе QEMU/KVM/libvirt: 2021-09-28 14:21:46.795+0000: 1817603: info : qemuMonitorSend:950 : QEMU_MONITOR_SEND_MSG: mon=0x7f8374028070 msg={"execute":"blockdev-mirror","arguments":{"job-id":"copy-vdb-libvirt-13-format","device":"libvirt-13-format","target":"libvirt-14-format","sync":"full","auto-finalize":true,"auto-dismiss":false},"id":"libvirt-713"} fd=-1

Много всяких сообщений о процессе копирования тома...

В рамках одного пула цефа происходит копирование ?

В моём случае я смотрю экстремальный вариант - миграцию тома между кластерами... Думаю нове всё-равно между чем копировать. Если копирование прилетает в нову

Не нове - а кему/квм под ее руководством

А развилка по условию - присоединённый том или нет - это по доке в начале моих постов написано. Я это в исходниках не искал специально

Ну и приятный момент - шанс получить консистентный том при такой миграции без выключения ВМ относительно высоки (конечно не 100% - тут Артемию можно слово передать) - весь ввод вывод контролирует либвирт при миграции и он же копирует данные

либвирт.кему.квм конечно... писать долго

Акстись ничего либвирт там не контроллирует, это все на стороне QEMU ясно же написано что отправляется QEMU_MONITOR_SEND_MSG: mon=0x7f8374028070 msg={"execute":"blockdev-mirror","arguments":{"job-id":"copy-vdb-libvirt-13-format","device":"libvirt-13-format","target":"libvirt-14-format","sync":"full","auto-finalize":true,"auto-dismiss":false},"id":"libvirt-713"}

тяжело писать - либвирт/кему/квм

лог то называется libvirtd.log

ввод вывод да обычно кему часть делает

либвирт запускает истанцы и получает их вывод не более

либвирт обвертка для запуска в соответствии с единым форматом для всего парка гипервизоров и все

либвирт- это просто библиотека, которая даёт возможность обращаться к кему/квм

Дядь, не поверишь к KVM он не обращается ))) ибо KVM это ядерный модуль поддержки виртуализации, такой же как и XEN а сверху стоит QEMU

ну и не библиотека, а демон -) котролирующий запуск QEMU

Ну можно отдельненько пройтись по терминологии и прийти к консенсусу... Предмет отдельный и обширный.... Если я в питоне подключаю работу с либвиртом, делая import libvirt, почему мне не ссылаться на libvirt, как на библиотеку ?

Много всяких сообщений о процессе копирования тома...

Живая миграция на сеф не работала из за либвирта

Ну можно отдельненько пройтись по терминологии и прийти к консенсусу... Предмет отдельный и обширный.... Если я в питоне подключаю работу с либвиртом, делая import libvirt, почему мне не ссылаться на libvirt, как на библиотеку ?

Ну так не надо вводить людей в заблуждение ИМХО.

особенно рассказывая как либвирт там что-то куда-то копирует

Живая миграция на сеф не работала из за либвирта

Работает она там отлично. Возможно секреты или конфиги либвирту не все довезли

Или либвирт свежий.

особенно рассказывая как либвирт там что-то куда-то копирует

В контексте моих сообщений kvm/qemu/libvirt это один прямоугольник. Просто писать это постоянно тяжело - я про это сказал

В контексте моих сообщений kvm/qemu/libvirt это один прямоугольник. Просто писать это постоянно тяжело - я про это сказал

Коллега не в обиду, но KVM вот тут вот вообще не причем.

Много всяких сообщений о процессе копирования тома...

У меня атаченный диск не ретайпится, queens

@vyacheslav_vershinin а он часом не boot ?

@vyacheslav_vershinin а он часом не boot ?

Нет доп диск именно

Там от api что-то про in-use

@vyacheslav_vershinin в личке нормально опиши ситуевину

Ты на ходу ретайпить пытаешься или нет ?

@vyacheslav_vershinin в личке нормально опиши ситуевину

Да мы кейс решаем через выключение, ретайп без детача не работает из-за api - оно возвращает ошибку, что диск используется, даже если выключить vm

аааа так это нормальное поведение

детач ретайп аттач

а если бутовый то базу хачить надо ибо его не детачить

У меня атаченный диск не ретайпится, queens

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

Я на уссури

а если бутовый то базу хачить надо ибо его не детачить

да это не сложно, но такой необходимости не было

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

а пул и цеф один ? или разные ?

Работает она там отлично. Возможно секреты или конфиги либвирту не все довезли

У тебя какие версии стека, либвирта и куэму?

а пул и цеф один ? или разные ?

Два разных кластера цефа, пулы в них разные, но называются олдинаково

а пул и цеф один ? или разные ?

у меня в разные пул в рамках 1 цефа работает с детачем

У тебя какие версии стека, либвирта и куэму?

Еще на Mirantis/Openstack 5.0 работали -)

у меня в разные пул в рамках 1 цефа работает с детачем

с детачем оно и на нетапп нормально едет -)

У тебя какие версии стека, либвирта и куэму?

(nova-libvirt)[root@r2cmp0 /]# virsh --v 7.0.0

Ага, ясно

Два разных кластера цефа, пулы в них разные, но называются олдинаково

У тебя это делалось через QEMU: Монитор отправили сделать зеркало "execute":"blockdev-mirror","arguments":{"job-id":"copy-vdb-libvirt-13-format","device":"libvirt-13-format","target":"libvirt-14-format","sync":"full","auto-finalize":true,"auto-dismiss":false},"id":"libvirt-713"}

У тебя это делалось через QEMU: Монитор отправили сделать зеркало "execute":"blockdev-mirror","arguments":{"job-id":"copy-vdb-libvirt-13-format","device":"libvirt-13-format","target":"libvirt-14-format","sync":"full","auto-finalize":true,"auto-dismiss":false},"id":"libvirt-713"}

Я бы не употреблял связку QEMU/KVM/libvirt если бы знал другой термин общий, который включает все три :)

Илья, без обид все три тут употреблять неверно. Тут все просто. KVM/XEN - это ядерная часть, которая просто правильно перекидывает контексты по большей части. QEMU - юзерспейс виртуализация общая что для KVM/XEN. Libvirt просто запускала QEMU и все

И либвирт еще и в ВмТварь умеет кстати

И либвирт еще и в ВмТварь умеет кстати

и lxc кстати

ну это уже контейнеры, не совсем то о чем мы говорим, но да умеет

я тебе больше скажу он бы и в докер умел бы )) но там философия совсем другая в отличии от lxc / systemd-spawd

Системный диск для запущенной виртуалки тоже переехал норм без детача

какая версия опенстэка ?

ussuri

До миграции было так: | name | ipo-botvol-r2 | | os-vol-host-attr:host | rbd:volumes@rbd-1#rbd-1 | | os-vol-mig-status-attr:migstat | error | | os-vol-mig-status-attr:name_id | None

На ошибку не обращайте внимание - это я первую попытку сделал с "неправильного" гипера, у которого нет кредов для второго бэкенда

После миграции: | name | ipo-botvol-r2 | | os-vol-host-attr:host | rbd:volumes@iporbd#iporbd | | os-vol-mig-status-attr:migstat | success | | os-vol-mig-status-attr:name_id | 31c774be-e978-4162-b1cc-a35dabe71fd7 | | os-vol-tenant-attr:tenant_id | 937474e4b4ca430f958cf44db2815147

На цефе-приёмнике том появился: [root@r1cmp0 ~]# rbd -p volumes ls volume-31c774be-e978-4162-b1cc-a35dabe71fd7

(os-venv) [root@ipo-kayb-cs8-us ~]# openstack volume list +--------------------------------------+---------------+--------+------+--------------------------------+ | ID | Name | Status | Size | Attached to | +--------------------------------------+---------------+--------+------+--------------------------------+ | e1e4a1ad-c10f-4105-892b-cb1f83acb21e | ipo-botvol-r2 | in-use | 1 | Attached to demo2 on /dev/vda |

Так что типа работает

а копию он как делает? через ceph или через qemu?

через qemu по идее должен делать

Но опять же тут по разному и от драйвера завист

https://github.com/openstack/cinder/blob/6901d2337c05fa629c8170991aa85afb7432eca0/cinder/volume/drivers/rbd.py#L1353

а копию он как делает? через ceph или через qemu?

Также - через qemu, как и в случае доп вольюма

в рамках 1 цефа я не видел что бы это делалось через qemu - выглядело так, как магия внутри ceph