You had to test it with 3.5. In 3.6+ we support more clients so the connection drop would be not the issue anymore. There are number of logical issues that would make your env not usable like Michal mentioned. Assuming at least two hosts it could happen that different hosts would become SPM for different engines. Engine is not designed to coexist with other engine and I suggest to not take this path. You may want to consider using hosted engine or use standalone engine which is able to recover after a crash. On Thu, Jun 16, 2016 at 10:17 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Thu, Jun 16, 2016 at 10:13 AM, Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
On 16 Jun 2016, at 09:07, Yaniv Kaul <ykaul@redhat.com> wrote:
On Thu, Jun 16, 2016 at 9:29 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Thu, Jun 16, 2016 at 9:10 AM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Thu, Jun 16, 2016 at 8:53 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Thu, Jun 16, 2016 at 5:33 AM, Sandvik Agustin <agustinsandvik@gmail.com> wrote:
Hi users,
Good day, is it possible to configure two ovirt-engine to manage one hypervisor? My purpose for this is what if the first ovirt-engine fails, I still have the 2nd ovirt-engine to manage hypervisor.
is this possible? or any suggestion similar to my purpose?
The "normal" solution is hosted-engine, which has HA - the engine runs in a VM, and HA daemons monitor it and the hosts, and if there is a problem they can start it on another host.
There were discussions in the past, which you can find in the list archives, about running two engines against a single database, and current bottom line is that it's not supported, will not work, and iiuc will require some significant development investment to support.
You might manage to have an active/passive solution - install an engine on two machines, configure both to use the same remote database, but make sure only one of them is active at any given time. Not sure if that's considered "fully supported", but might come close.
even when you make it work when cert issues are sorted out, you need to be very careful not to bring both engines up managing a same host, they will fight over it and the monitoring is going to be received only by one of the engines, which in turn may cause HA VMs restart and split brains all over the place.
And, IIRC from previous discussions, also internal caches etc.
But this is not something specific to ovirt-engine - many services have similar restrictions, and common clustering tools allow handling them.
That's not enough - they need to share the same set of certificates...
Best is to simply clone the machine after initial setup then change what's needed, or backup/restore only files (engine-backup --mode=backup --scope=files).
Didn't check, but I do not think they actually need all the certs of all hosts - that is, that it's not mandatory to keep /etc/pki synced between them after initial setup. Didn't try that myself.
I'm not sure what happens when you provision a host from Mgmt A, then move to Mgmt B and provision another from it: 1. Mgmt A won't be aware of that host, from cert req perspective. May not be such a big deal - donno.
2. Can Mgmt A provision another host? Need to ensure the certificate serial numbers are OK, etc.
They really need to share the CA DB.
Even keeping /etc/pki synced, or mounted from each one before starting the engine and umounting when stopping, should not be too hard.
The backup-restore sounds like good approach to me. Y.
Y.
You can find on the net docs/resources about creating a redundant postgresql cluster.
Best, -- Didi _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Didi
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Didi _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users