Pavel
на нфс же, в логе написано
Pavel
ккоу2
Pavel
флеш рояль
Anonymous
Тогда как вариант законвертить и примапить к другой вм ( ну или примапить не конвертируя)
Pavel
да чо толку, там либвирт не понимает что с памятью делать
Anonymous
Radik
в общем, сделал define
Radik
virsh list --all
Id Name State
----------------------------------------------------
- instance-00000220 shut off
virsh распознал
запускаю
virsh start instance-00000220
error: Failed to start domain instance-00000220
error: internal error: qemu unexpectedly closed the monitor: 2019-12-02T12:06:56.708285Z qemu-kvm: -chardev pty,id=charserial0,logfile=/dev/fdset/2,logappend=on: char device redirected to /dev/pts/3 (label charserial0)
2019-12-02T12:06:56.749371Z qemu-kvm: cannot set up guest memory 'pc.ram': Cannot allocate memory
Radik
памяти
total used free shared buff/cache available
Mem: 31875 8555 16378 321 6941 22505
Swap: 1022 0 1022
Anonymous
nova.conf в студию
Radik
тогда такой вопрос
как сейчас можно импортнуть это всё дело
и запустить в каком-нибудь proxmox или vmware
Pavel
лимиты св
Pavel
лимиты смотри, возможно кему не может сокет сделать
Pavel
или либвирт в дебаг логирование переводи, он напишет что пошло не так
Radik
принято
ушел пока
Anonymous
Qemu-convert qcow в формат vmdk
Pavel
или selinux там какой без профиля под вычислительный узел на kvm
Radik
/srv/nfs/96cf28bd-c074-4aa4-b8fb-62cc6f364452/disk: QEMU QCOW Image (v3), has backing file (path /srv/nfs/_base/0c731df092417ccc1fc4775d18390f7362b1100c), 42949672960 bytes
Pavel
не поможет
Radik
вот и я так подумал(
Anonymous
Anonymous
Anonymous
А не заново пересоздавать
Radik
Radik
а, т.е. тупо куда-то приаттачить?
Anonymous
Да
Anonymous
И потом разбираемся что у тебя с либвирт, почему инстансы не создаются
Radik
да, понял
спасибо всем большое
Anonymous
Если это еще надо будет
Radik
не, сам опенстэк сейчас не нужен
новые создаваться не будут
Radik
в общем, отпишу, как положено
решение оказалось довольно тупым, о чем сразу можно было догадаться
- xml я стянул из лога
- virsh define
- ну и причиной allocate memory конечно же был оверкоммит🤦♂️
Radik
@poghost @j52089ec7e87 спасибо за помощь
NS 🇷🇺
J
Radik
причем я даже своп ради этого врубал на всякий)
J
дофига
20гб стабильно свободно
Ну надо смотреть то на суммарно выделенную виртуалкам память. А из твоих объяснений я подумал что вообще ни одна машина на хосте не стартует.
Radik
Radik
Radik
Hello
Так, немного утренней ржаки от моего начальства.
Перевод by гугль транслейт с корейского.
Pre-meeting request for the introduction of %Company name% OpenStack.
1. Goal
The goal is to transform all server and IDC infrastructure(веб хостинг, два этажа датацентра) that %Company name% currently has into an OpenStack cloud.
The work will be carried out with a phased roadmap.
l %Company name% IDC Operation SE
2. Meeting Agenda
How will you transition your IDC infrastructure to the OpenStack cloud?
l Calculate the primary cost of introducing OpenStack
l Issues on technology transfer and education
Thank you.
Hello
Это имеет хоть сколько-то рациональное зерно? Переводить веб хостинг с физических машин на жирный опенстэк?
Hello
Как вообще может выглядеть миграция физических серверов в инфраструктуру опенстэка? Делать образ каждого сервера и загружать в glance?
Anonymous
Ну в общем и целом это имеет жирный плюс, но трудозатратно получится
Anonymous
И тут надо подумать стек или обойтись докерами с k8s раз это веб
Anonymous
Смотря еще какие сервисы в вебе крутятся
Anonymous
В кластере?
Anonymous
Тогда путь следующий, пробуй ( если есть ресурсы) ceph-docker-k8s базы рекомендовал бы вынести отдельно, далее бэкапы средствами цмс с физики и раскаты уже в сервисах которые крутятся в докерах
Anonymous
Если есть опыт написания playbook то все будет немного проще
Anonymous
Прикоучиваешь ко все этому хозяйству kibana и grafana - профит
Anonymous
Ну и это мое мнение ИМХО
Anonymous
Стек я не вижу смысла тут поднимать...
Hello
Стек я не вижу смысла тут поднимать...
Меня, к сожалению не спрашивают, на чем релизовывать, мне говорят : реализуй на openstck. Про ваш вариант я в любом случае почитаю, выглдит интересно.
Anonymous
Ну ок, тогда все равно рекомендую базы в стек не запихивать, производительность у нее будет вообще не ахти какая!
Hello
Логично! Положить бд в инстансы, в потом реплецировать для "надёжности" на другие инстансы
Anonymous
Лучше БД держать на физике
Hello
Я правильно понимаю, что создать образ работающего сервера, например акронисом, и перенести его в среду опенстека задача как минимум нетривиальная? Я сейчас копаюсь в документации по glance и пока ничего близкого по функционалу не нашел.
Tamerlan
Anonymous
Tamerlan
можно еще rsync в корень с livecd
Hello
Как же я люблю такие велосипеды.. Спасибо за направление, буду гуглить!
Pavel
А v2v и p2v уже не модно?
Dmitry
Dmitry
😉
J
Как вообще может выглядеть миграция физических серверов в инфраструктуру опенстэка? Делать образ каждого сервера и загружать в glance?
Если нужн омигрировать систему полностью, то это однозначно дерьмовая идея.
Вот олько несколько пунктов:
1. Убедиться что везде нормальные udev правила для именования устройств, потому что если там нету чего-то типа системдшного predictable device namin, то имена интерфейсов пойдут по очевидной прчиине по пизде. Также проверить всё что в своих конфигах может использовать имена интерфейсов или мак адреса
2. Проверить fstab, убедиться что монтирование происходит не по именам устройств, а по меткам фс, uuid, lvm тэгам или чему угодно еще. Потому что при миграции, опять же, количество и названия дисковых устрйоств поменяются
3. Если разные точки монтирования на разных устройствах, надо придумать как всё скопировать на одно устройство и с него уже снимать образ, иначе разбираться в этой лапше покажется сущим адом.
4. Установить в системе cloud-init
5. Грузить с livecd и содавать образы в любом удобном тебе формате, загрузить их в glance
6. Нарезать в опенстеке сети согласно твоей продуманной заранее архитектуре
7. Начать потихоньку разворачивать из образов
Сизифов труд. Бессмысленный и тяжелый. Проще насоздавать чистых виртуальных машин и туда смигрировать веб приложения.
J
В любом случае затея бессмысленная, мне кажется)
Не опасная, не плохая, а просто смысла нету.
Если, конечно, ты контролируешь baremetal инфраструктуру. А если арендуешь где-то серверы или кто-то у тебя берет под свои приложения виртуальную машину, то, конечно, ради бога, пусть работает в виртуалке и пишет хоть в ceph хоть в какой-нибудь, прости хоспаде, solidfire, ничего плохого.
Hello
Если нужн омигрировать систему полностью, то это однозначно дерьмовая идея.
Вот олько несколько пунктов:
1. Убедиться что везде нормальные udev правила для именования устройств, потому что если там нету чего-то типа системдшного predictable device namin, то имена интерфейсов пойдут по очевидной прчиине по пизде. Также проверить всё что в своих конфигах может использовать имена интерфейсов или мак адреса
2. Проверить fstab, убедиться что монтирование происходит не по именам устройств, а по меткам фс, uuid, lvm тэгам или чему угодно еще. Потому что при миграции, опять же, количество и названия дисковых устрйоств поменяются
3. Если разные точки монтирования на разных устройствах, надо придумать как всё скопировать на одно устройство и с него уже снимать образ, иначе разбираться в этой лапше покажется сущим адом.
4. Установить в системе cloud-init
5. Грузить с livecd и содавать образы в любом удобном тебе формате, загрузить их в glance
6. Нарезать в опенстеке сети согласно твоей продуманной заранее архитектуре
7. Начать потихоньку разворачивать из образов
Сизифов труд. Бессмысленный и тяжелый. Проще насоздавать чистых виртуальных машин и туда смигрировать веб приложения.
>Проще насоздавать чистых виртуальных машин и туда смигрировать веб приложения.
Да, к этому я и надеюсь склонить наших реформаторов. Которые хотят опенстак просто потому что модно-молодежно.
>А если арендуешь где-то серверы или кто-то у тебя берет под свои приложения виртуальную машину
Арендуется дата-центр, железо все своё. Я так понимаю начальство хочет продать часть железа и отказаться от части аренды, перенеся инфраструктуру на опенстак. С одной стороны, с точки зрения бизнеса, я понимаю эти фантазии, но как инженер я знаю, что мы не мэйл.ру, условный, с отделом девопсов, и реализация может встать в серьёзную головную боль, возможные простои, отказы клиентов и пр. Так что финансовая сторона вопроса тоже вызывает сомнения..
Спасибо большое за ваш список по пунктам, схоронил, попробую реализовать на какой-нибудь мартышке.
Dmitry
это не конструктив, скорее предостережение по поводу того, что надо остановиться и подумать - а зачем нам переносить все в виртуализацию? ...
Pavel
Попытка донести инженерную мысль Бизнесу?)
Dmitry
Надежда сделать ит мир у нас чуть более осознанным.
NS 🇷🇺