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

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

А как объяснили то это?

Для людей которые в бабкины сказки верят и друг другу их из поколения в поколение передают 100% любая нестандартная ситуация будет болью)

А как объяснили то это?

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

в общем всем спс

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

Чо такое в их понимании динамическое распределение ресурсов? Как в вмваре автоматом не балансируются виртуалки между хостами. Только при создании раскидываются или при эвакуации с выведенного из работы хоста.

В общем, у меня прям дико полыхать начинает от таких специалистов. Им бы в компуктерной помощи работать с таким подходом.

Для людей которые в бабкины сказки верят и друг другу их из поколения в поколение передают 100% любая нестандартная ситуация будет болью)

в варе когда-то это было актуально =) кровавый интерпрайз

Динамическое распределение ресурсов это DRS?

Так-то вообще сервис placement который собирает инфу о состоянии и ресурсах год есть давно. И на этапе scheduling/evacuate планировщик свободные ресурсы учитывает (ещё и в соответствии с политиками - если их задать)

Так-то вообще сервис placement который собирает инфу о состоянии и ресурсах год есть давно. И на этапе scheduling/evacuate планировщик свободные ресурсы учитывает (ещё и в соответствии с политиками - если их задать)

Насколько я понял, речь о continuous placement, а не о initial placement

Насколько я понял, речь о continuous placement, а не о initial placement

Ну то есть DRS?

ну да

Но тут жеж проблема не в нодах с разными наборами ресурсов будет.

@AlexanderChadin тут ты вроде хорошо state of the art знаешь 😀

кажется тут все как с мониторингом – каждый оператор для себя сам решает этот вопрос)

Скорее всего. То есть - инструменты есть, инструменты неидеальные, решения делались и делались под конкретные кластера. Потому как большой вопрос когда инициировать оптимизацию, как оптимизировать, с какой интенсивностью двигать нагрузки между нодами.

Ребзя, есть нова + циндер (ОС Виктория). Cinder backend - NFS У Циндера стоит: 2021-03-07 17:22:25.366 3555674 DEBUG oslo_service.service [req-1582d434-2de4-4ba4-801f-f624e3cf1a0e - - - - -] nfs-hdd.report_discard_supported = True При этом когда нова коннектит имейдж Cinder/NFS к инстанцу она не добавляет опцию discard/unmap. <driver name="qemu" type="raw" cache="none" io="native"/> Что я делаю не так?

И я не понимаю момент - если коннектит сам имейдж Нова то как она должна узнать из конфига Циндера что надо с Дискардом подключаться?

И я не понимаю момент - если коннектит сам имейдж Нова то как она должна узнать из конфига Циндера что надо с Дискардом подключаться?

Image meta

Image meta

и какая конкретно мета должна быть прописана? Все что надо для локального сторейжда (без Циндера) прописано и работает (появляется unmap)

для Циндера надо чтото ещё дописывать?

т.е. вот основной диск, локальный - <driver name='qemu' type='qcow2' cache='none' discard='unmap'/> вот то что подключается через циндер - <driver name="qemu" type="raw" cache="none" io="native"/>

т.е. вот основной диск, локальный - <driver name='qemu' type='qcow2' cache='none' discard='unmap'/> вот то что подключается через циндер - <driver name="qemu" type="raw" cache="none" io="native"/>

там вроде ещё в конфиге новы надо указать про unmap

cinder я, кстати, так и не понял как заставить работать с qcow2 :( Упёрто подключал LVM и всё тут

там вроде ещё в конфиге новы надо указать про unmap

там все указано > hw_disk_discard=unmap ([libvirt] section)

смотрите, у Циндера есть такая настройка - report_discard_supported = true Вот я пытаюсь понять как происходит этот самый репорт в нову

то есть от куда Нова знает что в циндере это прописано?

циндер просто дает доступ к хранилищу но подключает все (и генерит строчки для Либвирта (ХМЛ)) - Нова

т.е. вот основной диск, локальный - <driver name='qemu' type='qcow2' cache='none' discard='unmap'/> вот то что подключается через циндер - <driver name="qemu" type="raw" cache="none" io="native"/>

Так, на свеже созданных Инстанцах все ок, на старых не ок

в смысле проблема решена

Народ, кто нить vrouter переводил на dpdk?

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

Эта проблема и в виктории

кто-то смог добиться живой миграции вм без сетевых потерь? у меня потери минимум 4-5 секунд на ovs

кто-то смог добиться живой миграции вм без сетевых потерь? у меня потери минимум 4-5 секунд на ovs

мы до пары довели на до конца не победили

мы до пары довели на до конца не победили

А как?

А как?

тюнили параметры миграции, сетевку. А затык по итогу остался в переключении портов нейтроном

А vrouter с tf кто-нить юзает?

А vrouter с tf кто-нить юзает?

tf == terrraform?

tf == terrraform?

Tungsten Fabric:

Tungsten Fabric:

были тут такие, обычно после обеда просыпаются =)

