Есть ещё один, он работает в Proxmox - там HA из коробки работает

Это которое родное от linbit в связке corosync/pacemaker ?

Можно ещё что нибудь из best practices. Например, на вычислительных нодах также можно использовать hugepages. Это так же можно рассматривать как резервирование памяти под виртуалки, куда не залезет ceph.

а opennebula  в контейнере нормально живет ? если в одном контейнере фронт+kvm нода ?

А зачем kvm ноду в контейнер?

Как ни странно OpenNebula не так распространена в РФ как в той же Европе например

на одной ноде хотел крутить проксмокс и opennebula-kvm ноду, но они конфликтуют из-за пакета qemu-kvm

Готовлю доклад по OpenNebula на DevOpsConf, накидайте вопросов о чем было бы интересно послушать

Я провел исследования, сделал выводы и хочу с вами поделиться.
У виртуалки в opennebula есть два параметра: CPU и VCPU.
И они значат не то, что вы думаете.

VCPU - это сколько ядер в виртуалке.
А ещё это - сколько ядер хоста может выжрать виртуалка.
Одно ядро виртуалки, если его нагрузить, выжирает одно ядро хоста.
Виртуалка с 4 VCPU, если их загрузить, нагрузит 4 ядра хоста.

CPU - бесполезный параметр.
opennebula позволяет выставлять приоритеты виртуалкам по части cpu.
Приоритеты выставляются через подсистему cgroups.
В cgroups есть параметр cpu.shares, который можно выставить процессу или группе процессов.
Два процесса с cpu.shares=100 поделят процессорное время ядра поровну.
Процессы с 100 и 200 поделят время, как 1/3 и 2/3 (каждый получит свой кусок от 100+200).
Так вот, CPU=1 у виртуалки просто выставляет ей cpu.shares=1024. И все.
CPU=0.5 - это cpu.shares=512.
CPU=0.01 - это cpu.shares=11.

Как это будет выглядеть на практике.
Допустим, есть хост с 1 ядром.
И мы запускаем 2 виртуалки с такими параметрами:

* v1: CPU=1 VCPU=1
* v2: CPU=1 VCPU=1

Если на v1 и v2 запустить нагрузку, они поделят одно реальное ядро пополам.
Если у v1 указать CPU=0.5, то он будет получать 33% одного реального ядра, а v2 - 66%.
Почему? Потому что их cpu.shares будут равны в сумме 1536. Доля v1 (512) в этом будет 33%, а доля v2 (1024) - 66%.
Так вот, если теперь у v2 указать CPU=0.5, то они снова будут делить ядро пополам.
Почему? 512+512 = 1024, и доля каждого (512) будет снова равна 50%.

CPU не отражает что-то сам по себе.
Он просто задает приоритет.
И он имеет смысл только в сравнении с CPU других виртуалок.
CPU=1 у всех виртуалок на хосте имеет такой же смысл, как CPU=0.01 или CPU=100.
Он имеет смысл только в одном случае: если у нас честный хостинг.
Т.е. если мы продаем виртуалки вообще без overselling'а.
Например, сервер на 24 ядра - это 24 виртуалки с одним виртуальным ядром.
Честно и не выгодно.
В этом случае параметр можно использовать.
opennebula честно считает отданные CPU и указывает их в "Allocated CPU".

1. Переезд с других гипервизоров и облаков. Я лично переносил виртуалки с ксена, гипер-ви и вмвары ) Морока, конечно, только с виндой и древними дистрами линукса. А, да, морока, конечно, только из-за virtio.
2. Разграничение прав пользователей на основе групп. Как правильно и красиво рулить правами, квотами, шаблонами и др. ресурсами в рамках групп пользователей.
3. Твики ускорящие работу сефа и/или виртуалок.
4. Что такое зоны, VDC, кластер. Их отличия и для каких целей они должны использоваться?
5. Неочевидные вещи, которые даже, возможно, описаны в документации, но так далеко залезают не всякие ) Например, опция Allocated CPU, в шаблоне значащаяся как CPU. Это, как я понимаю, зарезервированное за виртуалкой кол-во ЦПУ. Но если проц свободен, виртуалка сможет отожрать больше этого значения. И что если выствить это значение на весь доступный гипервизору ЦПУ, то с созданием новых виртуалок будут проблемы - небула будет жаловаться на недостаток ресурсов при их развёртывании. Или что опция flatten удаляет все снимки. Что диску, который имеет снимки уже нельзя изменить размер. Нужно сначала удалить все снимки...  :) Вот что-то типа таких вещей.