Телеграмм чат группы openstack

спасибо это интересно почитаю

Dmitry Polyakov in OpenStack — русскоговорящее сообщество

14:45пожаловаться

Тогда внимаельно изучи все процессоры во всех своих гипервизорах, найди самый бедный по возможностям, затем ставь host_model qemu64\kvm64 и добирай недостающие флаги экстра параметрами.

Если поступить по-другому с сильно разношерстным парком процессоров, то во время миграции с более навороченного на менее навороченный будешь получать ошибку.

только во время живой

14:45пожаловаться

ndaemonv

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

Гипервизоры с разными cpu группировать в host aggregate и задействовать соответствующий фильтр для планировщика.

Евгений in OpenStack — русскоговорящее сообщество

14:46пожаловаться

ndaemonv

Дмитрий я ж грю я искал универсальное решение у меня очень разношерстные процы

Самое универсальное решение на мой счет, поставить везде самый младший. Тем самым и миграция будет работать и универсальность по всем хостам

14:46пожаловаться

Евгений, а с производительностью как дела будут?

14:47пожаловаться

ndaemonv

Евгений, а с производительностью как дела будут?

Протесть.
ЧУть ниже чем на самом младшем из твоих процессоров.

14:50пожаловаться

Засчет более высокой тактовой частоты на "крутых" производительность будет лучше, конечно)

Евгений in OpenStack — русскоговорящее сообщество

14:51пожаловаться

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

14:51пожаловаться

да протестирую кэшн

14:51пожаловаться

всем спасибо

14:52пожаловаться