Re: [ovirt-users] oVirt DR: ansible with 4.1, only a subset of storage domain replicated

On Thu, Feb 8, 2018 at 10:34 AM, Luca 'remix_tj' Lorenzetto < lorenzetto.luca(a)gmail.com&gt; wrote: If engine will update the OVF_STORE on any VM change that could reflect the oVirt performance since it is a heavy operation, although we do have some ideas to change that design so every VM change will only change the VM OVF instead of the whole OVF_STORE disk. If using the fail-over in ovirt-ansible-disaster-recovery, the VM/Template registration process is being done automatically through the ovirt-ansible tasks and it is based on the oVirt 4.2 API. The task which registers the VMs and the Templates is being done there without indicating the target cluster id, since in oVirt 4.2 we already added the cluster name in the VM's/Template's OVF. If your engine is oVirt 4.1 the registration will fail since in oVirt 4.1 the cluster id is mandatory. I think it could work, although I suggest that the clusters should be compatible with those configurd in the primary setup otherwise you might encounter problems when you will try to fail back (and also to avoid any collisions of affinity groups/labels or networks). For example if in your primary site you had DC1 with cluster1 and DC2 with cluster2 then your secondary setup should be DC_Secondary with cluster_A and cluster_B. cluster1 will be mapped to cluster_A and cluster2 will be mapped to cluster_B. Another thing that might be troubling is with the master domain attribute in the mapping var file. That attribute indicates which storage domain is master or not. Here is an example how it is being configured in the mapping file: - dr_domain_type: nfs dr_primary_dc_name: Prod dr_primary_name: data_number dr_master_domain: True dr_secondary_dc_name: Recovery dr_secondary_address: ... In your primary site you have two master storage domains, and in your secondary site what will probably happen is that on import of storage domains only one of those two storage domains will be master. Now that I think of it, it might be better to configure the master attribute for each of the setups, like so: dr_primary_master_domain: True dr_secondary_master_domain: False