Миграция работает и с локальными дисками…

Миграция работает и с локальными дисками…

Раздувание диска при миграции фиксили?

не используй qcow =)

ни разу не видел, но судя по ошибке у вас в ovn_mac_addr_net указана некая сеть, но сетей с таким именем несколько. предлагают указать ID сети, вместо имени

Всем привет :) Может тут есть эксплуатирующие redhat openstack? При минорном обновлении 16.2.2->16.2.3 и проведения операции "openstack overcloud update prepare" ловлю ошибку resources.OVNMacAddressPort.properties.network: Multiple network matches found for name 'ovn_mac_addr_net', use an ID to be more specific.

А это точно ошибка? Обычно такое это ворнинг и не требует подпрыгивания. OVN сам разберется.

Но там же не о маке речь идёт о сети и ее имени, не помню чтобы мы могли управлять маками в ovn

Но там же не о маке речь идёт о сети и ее имени, не помню чтобы мы могли управлять маками в ovn

Ребят, существует какой-то способ не останавливая инстанс докинуть ему cpu и ram-ы?

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

там в кли уже опций накидали? или по прежнему через жопу?

там в кли уже опций накидали? или по прежнему через жопу?

Не накидали)

а лайв ресайс заявлен уже хз сколько лет :D

Даже и не знал что заявляли

а лайв ресайс заявлен уже хз сколько лет :D

там по сути при создании вмки надо в хмл для либвирта дописать что хотплаг вкл, а потом память досыпается типа "планками памяти" отдельными хмл, а цпу не помню уже как

Короче, выходит что надежно это сделать нельзя. Любая операция приводящая к генерации xml описания домена заново затрет хотплаг.

Что интересно в ovirt-е тоже libvirt но hot(plug/unplug) доступен из веб-интерфейса

https://www.ovirt.org/develop/release-management/features/virt/hot-plug-cpu.html

там по сути при создании вмки надо в хмл для либвирта дописать что хотплаг вкл, а потом память досыпается типа "планками памяти" отдельными хмл, а цпу не помню уже как

и как оно уживается с текущим <memory unit='KiB'></memory>?

seems neutron should be downloaded prior installation

I installed from devstack not manually

take a look on tutorial I've sent. You do not need to install neutron manually I have a devstack installed / reinstalled several times using this guide without any issue, on Ubuntu 20.04

Very thank But devstack stack.sh should will install all

You need install devstack from branch for ubuntu 20.04 (not master) yoga - latest releas for 20.04

M Try to use this guide: https://docs.ovn.org/en/latest/tutorials/ovn-openstack.html#setting-up-devstack

есть ли какая-то матрица по соотношению релизов новы и поддерживаемого qemu ?

есть ли какая-то матрица по соотношению релизов новы и поддерживаемого qemu ?

https://docs.openstack.org/nova/latest/reference/libvirt-distro-support-matrix.html

Печально чот, уже 7.1 версия же вышла, а нова до сих пор юзает 5…

Печально чот, уже 7.1 версия же вышла, а нова до сих пор юзает 5…

Ну если апи имеет обратную совместимость, то почему бы и не обновить. Я вот тоже про свежий либвирт мечтаю

А не понял что значит "nova использует". Использует же тот который установлен)

Ну ты понимаешь, есть каста суеверных, которые от капабилити листов не отходят

А не понял что значит "nova использует". Использует же тот который установлен)

nova => libvirt => qemu на одном из шагов может быть несовместимость и "ой всё"

Ой что? Практические примеры хочу почитать. У самого было только наоборот, проблемы когда старье использовал.

Ой что? Практические примеры хочу почитать. У самого было только наоборот, проблемы когда старье использовал.

А вот прямо хочется узнать «ой что»? Да еще и в проде? :) Есть матрица совместимости, живём по ней. Захотелось анального зуда - пошли экспериментировать. Все просто.

В матрице совместимости минимальные версии указаны, а максимальных нет. Ну и чего тогда жаловаться и выдумывать что nova использует пятый либвирт, а вышел то уже восьмой? Бери и используй восьмой, матрица на которую вы с коллегами ссылаетесь не запрещает так делать.

nova => libvirt => qemu на одном из шагов может быть несовместимость и "ой всё"

Да я и не жаловался на пятый либвирт. Это ты меня с кем то перепутал :) Лично мое мнение - никакого апстрима в опенсорсе. Но и легаси лучше не тянуть. По этому, лучше где то поближе к голове держаться, но особо не спешить. (надо дважды подчеркнуть «мое мнение»?) :)

Может, я обновил как-то либвирт с новой и с запущенными вм начали происходить плохие вещи. Нова перестала мочь управлять вм-ками и появились лаги в диск. Полечилось откатом либвирта на старую версию. Victoria(kolla-ansible) если правильно помню libvirt 7

Я перепутал версии Libvirt и qemu, а не тебя с коллегой) Сути это не меняет)

Может, я обновил как-то либвирт с новой и с запущенными вм начали происходить плохие вещи. Нова перестала мочь управлять вм-ками и появились лаги в диск. Полечилось откатом либвирта на старую версию. Victoria(kolla-ansible) если правильно помню libvirt 7

Может, я обновил как-то либвирт с новой и с запущенными вм начали происходить плохие вещи. Нова перестала мочь управлять вм-ками и появились лаги в диск. Полечилось откатом либвирта на старую версию. Victoria(kolla-ansible) если правильно помню libvirt 7

Основная проблема - запущенные вм

А лаги в локал диски же?

Нет в цеф, вечером обновил, а с утра появились проблемы сначала думали что цеф виноват. В логах либверта мата много было.

Так в чем дело о оказалось, не томи?) Как обновление libvirt оказалось свзано с тормозами на рабочих вм?