Добрый день друзья, скажите, а можно как то изменить cat /sys/class/dmi/id/product_serial ? суть проблемы то что при снапшоте и поднятия вм из снапшота на той же ноде, Вм имеет тот же сериал, а надо что бы другой был

Добрый день друзья, скажите, а можно как то изменить cat /sys/class/dmi/id/product_serial ? суть проблемы то что при снапшоте и поднятия вм из снапшота на той же ноде, Вм имеет тот же сериал, а надо что бы другой был

В xml инстанса лезть надо

ок, попробую

В xml инстанса лезть надо

Не вариант. xml сгенерируется заново и затрется.

Не вариант. xml сгенерируется заново и затрется.

Ну опенстак в этом плане кастрирован

server_id из базы берётся же

Вообще непонятно. В product_serial должен быть uuid виртуалки.

Если при раскатывании из снапшота он остается тем же самым, значит снапшот навернут на машину с тем же uuid.

Вот, например.

Добрый день друзья, скажите, а можно как то изменить cat /sys/class/dmi/id/product_serial ? суть проблемы то что при снапшоте и поднятия вм из снапшота на той же ноде, Вм имеет тот же сериал, а надо что бы другой был

Понял. Речь идёт конкретно про serial id, который ранее по-умолчанию брался из /etc/machine-id гипервизора. Сейчас (начиная со stein) в nova по-умолчанию для sysinfo_serial испольузется уникальный UUID для каждой VM (https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.sysinfo_serial)

в более старых, он не совпадает с uuid

с UUID чего?

VM serial product и uuid виртуалки разные

да, по-умолчанию в версиях до stein'a было так » Uses the “os” source if possible, else “hardware”. вот пример с версии до stein'a при использовании одного гипервизора для двух VM гипервизор: cat /etc/machine-id eac03f97e4494bb98fc67e5e644bf32e vm1: virsh dumpxml 189dd5ab-3e7c-4b7d-8802-6087557912f8 | grep -Ei "name=('serial'|'uuid')" <entry name='serial'>eac03f97-e449-4bb9-8fc6-7e5e644bf32e</entry> <entry name='uuid'>189dd5ab-3e7c-4b7d-8802-6087557912f8</entry> vm2: virsh dumpxml acb2a6d2-3e47-42d0-950e-47119674d098 | grep -Ei "name=('serial'|'uuid')" <entry name='serial'>eac03f97-e449-4bb9-8fc6-7e5e644bf32e</entry> <entry name='uuid'>acb2a6d2-3e47-42d0-950e-47119674d098</entry>

Не вариант. xml сгенерируется заново и затрется.

да так и происходит, ищу костыль, как это поправить)

да так и происходит, ищу костыль, как это поправить)

Обновиться, очевидно)

не вариант :)

тюнили параметры миграции, сетевку. А затык по итогу остался в переключении портов нейтроном

Привет, а можешь подробнее рассказать как именно потюнили? может в личку?

Привет, а можешь подробнее рассказать как именно потюнили? может в личку?

Над поискать плейбуки последние, я полгода как ушел оттуда )

Над поискать плейбуки последние, я полгода как ушел оттуда )

был бы благодарен, вторую неделю борем, 4 сек рекорд, а 2 сек было бы норм

Снежана Еремина: user has been CAS banned

Всем привет, подскажите как создать ВМ с графическим адаптером.

облако на mail.ru

их саппорт говорит что так сделать нельзя, пока использую вирткальный монитор на tigervnc, но с ним есть проблемы, хочется нормальный x11vnc чтобы был 0 дисплей на видяхе.

их саппорт говорит что так сделать нельзя, пока использую вирткальный монитор на tigervnc, но с ним есть проблемы, хочется нормальный x11vnc чтобы был 0 дисплей на видяхе.

а саму карточку кто-то уже вставил в комп?)

а саму карточку кто-то уже вставил в комп?)

так виртуалке же

диск диртуальный, проц виртуальный, какие проблемы сделать виртуальную видяху? на proxmox я спокойно выбираю тип видеоадаптера, какой хочу при создании ВМ. Здесь пока разобраться не могу.

так виртуалке же

прекрасно, но суть вопроса не меняется, видяху уже вставили в вм?

прекрасно, но суть вопроса не меняется, видяху уже вставили в вм?

кажется ее там просто нет

вот скорее всего адаптер "стандартный" на 4-128Мб который просто затычка, чтобы виндус "не ругался"

вот в этом и вопрос, есть ли в openstack-client параметр отвечающий за видяху при создании вм?

по документации mail.ru ничего про это не сказано, я выбираю группу безопасности, flavor, volume, net

зачем вообще видяха в вм?

и создаю ВМ, все хорошо, но дисплея нет

да у меня гуи приложение, нужен ubuntu desktop

ну ок, дай ему десктоп виртуальный

например берем Xvfb и погнали

зачем тебе железо, чтобы всего-лишь эмулировать рабочий стол))