Стек я не вижу смысла тут поднимать...

Меня, к сожалению не спрашивают, на чем релизовывать, мне говорят : реализуй на openstck. Про ваш вариант я в любом случае почитаю, выглдит интересно.

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

Логично! Положить бд в инстансы, в потом реплецировать для "надёжности" на другие инстансы

Лучше БД держать на физике

Согласен. Про инстансы и репликацию была шутка..

Я правильно понимаю, что создать образ работающего сервера, например акронисом, и перенести его в среду опенстека задача как минимум нетривиальная? Я сейчас копаюсь в документации по glance и пока ничего близкого по функционалу не нашел.

насчёт окрониса хз, qcow/raw импорт работает отлично

Тут вопрос о миграции физической машинки в виртуальную

Покопайся в сторону вмваре тулзов по миграции в vhd или vmdk, а далее qemu-convert переделаешь в qcow2 или raw

можно еще rsync в корень с livecd

Как же я люблю такие велосипеды.. Спасибо за направление, буду гуглить!

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

А v2v и p2v уже не модно?

зависит от нагрузки на базу

😉

Если нужн омигрировать систему полностью, то это однозначно дерьмовая идея.
Вот олько несколько пунктов:

1. Убедиться что везде нормальные udev правила для именования устройств, потому что если там нету чего-то типа системдшного predictable device namin, то имена интерфейсов пойдут по очевидной прчиине по пизде. Также проверить всё что в своих конфигах может использовать имена интерфейсов или мак адреса
2. Проверить fstab, убедиться что монтирование происходит не по именам устройств, а по меткам фс, uuid, lvm тэгам или чему угодно еще. Потому что при миграции, опять же, количество и названия дисковых устрйоств поменяются
3. Если разные точки монтирования на разных устройствах, надо придумать как всё скопировать на одно устройство и с него уже снимать образ, иначе разбираться в этой лапше покажется сущим адом.
4. Установить в системе cloud-init
5. Грузить с livecd и содавать образы в любом удобном тебе формате, загрузить их в glance
6. Нарезать в опенстеке сети согласно твоей продуманной заранее архитектуре
7. Начать потихоньку разворачивать из образов

Сизифов труд. Бессмысленный и тяжелый. Проще насоздавать чистых виртуальных машин и туда смигрировать веб приложения.

В любом случае затея бессмысленная, мне кажется)
Не опасная, не плохая, а просто смысла нету.

Если, конечно, ты контролируешь baremetal инфраструктуру. А если арендуешь где-то серверы или кто-то у тебя берет под свои приложения виртуальную машину, то, конечно, ради бога, пусть работает в виртуалке и пишет хоть в ceph хоть в какой-нибудь, прости хоспаде, solidfire, ничего плохого.

>Проще насоздавать чистых виртуальных машин и туда смигрировать веб приложения.
Да, к этому я и надеюсь склонить наших реформаторов. Которые хотят опенстак просто потому что модно-молодежно.

>А если арендуешь где-то серверы или кто-то у тебя берет под свои приложения виртуальную машину
Арендуется дата-центр, железо все своё. Я так понимаю начальство хочет продать часть железа и отказаться от части аренды, перенеся инфраструктуру на опенстак. С одной стороны, с точки  зрения бизнеса, я понимаю эти фантазии,  но как инженер я знаю, что мы не мэйл.ру, условный, с отделом девопсов, и реализация может встать в серьёзную головную боль, возможные простои, отказы клиентов и пр. Так что финансовая сторона вопроса тоже вызывает сомнения..

Спасибо большое за ваш список по пунктам, схоронил, попробую реализовать на какой-нибудь мартышке.