You could combine method #1 with ManageIQ [1] to get unified management.

Barak.

[1] http://manageiq.org/

On 6 October 2015 at 19:25, Darrell Budic <budic@onholyground.com> wrote:
> I use method 1. One thing to consider is that the engine manages HA VMs, migrations, etc. It doesn’t need much bandwidth, but if it can’t talk to nodes, no migrations can happen, either for load balancing or in case of a node or storage failure.
>
> If you had very solid networking, it’s probably fine, but I find it works better in my situation to run a self hosted engine for each cluster.
>
>   -Darrell
>
>> On Oct 5, 2015, at 2:17 PM, wodel youchi <wodel.youchi@gmail.com> wrote:
>>
>> Hi,
>>
>> I need some help to decide which is better / feasible with ovirt to manage two or more distant DCs.
>>
>> Let say that we have two distant DCs to virtualize with ovirt.
>>
>> we have two options to manage them:
>>
>> 1- install two engines, one on each DC, the good side is, if one DC is down, we can still manage the other one. the down side we will have two consoles to manage.
>>
>> 2- install one engine to manage the two DCs, the good side is the use of one console to rule them all :-) the down side is if the DC containing the engine become down, there is way to manage the other one.
>>
>> is there (will be there in the future) a way for example to create a slave engine in the second DC which can takeover and let the admin to manage the second DC?
>>
>> thanks in advance
>> _______________________________________________
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users

--
Barak Korren
bkorren@redhat.com
RHEV-CI Team

_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users