Немного не в ту сторону напишу. Но обратите внимание как сделано то же vmware с vicentr, ovirt вся логика управления находится на отдельной vm (ну или на отдельной железке) и к ней идет подключение гипервизоров. Главное сам sunstone не потерять, а лучше его еще и бэкапить. А по HA и распределенности- поймать глюк из-за косячной репликации или потери лидера в случае сетевой недоступности- мало приятного и вероятность может быть выше, чем потерять одну vm (при том, что она еще и бэкапится). Но это только мое мнение, может кто не согласится.
Важен не только sunstone, но и oned. Управляющие демоны в виртуалке - это проблема курицы и яйца. Я бы тогда взял контейнер другой технологии, lxc например.
The OpenNebula daemon oned manages the cluster nodes, virtual networks, virtual machines, users, groups and storage datastores. Описание из одной строки выглядит подозрительно 😁 поэтому и спрашиваю.
Ну, оно все точно описывает. В opennebula и правда есть такие понятия, как cluster nodes, virtual networks, virtual machines, users, groups and storage datastores :) Просто если вы чего-то из этого не знаете, то вам это может показаться туманным. Но это значит, что нужно побольше почитать доку :)
1. миграции нет 2. ресайза образа нет 3. opennebula монтирует образ lxd через блочное устройство и это бьет по скорости дисковых внутри него в разы (оно умеет raw, qcow2 и ceph. я пробовал raw и qcow2) 4. у меня не получилось запустить unprivileged контейнер, пришлось настроить privileged
1. миграции нет 2. ресайза образа нет 3. opennebula монтирует образ lxd через блочное устройство и это бьет по скорости дисковых внутри него в разы (оно умеет raw, qcow2 и ceph. я пробовал raw и qcow2) 4. у меня не получилось запустить unprivileged контейнер, пришлось настроить privileged