On Mon, Jul 8, 2019 at 10:39 AM Eyal Shenitzky <eshenitz@redhat.com> wrote:
I don't see any reason not to do it in case the SD replicas are separated storage domain.
Just note that for the DR, you should prepare a separated DC with a cluster.

P.S - I most to admit that I didn't try this configuration - please share your results.

Thanks for your insights Eyal. 
I'm going ahead with the tests.
One question arose after creating disaster_recovery_maps.yml and the need to populate all the "secondary_xxx" variable mappings.

In my scenario the primary DC DC1 in Site A has the same network configuration of the primary DC DC2 in Site B.
In fact the main target is to reach better utilization of available resources and so potentially VMs in DC1 communicates with VMs in DC2 in normal conditions.
Now to configure DR I have to create a mapping of DC1 in Site B: if I want to leverage hosts' resources in Site B I'm forced to set it to DC2, correct? That is the current primary for its storage domain SD2, otherwise I will have no hosts to assign to the cluster inside it... what is the risk of overlapping of objects in this case (supposing I personally take care to not have Vms in DC1 with same name of VMs in DC2, and the same for storage domains' names)? I could have an object, such a disk id that during import would overlap with existing objects n the database? Or will the engine re-create new ids (for vnics, disks, ecc.) while importing them?

Other scenario could be to create inside Site B environment another Datacenter with name DC1-DR, and I think I have to create also the same logical networks of DC1 (and DC2 incidentally) and in case of DR I have to take off one of the hosts of DC2 and assign it to DC1-DR....

Opinions?

Thanks in advance,
Gianluca